仅需要花费l0%-20%的响应时间来下载HTML文档这一现象并不只出现在Yahoo!的首页 上。这一统计数字适用于我所分析过的所有的Yahoo!功能（除了 Yahoo! Search,因为它 的页面上只有很少世的组件)。而且，这一统计数字适用于绝大多数网站。表A-1展示了 从上得到的前十个美国网站。注意除了 AOL之外，这些网站都名列 美国前十名。Craigslist.org也位于前十名，但它的页面中几乎没有图片.脚本和样式表， 并不是一个很好的实例。因此我在这里选择用AOL来代替它。
表A-1:十大网站花在下载HTML文档上的时间百分比
无缓存 | 完整缓存 | |
AOL | 6% | 14% |
Amazon | IS% | 14% |
CNN | 19% | 8% |
eBay | 2% | 8% |
14% | 36% | |
MSN | 3% | 5% |
MySpace | 4% | 14% |
Wikipedia | 20% | 12% |
Yahoo! | 5% | 12% |
YouTube | 3% | 5% |
所有这些网站在获取HTML文档时，花费的时间都不到总响应时间的20%。其中一个例是Google在完整缓存场景中的情况。这是因为http://www.google.com只有6个组件， 除了其中一个之外，都被配置为可以由浏览器进行缓存。在后续的页面査看过程中，所有 这些组件都已被缓存，只需对HTML文档和一个图片信标进行HTTP请求，
在进行优化时，关键是剖析当前的性能，找到在哪里能够获得最大的改进。很明显，在这 种情况下我们应该关注前端性能。
如果我们可以将后端响应时间缩短一半，整体 响应时间只能减少5%-10%。而如果关注前端性能，同样是将其响应时间减少一半，则整 体响应时间可以减少40%-45%。
减少后端延迟会带来很大的改动，例如重新设计应用程序的架构和代码、査找和优化临界代码路径、添加或改动硬件、对数据库进 行分布化等。这些改动需要花费数周或数月。接下来的章节中将要介绍的前端性能改进只 需要一些最佳实践，例如修改Web服务器配ffl文件、将脚本和样式表 放在页面中的特定位罝、合并图片、将脚本和样式表这些改 动只需要几个小时或几天，这比进行后端改进要少花很多时间。
Yahoo!中有超过50个团队使用了这里介绍的最 佳实践并降低了最终用户响应时间，降低的幅度通常为25%或更髙。有的时候，我们必须 超越这些规则，并根据对网站的分析进行更有针对性的改进。但一般来说，只需要遵守这 些最佳实践就能节省25%或更多的时间。 在开始任何新的性能改善计划之前，我绘制了一个类似表A-丨的图表，并解释一下性能黄金法则：
只有10%~20%的最终用户响应时间花在了下栽HTML文档上.其余的80%~90%
时间花在了下载页面中的所有组件上，