Page 177 - Web性能权威指南

• 使用CDN
从地理上把数据放到接近客户端的地方，可以显著减少每次 TCP 连接的网络延
迟，增加吞吐量。

• 添加Expires首部并配置ETag标签
相关资源应该缓存，以避免重复请求每个页面中相同的资源。Expires 首部可用
于指定缓存时间，在这个时间内可以直接从缓存取得资源，完全避免 HTTP 请
求。ETag 及 Last-Modified 首部提供了一个与缓存相关的机制，相当于最后一次
更新的指纹或时间戳。

• Gzip资源
所有文本资源都应该使用 Gzip 压缩，然后再在客户端与服务器间传输。一般来
说，Gzip 可以减少 60%~80% 的文件大小，也是一个相对简单（只要在服务器上
配置一个选项），但优化效果较好的举措。

• 避免HTTP重定向
HTTP 重定向极其耗时，特别是把客户端定向到一个完全不同的域名的情况下，
还会导致额外的 DNS 查询、TCP 连接延迟，等等。

上面每一条建议都经受了时间检验，无论是该书出版的 2007 年还是今天，都是适
用的。这并不是巧合，而是因为所有这些建议都反映了两个根本方面：消除和减少
不必要的网络延迟，把传输的字节数降到最少。这两个根本问题永远是优化的核心，
对任何应用都有效。

可是，对所有 HTTP 1.1 的特性和最佳实践，我们就不能这么说了。因为有些 HTTP
1.1 特性，比如请求管道，由于缺乏支持而流产，而其他协议限制，比如队首响应阻
塞，则导致了更多问题。为此，Web 开发社区（一直都最有创造性），创造和推行
了很多自造的优化手段：域名分区、连接文件、拼合图标、嵌入代码，等等，不下
数十种。

对多数 Web 开发者而言，所有这些都是切实可行的优化手段：熟悉、必要，而且
通用。可是，现实当中，我们应该对这些技术有正确的认识：它们都是些针对当前
HTTP 1.1 协议的局限性而采用的权宜之计。我们本来不应该操心去连接文件、拼合
图标、分割域名或嵌入资源。但遗憾的是，“不应该”并不是务实的态度：这些优化
手段之所以存在，都是有原因的，在背后的问题被 HTTP 的下一个版本解决之前，
必须得依靠它们。

162 ｜ 第 11 章