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
ETags 存在的问题是它们是由特定服务器构造的，所以如果浏览器从一个服务器获取最初的组件，然后想验证另一个服务器上的相同组件， ETags 是无法匹配成功的，而用一群服务器处理请求在 web 站点中又非常普遍。默认情况下， Apache 和 IIS 会在 ETag 中嵌入数据，以大大降低在多服务器站点上有效性测试成功的几率。
Apache 1.3 和 2.x 中 ETag 的格式是 inode-size-timestamp 。就算给定的文件可能在多个服务器的相同目录下，而且文件大小、访问权限、时间戳等等全部相同，它的 i 节点（ P.S. inode ， UNIX 中的索引文件）在不同服务器中也不一样。
IIS5.0 和 6.0 也都存在类似的问题。 IIS 中 ETags 的格式是 Filetimestamp:ChangeNumber ， ChangeNumber 是一个用来追踪 IIS 配置变更的计数器。 一个站点在不同的 IIS 服务器上的 ChangeNumber 是不可能相同的。
最终结果是 Apache 和 IIS 为完全相同的组件生成的 ETags 无法跨浏览器匹配，如果 ETags 不匹配，用户就无法收到为又小又快的 304 响应设计的 ETags 。反而，他们将收到一个携带着组件所有数据的 200 正常响应。如果站点部署在单一服务器上，就根本不存在这个问题。但如果站点部署在多个服务器上，而且打算用 Apache 或者 IIS 的默认 ETags 配置，用户将看到缓慢的页面，服务器负载更高，还会消耗更大的带宽，并且代理也无法有效缓存页面内容。即使组件有“永久” Expires HTTP 头，用户点击重新加载或者刷新的时候，仍然会发出条件 GET 请求。
如果不想用 ETags 提供的灵活的验证模型，最好把所有的 Etag 全都去掉，可以用基于组件的时间戳的 Last-Modified HTTP 头验证，而且去掉 ETag 可以减少 HTTP 响应头以及后续请求的大小。 Microsoft Support article 里写了怎样移除 ETags 。在 Apache 中，可以简单地通过在 Apache 配置文件中添上如下代码来实现：
FileETag none
14. 让 Ajax 可缓存
分类 : 内容
Ajax 的一个好处是可以给用户提供即时反馈，因为它能够从后台服务器异步请求信息。然而，用了 Ajax 就无法保证用户在等待异步 JavaScript 和 XML 响应返回期间不会非常无聊。在很多应用程序中，用户能够一直等待取决于如何使用 Ajax 。例如，在基于 web 的电子邮件客户端中，用户为了寻找符合他们搜索标准的邮件消息，将会保持对 Ajax 请求返回结果的关注。重要的是，要记得“异步”并不意味着“即时”。
要提高性能，优化这些 Ajax 响应至关重要。最重要的提高 Ajax 性能的方法就是让响应变得可缓存，就像在 添上 Expires 或者 Cache-Control HTTP 头 中讨论的一样。下面适用于 Ajax 的其它规则：
Gzip 组件
减少 DNS 查找
压缩 JavaScript
避免重定向
配置 ETags
我们一起看看例子，一个 Web 2.0 的电子邮件客户端用了 Ajax 来下载用户的通讯录，以便实现自动完成功能。如果用户从上一次使用之后再没有修改过她的通讯录，而且 Ajax 响应是可缓存的，有尚未过期的 Expires 或者 Cache-Control HTTP 头，那么之前的通讯录就可以从缓存中读出。必须通知浏览器，应该继续使用之前缓存的通讯录响应，还是去请求一个新的。可以通过给通讯录的 Ajax URL 里添加一个表明用户通讯录最后修改时间的时间戳来实现，例如 &t=1190241612 。如果通讯录从上一次下载之后再没有被修改过，时间戳不变，通讯录就将从浏览器缓存中直接读出，从而避免一次额外的 HTTP 往返消耗。如果用户已经修改了通讯录，时间戳也可以确保新的 URL 不会匹配缓存的响应，浏览器将请求新的通讯录条目。
即使 Ajax 响应是动态创建的，而且可能只适用于单用户，它们也可以被缓存，而这样会让你的 Web 2.0 应用更快。
15. 尽早清空缓冲区
分类 : 服务器
当用户请求一个页面时，服务器需要用大约 200 到 500 毫秒来组装 HTML 页面，在这期间，浏览器闲等着数据到达。 PHP 中有一个 flush() 函数，允许给浏览器发送一部分已经准备完毕的 HTML 响应，以便浏览器可以在后台准备剩余部分的同时开始获取组件，好处主要体现在很忙的后台或者很“轻”的前端页面上（ P.S. 也就是说，响应时耗主要在后台方面时最能体现优势）。
比较理想的清空缓冲区的位置是 HEAD 后面，因为 HTML 的 HEAD 部分通常更容易生成，并且允许引入任何 CSS 和 JavaScript 文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。
例如：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content --> Yahoo! 搜索 开创了这项技术，而且真实用户测试研究也证明了使用这种技术的诸多好处。
16. 对 Ajax 用 GET 请求
分类 : 服务器
Yahoo! 邮箱 团队发现使用 XMLHttpRequest 时，浏览器的 POST 请求是通过一个两步的过程来实现的：先发送 HTTP 头，在发送数据。所以最好用 GET 请求，它只需要发送一个 TCP 报文（除非 cookie 特别多）。 IE 的 URL 长度最大值是 2K ，所以如果要发送的数据超过 2K 就无法使用 GET 了。
POST 请求的一个有趣的副作用是实际上没有发送任何数据，就像 GET 请求一样。正如 HTTP 说明文档 中描述的， GET 请求是用来检索信息的。所以它的语义只是用 GET 请求来请求数据，而不是用来发送需要存储到服务器的数据。
17. 延迟加载组件
分类 : 内容
可以凑近看看页面并问自己：什么才是一开始渲染页面所必须的？其余内容都可以等会儿。
JavaScript 是分隔 onload 事件之前和之后的一个理想选择。例如，如果有 JavaScript 代码和支持拖放以及动画的库，这些都可以先等会儿，因为拖放元素是在页面最初渲染之后的。其它可以延迟加载的部分包括隐藏内容（在某个交互动作之后才出现的内容）和折叠的图片。
工具可帮你减轻工作量： YUI Image Loader 可以延迟加载折叠的图片，还有 YUI Get utility 是一种引入 JS 和 CSS 的简单方法。 Yahoo! 主页 就是一个例子，可以打开 Firebug 的网络面板仔细看看。
最好让性能目标符合其它 web 开发最佳实践，比如“渐进增强”。如果客户端支持 JavaScript ，可以提高用户体验，但必须确保页面在不支持 JavaScript 时也能正常工作。所以，在确定页面运行正常之后，可以用一些延迟加载脚本增强它，以支持一些拖放和动画之类的华丽效果。
18. 预加载组件
分类 : 内容
预加载可能看起来和延迟加载是相反的，但它其实有不同的目标。通过预加载组件可以充分利用浏览器空闲的时间来请求将来会用到的组件（图片，样式和脚本）。用户访问下一页的时候，大部分组件都已经在缓存里了，所以在用户看来页面会加载得更快。
实际应用中有以下几种预加载的类型：
无条件 预加载 ——尽快开始加载，获取一些额外的组件。 google.com 就是一个 sprite 图片预加载的好例子，这个 查看更多关于关于yahoo军规的详细介绍的详细内容...