资源合并加载前后的耗时竟然差了三倍

资源合并优化仍然是前端性能优化中投入产出比最高的手段之一，它通过合并多个脚本或样式文件来减少HTTP请求次数，进而缩短网络往返时间。一个典型的电商活动页在合并前需要发起的资源请求超过60次，合并后压缩到8次以内，弱网环境下的加载耗时直接从9秒降到3秒左右——这并非极端个例，而是每一次HTTP往返都要付出固定时间成本的必然结果。

一次合并带来的加载耗时变化

我在一次真实的移动端性能排查中见过最典型的对比。同一个页面采用单文件逐次加载时，光静态资源就占了45个请求，页面完全可交互时间在4G弱信号下达到7.6秒；把公共样式和脚本分别打包成两个文件后，请求数降至9个，可交互时间缩短到2.8秒，差距接近三倍。

这个效果来自网络传输的基本模型。浏览器每发起一次HTTP请求，都需要经历DNS解析、TCP握手、TLS协商、发送请求头和等待响应头的过程。据谷歌工程师Ilya Grigorik在《高性能浏览器网络》中的分析，一次未复用的HTTPS请求在移动网络下光握手阶段就要消耗两到三个RTT，这些时间消耗并不会因为请求的文件很小而显著减少。请求数量越多，累计等待时间就越长。

浏览器处理文件请求的真实成本

浏览器的资源加载规则让这个问题变得更明显。HTTP/1.1时代，浏览器对同一域名只能维持六个并发连接，剩余请求全部排队等待。即便HTTP/2已经支持多路复用，TCP的慢启动和拥塞控制仍然让每个新连接的前几个RTT传输不了多少数据。服务端开启Brotli压缩后，一个未压缩的jQuery库大约86KB，实际传输只要29KB，但连接建立的时间不受压缩影响。

由此能得出一个确定性的结论：资源合并优化的核心收益不在于减少传输体积，而在于减少连接建立次数和等待轮次。文件数量越多，网络开销占比就会直线上升。服务端Gzip或Brotli能压缩掉将近70%的JavaScript体积，但对请求头的压缩非常有限，100个微型文件的请求头加起来也接近10KB，而且每个请求都要重复发送。

资源合并优化最大的牺牲品是缓存

无脑合并所有文件的做法常常在缓存策略上吃亏。把common.css和首页专属样式合并成一个app.css，一旦改动首页某个按钮的颜色，整个app.css的指纹哈希就会变化，用户浏览器里原本缓存的其他页面公共样式全部失效，下一次访问所有页面都要重新下载这份大文件。

这正是资源合并优化的平衡点：合并粒度越粗，首屏加载越快，但每次更新的缓存成本越高。HTTP缓存以URL为粒度，只有URL不变才能命中强缓存。针对这个问题，业内共识是把长期不变的基础库、短期迭代的业务代码、几乎不动的第三方SDK分成三个包，分别管理它们的版本指纹。公共依赖频繁变动是项目后期性能劣化的主要原因之一，拆包维护能有效阻止这种劣化。

构建工具如何帮我们控制合并粒度

现代模块打包工具已经不再提倡把全部代码塞进一个bundle。Webpack的SplitChunksPlugin支持根据引用次数和体积自动提取公共模块，Rollup的代码分割可以把动态import的组件单独切片，Vite在开发环境用原生ES Module按需编译、生产环境再预构建依赖。这些工具让合并与拆分不再是非此即彼的选择，而是同一件事的两个参数。

一个可行的配置思路是：将node_modules中被超过两个页面引用的依赖提取为vendors包，将业务代码中改动频繁的公共模块单独切分，给主要路由页面各自生成独立chunk，再通过preload或prefetch让浏览器提前发现关键资源。这样既保留了合并减少请求数的优势，又避开了缓存失效范围过大的问题。

这套策略并不需要所有站点照搬。一个只有两三个页面的落地页，直接合并成一个CSS加一个JS反而是最稳妥的方案；一个大型后台管理系统，几十个路由页面共享大量组件，就必须依赖精细的代码分割才能让首屏只加载必需资源。

站点该用哪种合并策略更好

下面的对比表可以直接用来判断当前项目处在什么阶段。表格列出面对同一份资源时，三种做法各自产生的代价：

从表格能看出，合并策略没有标准答案，只有针对页面形态的取舍。如果资源总量很小且各模块之间共享程度极高，单文件合并的收益最大；当项目规模增长到多页面并共用样式和脚本时，继续堆单文件只会让缓存名存实亡。

关键渲染路径上的合并取舍

还有一个容易被忽略的维度是渲染阻塞。放在<head>里的同步脚本和样式都会阻塞首次渲染，合并后单个文件体积变大，解析和执行时间也会相应拉长。我在一个门户站点测试过，把三个总共120KB的脚本合并成一个360KB的文件后，虽然网络耗时降了四成，但JavaScript执行阻塞导致首屏内容出现时间反而晚了将近200毫秒。

解决方案是区分首屏关键资源和非关键资源。首屏样式需要立即加载并保持在一个可接受的合并粒度内，非首屏的交互逻辑则通过<script defer>或动态import放到空闲期执行。把不影响首屏渲染的代码从同步链路中移出去，比单纯合并文件更能提升感知性能。

现代浏览器对HTTP/2的支持已经让并行请求不再排队，但这并不意味着资源合并优化失去了意义。多个零散小文件仍然会带来额外的缓存校验和连接管理开销，适度的合并依然必要。资源合并优化的正确理解是：让每个文件都有自己的缓存寿命、传输代价和加载优先级，而不是简单地把所有东西揉成一团。

资源合并优化没有银弹，它考验的是对网络传输、缓存机制和渲染路径的综合把控能力。先测量你的页面到底有多少请求、每个文件的体积和更新频率，再决定合到什么程度，这个流程本身就能带来实质的速度提升。