HTML5如何减少HTTP请求_HTML5资源请求合并技巧【技巧】

合并资源不能仅靠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.tsbuild.sourcemap 是否开着(它会让生成的 JS 多一个 .map 请求)。细节比技巧更致命。