转 Web程序优化的最佳实践（服务器篇）

【编者按】来自Yahoo!的Exceptional Performance团队为我们带来了改善Web性能的最佳实践方案。为此，他们为此进行了 一系列的实验、开发了各种工具、写了大量的文章和博客并在各种会议上参与探讨。最佳实践的核心就是提高网站性能。通过各种努力，xcetional Performance团队总结出了一系列可以提高网站速度的方法。可以分为 7 大类 34 条。包括内容、服务器、cookie、CSS、JavaScript、图片、移动应用等七部分。本文为服务器端的优化实践内容。

除了在网站在内容上的改进外（详情可查看站长之家前文：Web程序优化的最佳实践（网站内容篇）），在网站服务器端上也有需要注意和改进的地方，它们包括：

1. 使用内容分发网络

2. 为文件头指定Expires或Cache-Control

3. Gzip压缩文件内容

4. 配置ETag

5. 尽早刷新输出缓冲

6. 使用GET来完成AJAX请求

1、使用内容分发网络

用户与你网站服务器的接近程度会影响响应时间的长短。把你的网站内容分散到多个、 处于不同地域位置的服务器上可以加快下载速度。但是首先我们应该做些什么呢？ 按地域布置网站内容的第一步并不是要尝试重新架构你的网站让他们在分发服务器上 正常运行。根据应用的需求来改变网站结构，这可能会包括一些比较复杂的任务，如在 服务器间同步Session状态和合并数据库更新等。要想缩短用户和内容服务器的距离， 这些架构步骤可能是不可避免的。

要记住，在终端用户的响应时间中有 80%到 90%的响应时间用于下载图像、样式表、脚 本、Flash等页面内容。这就是网站性能黄金守则。和重新设计你的应用程序架构这样 比较困难的任务相比，首先来分布静态内容会更好一点。这不仅会缩短响应时间，而且 对于内容分发网络来说它更容易实现。

内容分发网络（Content Delivery Network，CDN）是由一系列分散到各个不同地理位 置上的Web服务器组成的，它提高了网站内容的传输速度。用于向用户传输内容的服务 器主要是根据和用户在网络上的靠近程度来指定的。例如，拥有最少网络跳数（network hops）和响应速度最快的服务器会被选定。 一些大型的网络公司拥有自己的CDN，但是使用像Akamai Technologies，Mirror Image

Internet， 或者Limelight Networks这样的CDN服务成本却非常高。对于刚刚起步的企

业和个人网站来说，可能没有使用CDN的成本预算，但是随着目标用户群的不断扩大和 更加全球化，CDN就是实现快速响应所必需的了。以Yahoo来说，他们转移到CDN上的网 站程序静态内容节省了终端用户 20%以上的响应时间。使用CDN是一个只需要相对简单地

修改代码实现显著改善网站访问速度的方法。

2、为文件头指定Expires或Cache-Control

这条守则包括两方面的内容：

对于静态内容：设置文件头过期时间Expires的值为"Never expire"（永不过期） 对于动态内容：使用恰当的Cache-Control文件头来帮助浏览器进行有条件的请求 网页内容设计现在越来越丰富，这就意味着页面中要包含更多的脚本、样式表、图片和 Flash。第一次访问你页面的用户就意味着进行多次的HTTP请求，但是通过使用Expires 文件头就可以使这样内容具有缓存性。

它避免了接下来的页面访问中不必要的HTTP请求。Expires文件头经常用于图像文件，但是应该在所有的内容都使用他，包括脚本、样式 表和Flash等。浏览器（和代理）使用缓存来减少HTTP请求的大小和次数以加快页面访问速度。Web服 务器在HTTP响应中使用Expires文件头来告诉客户端内容需要缓存多长时间。下面这个 例子是一个较长时间的Expires文件头，它告诉浏览器这个响应直到 2010 年 4 月 15 日 才过期。

Expires: Thu, 15 Apr 2010 20:00:00 GMT

如果你使用的是Apache服务器，可以使用ExpiresDefault来设定相对当前日期的过期时 间。下面这个例子是使用ExpiresDefault来设定请求时间后 10 年过期的文件头：

ExpiresDefault "access plus 10 years"

要切记，如果使用了Expires文件头，当页面内容改变时就必须改变内容的文件名。依Yahoo!来说我们经常使用这样的步骤：在内容的文件名中加上版本号，如 yahoo_2.0.6.js。

使用Expires文件头只有会在用户已经访问过你的网站后才会起作用。当用户首次访问 你的网站时这对减少HTTP请求次数来说是无效的，因为浏览器的缓存是空的。因此这种 方法对于你网站性能的改进情况要依据他们"预缓存"存在时对你页面的点击频率（"预缓存"中已经包含了页面中的所有内容）。

Yahoo!建立了一套测量方法，我们发现所有的页面浏览量中有 75~85%都有"预缓存"。通过使用Expires文件头，增加了缓 存在浏览器中内容的数量，并且可以在用户接下来的请求中再次使用这些内容，这甚至都不需要通过用户发送一个字节的请求。

3、Gzip压缩文件内容

网络传输中的HTTP请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的 带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是 还有其他因素影响着响应时间。通过减小HTTP响应的大小可以节省HTTP响应时间。 从HTTP/1.1 开始，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格 式：

Accept-Encoding: gzip, deflate

如果web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响 应内容。Web服务器把压缩方式通过响应文件头中的Content-Encoding来返回给浏览器。 Content-Encoding: gzip Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并通过RFC 1952来标准

化的。另外仅有的一个压缩格式是deflate，但是它的使用范围有限效果也稍稍逊色。

