性能优化

时间都花哪了

浏览器会解释HTML并开始下载页面中的组件。在这种情况下，浏览器的缓存是空的，因此必须下载所有组件。HTML文档只占总响应时间的5%。用户需要花费其余95%的时间中的大部分来等待组件的下载。还有一小部分时间花在解析HTML、脚本和样式表上面。至少80%的最终用户响应时间花在了页面中的组件上。如果饿哦没人能继续深入挖掘这些图表的细节，将开始看到浏览器好人HTTP之间的相互影响是多迷人复杂。我们已经讨论了HTTP状态码和响应头是如何影响浏览器缓存的。此外，我们还可以进行以下观察。

有缓存的场景并没有太多的下载活动。紧跟HTML文档的HTTP请求之后的是一段空白，没有进行下载。这段时间里。浏览器正在解析HTML、JavaScript和CSS，并从缓存中获取组件。

大量的HTTP请求并幸发生，不管是HTTP1.0还是1.1，这一行为是因为使用了多个不同主机名造成的。

在请求脚本时不会发生并行请求。这是因为在很多情况下，浏览器在下载脚本时会阻塞额外的HTTP请求。

要精确地指出时间花在哪是很有挑战性的工作。但很容易看出时间没有花在哪里——它没有花在下载HTML文档上，包括任何的后端处理。这就是为什么前端性能很重要。

二．性能黄金法则

很多网站在获取HTML文档时，花费的时间都不到总响应时间的20%。其中有一个例外是Google在完整缓存场景中的情况。这是因为http://www.google.com只有6个人组件，除了其中一个之外，都被配置为可以优浏览器进行缓存。在后续的页面查看过程中，所有的这些组件都已被缓存，只需要对HTML文档和一个图片信标进行HTTP请求。

在进行优化是，关键是解剖当前的性能，找到在哪里能够获得最大的改进。很明显，在这种情况下我们应该关注前端性能。

首先，关注前端可以很好的提高整体性能。如果我们可以将后端响应时间缩短一半，整体响应时间只能减少5%-10%。而如果关注前端性能，同样是将其响应时间减少一半，则整体响应时间可以减少40%-45%。

其次，改进前端通常只需要较少的时间和资源。减少后端延迟会带来很大的改动，例如重新设计应用程序的架构和代码、查找和优化临界代码路径、添加或改动硬件、对数据库进行分布化等。这些被动需要花费数周或数月。

第三，前端性能调整已被证明是可行的。Yahoo!中有超过50哥团队使用了这里介绍的最佳实践并降低了最终用户响应时间，降低的幅度通常为25%或更高。有的时候，我们必须超越这些规则，并根据对网站的分析进行更有针对性的改进。但一般来说，只炫耀遵守这些最佳实践就能节省25%或更多的时间。

那么，性能黄金法则：

 只有10-20%的最终用户响应时间花在了下载HTML文档上。其余的80%-90%时间花在了下载页面中的所有组件上。

在这之后是14条提升性能的规则。