译文：前端性能的重要性 The Importance of Frontend Performance

欢迎訪问我的主页。最新的文章我会首先公布在个人主页上：

http://blog.guaidm.com/shocky/

原书下载地址：http://pan.baidu.com/s/1pJocRwB

在我的web开发生涯里，大部分时候我都是作为一个后台project师。这样一来，我投入了非常多的精力去研究、练习怎样通过后台优化来提升项目产品的性能，诸如编译器选项，数据库索引。内存管理等。非常多书都花大量篇幅来讲述怎样在这些方面提高性能。非常多人也进而在这方面的优化花了大量时间。说实话，非常多WEB网页，真正花费在webserver到终端用户的时间事实上往往不超过整个响应时间的一两成。

假设你真的想极大幅度地降低web页面的响应时间。你应该把注意力放在真正影响终端用户体验的另外八九成的内容上。那这80%-90%的时间究竟花费在哪了？怎样才干去降低？基于现现在WEB应用的基本原理，本书的下面章节便将来提供14条加速优化法则。

Tracking Web Page Performance

追踪网页性能

为了可以找到性能的提升点。我们必须知道用户的时间花在哪了。图表A-1展示了当用户用IE浏览器訪问雅虎首页(http://www.yahoo.com)时的HTTP传输情况。每一个横条是一个html请求。第一个名为html的横条是表示初始化HTML文档。浏览器解析HTML文本并開始下载当中的文档元素。

在这个样例中，因为浏览器的缓存为空，所以全部的元素都须要进行下载。下载HTML文档只耗费了全响应响应时间中的5%。所以另外95%的用户等待时间都用在了下载文档节点的详细元素内容上。

当然，还有非常小的一部分时间花在了等待解析HTML、脚本和CSS上。也就是图中两个下载条之中的空白区间。

图标A-2展示了使用IE浏览器第二次訪问同一个URL地址时候的情况。

HTML文档初始化依然仅仅占用了12%的总响应响应时间。并且绝大部分元素内容不须要再下载了。由于他们已经在浏览器的缓存里。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveWFuZ3h5ODExMTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

只是在第二次訪问时。有5个元素还是被请求进行下载了：

一个重定向：

这个重定向的内容事实上之前就下载过。可是浏览器还是又请求了一次，这回HTTP响应结果是302（"Found" 或 "move temporarily") ，而且在返回的报头中并没有不论什么缓存信息。所以浏览器也没办法缓存本次响应结果。关于这个我将在章节B中对HTTP进行讨论。

三张未进行缓存的图片

接下来之所以三个图片被请求下载了是因为之前第一次訪问时没有被下载缓存过，这三张图是新闻图片和广告图片，所以会被频繁的更换。

一张已经被缓存的图片

最后一个HTTP请求是一个条件GET请求。

这个图片之前已经被缓存过了，可是因为HTTP的响应报头中的參数设置，浏览器必须在确保图片是最新版本号的图片后才干给到用户。关于条件GET请求也会在章节B中进行讨论。

Where Does the Time Go?

时间都去哪了？

这么一来。我们发现：至少80%的响应时间是花在了下载页面元素内容上。

当我们去深度挖掘这些图表的细节时，我们将会逐渐看到HTTP与浏览器之间及其复杂的交互过程。之前，我已经提到过HTTP的状态码和报头是怎样影响浏览器的缓存操作的。除此之外，我们还能注意到下面几点：

1. 在使用了缓存的情况下（图表A-2)，并不会有非常多下载请求。相反，你会看到在HTML文档初始化解析完毕后，紧接着出现一段没有不论什么下载记录的空白区域。这一段时间就是用来解析HTML文档，JS和CSS。同一时候也包含了从缓存中取出已有的元素内容。

2.时刻变化的并行HTTP请求数。图表A-2最多时候出现了3个并行的HTTP请求。然而在图表A-1中却有了多达6、7个HTTP请求同一时候出现。

这样的现象缘于不同域名的数量的影响，而且不管这个使用的协议HTTP/1.0还是HTTP/1.1
。关于这个问题我们将在章节6“并行下载”中进行深入探讨。

3. 并行请求并不会发生在脚本被请求时，这是由于在绝大多数时候。浏览器会对除开下载脚本之外的请求进行堵塞。章节6中对此的原因进行了解释。并介绍了怎样利用这样的特点来加快页面载入速度。

