17370845950

合并资源不能仅靠HTML中link/script顺序拼接，因浏览器仍发起多个HTTP请求；关键需服务端参与或构建工具打包，否则无法减少请求数。

为什么合并资源不能只靠 和 顺序拼接

直接把多个 CSS 或 JS 文件按顺序写在 HTML 里，浏览器仍会发起多个 HTTP 请求——合并不是靠“写在一起”，而是让一个请求返回多个资源的内容。关键在于服务端是否参与：纯前端静态 HTML 无法真正减少请求数，除非借助构建工具或服务端逻辑提前打包。

• 浏览器对同一域名的并行连接数有限（通常 6 个），但每个 或 都算独立请求
• HTTP/2 虽支持多路复用，但请求头开销、TLS 握手、缓存粒度仍受单文件影响
• 开发阶段保留多文件利于调试；上线前必须合并+压缩，否则白搭

用 Webpack/Vite 打包时如何正确启用 CSS/JS 合并

现代构建工具默认已做代码分割，但「合并」需主动关闭分块或显式配置入口。重点不是“能不能合”，而是“合得是否合理”：过度合并会导致首屏加载变慢，因为用户需要的只是部分样式或逻辑。

• Vite 中默认使用 build.rollupOptions.output.manualChunks 控制拆包，设为空对象可强制全量合并（不推荐）
• Webpack 中禁用 splitChunks 即可让所有模块打进一个 bundle.js，但应仅用于小型页面
• 真正有效的做法是提取公共依赖：

  export default defineConfig({
    build: {
      rollupOptions: {
        output: {
          manualChunks: {
            vendor: ['vue', 'lodash'],
            ui: ['element-plus']
          }
        }
      }
    }
  })

内联关键 CSS/JS 时要注意哪些渲染阻塞陷阱

把小体积的首屏必需资源直接写进 HTML 的 或 标签里，能消灭一次 HTTP 请求，但容易误伤性能。

• 超过 ~15KB 的内联 CSS 会显著延长 HTML 解析时间，触发浏览器重排
• 内联脚本默认同步执行，会阻塞 DOM 构建；加 type="module" 或 defer 属性才安全
• 内联内容无法被 CDN 缓存，每次 HTML 变更都会导致重复传输相同样式/逻辑
• 推荐只内联「首屏可见区域」所需的最小 CSS（如字体、布局、按钮基础样式），其余仍走外链

使用 HTTP/2 Server Push 还值得尝试吗

Server Push 在 HTTP/2 中曾被寄予厚望，但实际已被主流放弃：Chrome 96+、Firefox 90+ 已移除支持，Nginx 也早在 1.13.10 后弃用该功能。

• Push 不可控：服务器无法知道客户端是否已缓存某资源，强行推送反而浪费带宽
• 优先级难协调：Push 资源可能抢占关键 HTML 的传输带宽
• 替代方案更可靠：使用 显式提示浏览器提前获取关键资源

• 如果还在用老旧 Nginx 配置 http2_push，建议立即删掉——它现在只增加配置复杂度，不带来收益

真正省请求的关键不在 HTML 写法，而在构建流程是否把“哪些资源必须一起到达”想清楚。很多人花时间折腾 HTML 标签顺序，却没检查 vite.config.ts 里 build.sourcemap 是否开着（它会让生成的 JS 多一个 .map 请求）。细节比技巧更致命。