Page 190 - Web性能权威指南

• 减少协议开销
通过把文件组合成一个资源，可以消除与文件相关的协议开销。如前所述，每个
文件很容易招致 KB 级未压缩数据的开销。

• 应用层管道
说到传输的字节，这两种技术的效果都好像是启用了 HTTP 管道：来自多个响应
的数据前后相继地连接在一起，消除了额外的网络延迟。实际上，就是把管道提
高了一层，置入了应用中。

连接和拼合技术都属于以内容为中心的应用层优化，它们通过减少网络往返开销，
可以获得明显的性能提升。可是，实现这些技术也要求额外的处理、部署和编码
（比如选择图片精灵中子图的 CSS 代码），因而也会给应用带来额外的复杂性。此
外，把多个资源打包到一块，也可能给缓存带来负担，影响页面的执行速度。

要理解为什么这些技术会伤害性能，可以考虑一种并不少见的情况：一个包含十来
个 JavaScript 和 CSS 文件的应用，在产品状态下把所有文件合并为一个 CSS 文件和
一个 JavaScript 文件。

• 相同类型的资源都位于一个 URL（缓存键）下面。
• 资源包中可能包含当前页面不需要的内容。
• 对资源包中任何文件的更新，都要求重新下载整个资源包，导致较高的字节开销。
• JavaScript 和 CSS 只有在传输完成后才能被解析和执行，因而会拖慢应用的执行
速度。

实践中，大多数 Web 应用都不是只有一个页面，而是由多个视图构成。每个视图都
有自己的资源，同时资源之间还有部分重叠：公用的 CSS、JavaScript 和图片。实
际上，把所有资源都组合到一个文件经常会导致处理和加载不必要的字节。虽然可
以把它看成一种预获取，但代价则是降低了初始启动的速度。

对很多应用来说，更新资源带来的问题更大。更新图片精灵或组合 JavaScript 文件
中的某一处，可能就会导致重新传输几百 KB 数据。由于牺牲了模块化和缓存粒度，
假如打包资源变动频率过高，特别是在资源包过大的情况下，很快就会得不偿失。
如果你的应用真到了这种境地，那么可以考虑把“稳定的核心”，比如框架和库，转
移到独立的包中。

内存占用也会成为问题。对图片精灵来说，浏览器必须分析整个图片，即便实际上
只显示了其中的一小块，也要始终把整个图片都保存在内存中。浏览器是不会把不
显示的部分从内存中剔除掉的！

HTTP 1.x ｜ 175