Gzip大概可以减少 70%的响应规模。目前大约有 90%通过浏览器传输的互联网交换支持 gzip格式。如果你使用的是Apache，gzip模块配置和你的版本有关：Apache 1.3 使 用mod_zip，而Apache 2.x使用moflate。 浏览器和代理都会存在这样的问题：浏览器期望收到的和实际接收到的内容会存在不匹 配的现象。幸好，这种特殊情况随着旧式浏览器使用量的减少在减少。Apache模块会通 过自动添加适当的Vary响应文件头来避免这种状况的出现。

服务器根据文件类型来选择需要进行gzip压缩的文件，但是这过于限制了可压缩的文件。 大多数web服务器会压缩HTML文档。对脚本和样式表进行压缩同样也是值得做的事情， 但是很多web服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括XML 和JSON，都值得的。图像和PDF文件由于已经压缩过了所以不能再进行gzip压缩。如果 试图gizp压缩这些文件的话不但会浪费CPU资源还会增加文件的大小。

Gzip压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。

4、配置ETag

Entity tags（ETags）（实体标签）是web服务器和浏览器用于判断浏览器缓存中的内 容和服务器中的原始内容是否匹配的一种机制（"实体"就是所说的"内容"，包括图 片、脚本、样式表等）。增加ETag为实体的验证提供了一个比使用"last-modified date

（上次编辑时间）"更加灵活的机制。Etag是一个识别内容版本号的唯一字符串。唯一 的格式限制就是它必须包含在双引号内。原始服务器通过含有ETag文件头的响应指定页 面内容的ETag。

HTTP/1.1 200 OK

Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f"

Content-Length: 12195

稍后，如果浏览器要验证一个文件，它会使用If-None-Match文件头来把ETag传回给原 始服务器。在这个例子中，如果ETag匹配，就会返回一个 304 状态码，这就节省了 12195 字节的响应。

 GET /i/yahoo.gif HTTP/1.1

Host: us.yimg.com

If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT If-None-Match: "10c24bc-4ab-457e1c1f"

HTTP/1.1 304 Not Modified

ETag的问题在于，它是根据可以辨别网站所在的服务器的具有唯一性的属性来生成的。 当浏览器从一台服务器上获得页面内容后到另外一台服务器上进行验证时ETag就会不 匹配，这种情况对于使用服务器组和处理请求的网站来说是非常常见的。

默认情况下， Apache和IIS都会把数据嵌入ETag中，这会显著减少多服务器间的文件验证冲突。 Apache 1.3 和 2.x中的ETag格式为inode-size-timestamp。即使某个文件在不同的服务 器上会处于相同的目录下，文件大小、权限、时间戳等都完全相同，但是在不同服务器 上他们的内码也是不同的。

IIS 5.0 和IIS 6.0 处理ETag的机制相似。IIS中的ETag格式为 Filetimestamp:ChangeNumber。用ChangeNumber来跟踪IIS配置的改变。网站所用的不 同IIS服务器间ChangeNumber也不相同。 不同的服务器上的Apache和IIS即使对于完全 相同的内容产生的ETag在也不相同，用户并不会接收到一个小而快的 304 响应；相反他 们会接收一个正常的 200 响应并下载全部内容。如果你的网站只放在一台服务器上，就 不会存在这个问题。但是如果你的网站是架设在多个服务器上，并且使用Apache和IIS 产生默认的ETag配置，你的用户获得页面就会相对慢一点，服务器会传输更多的内容， 占用更多的带宽，代理也不会有效地缓存你的网站内容。即使你的内容拥有Expires文 件头，无论用户什么时候点击"刷新"或者"重载"按钮都会发送相应的GET请求。

如果你没有使用ETag提供的灵活的验证模式，那么干脆把所有的ETag都去掉会更好。 Last-Modified文件头验证是基于内容的时间戳的。去掉ETag文件头会减少响应和下次 请求中文件的大小。微软的这篇支持文稿讲述了如何去掉ETag。在Apache中，只需要在配置文件中简单添加下面一行代码就可以了：

FileETag none

5、尽早刷新输出缓冲

当用户请求一个页面时，无论如何都会花费 200 到 500 毫秒用于后台组织 HTML 文件。 在这期间，浏览器会一直空闲等待数据返回。在 PHP 中，你可以使用 flush()方法，它 允许你把已经编译的好的部分 HTML 响应文件先发送给浏览器，这时浏览器就会可以下 载文件中的内容（脚本等）而后台同时处理剩余的 HTML 页面。这样做的效果会在后台 烦恼或者前台较空闲时更加明显。

输出缓冲应用最好的一个地方就是紧跟在<head />之后，因为 HTML 的头部分容易生成 而且头部往往包含 CSS 和 JavaScript 文件，这样浏览器就可以在后台编译剩余 HTML 的

同时并行下载它们。 例子：

 

 

… <!– css, js –>

</head>

<?php flush(); ?>

<body>

… <!– content –>

为了证明使用这项技术的好处，Yahoo!搜索率先研究并完成了用户测试。

6、使用GET来完成AJAX请求

Yahoo!Mail团队发现，当使用XMLHttpRequest时，浏览器中的POST方法是一个"两步走" 的过程：首先发送文件头，然后才发送数据。因此使用GET最为恰当，因为它只需发送 一个TCP包（除非你有很多cookie）。IE中URL的最大长度为 2K，因此如果你要发送一个超过2K的数据时就不能使用GET了。 一个有趣的不同就是POST并不像GET那样实际发送数据。根据HTTP规范，GET意味着"获 取"数据，因此当你仅仅获取数据时使用GET更加有意义（从语意上讲也是如此），相反，发送并在服务端保存数据时使用POST。