精确找出时间究竟花在哪了。这非常难。可是要找出哪里没花时间，却非常easy——下载HTML文档不费时。与之相关的不论什么的后台处理也不费时。既然这些不费时。那么我们便能够意识到。优化前端中那些费时的东西，是何等重要了。

The Performance Golden Rule

性能优化黄金条例

之前我们提到了仅仅有10-20%的响应时间被花在了下载HTML文档上，而这样的现象并不仅仅仅仅发生在雅虎站点的首页。

之前的这些数据特点可以很好的适用于雅虎的差点儿全部功能（除了雅虎的搜索功能，由于那个搜索页的元素实在太少了）。

而且，这些统计数据相同适用于绝大部分站点。

表格A-1展示了http://www.alexa.com选出的美国十大站点。当然有点小修改：除了AOL以外其它都是美国十大站点，当中Craigslist.org位列当中。可是该站点差点儿没有图片。脚本和CSS，所以实在是没办法成为一个好的样例。所以我换做把AOL选入进来了。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveWFuZ3h5ODExMTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

相同的，差点儿全部的站点都是在仅仅将低于20%的响应时间用在下载HTML文档上。当中唯一的一个列外是在有缓存环境下的Google。这是由于http://www.google.com总共仅仅有6个文档元素，除了一个元素以外，其它的全部元素都被设定为浏览器缓存处理。在之后的訪问中，由于这些元素都已经被缓存了，就仅仅剩下HTML文档请求和一个image
beacon。

在全部的性能优化中。最关键的是通过刻划界定当下的性能表现。来指出哪里才是真正可以大幅度提升行性能的要害之处。

非常明显。前端才是我们真正要关注的性能优化点。

首先，优化前端对整体性能的提升蕴藏着巨大的潜力。我们把后台系统处理的花费时间减半，那终端用户的响应时间无非就是缩短5-10%；相反，假设我们在前端上将时间减半，将能够缩短总响应时间的40-50%
！

其次。前端性能优化通常花费的时间更少，所需的资源也更少。

要缩短后台的等待时间。我们往往会不可避免地要做各种的事情，比方又一次设计架构与代码，找到并优化有问题的代码分支，加入或改动硬件设备，数据库分布式搭建等等。这些事往往须要花费几周乃至几个月时间。而我们之后一些章节要提到的前端性能优化措施，将都是更利于实际操作的最佳实践方案。诸如改动WEBserver配置（章节3、4）。变更脚本和CSS在web页面中的位置（章节5、6）。合并图片、脚本和CSS（章节1）。

而这些工作只花费几个小时或者几天——这远远低于后台优化所需的时间。

再有，前端优化的实际价值已经得到印证。

在雅虎，超过50个团队通过使用这些最佳实践方案。成功减少了终端用户的响应等待时间，缩减比例非常多达到了25%甚至很多其它。当然。在非常多时候。我们必须不拘泥于这些法则，依据站点的详细情况进行更详细的分析与优化，可是一般来说。通过这些最佳实践，提升25%的性能甚至更高，这都是全然有可能的。

在每一次開始进行行性能优化的时候。我都会画一个像类似A-1的图表。然后注明上性能优化的黄金法则：

10-20%的时间事实上使用来下载HTML文档，其它的80-90%时间是在下载页面元素。

本书的其它部分将会精确细致的介绍这些怎样减少这80-90%的耗费时间。为了说明清楚这些，我将会囊括非常多方面的技术：HTTP请求头、JavaScript、CSS、Apache
等等。

考虑到HTTP的基础概念是理解本书的关键所在，我将这一块单独提升到了章节B来进行讲述。

在章节B后便是提升性能的14条法则，每一条法则一个章节。这些法则依照我们通常理解上的优先顺序来进行排序。当然，一个法则是否可以非常好的适用于你特定的站点，这个要是详细情况而定。举例来说。法则2更适应于商业站点而并不是适用于个人站点。假设你採用了全部的适合你的站点的优化手段。你将可以让你的页面訪问速度提升25-50%，同一时候大大改善用户体验性。本书的最后章节展示了怎样从性能角度来分析美国的十大站点。