翻译:High Performance Web Sites(1)-Chapter A

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

我的大部分web生涯都是在扮演后台开发工程师的角色。所以,我很自然的把每个性能作业都作为是一个后台的优化练习罢了,像什么编译器参数,数据库索引,内存管理什么的。而且也有很多关于后台性能优化的书籍和资料让大家从中找到想要的东西。但实际上,对于绝大多数的web页面,只有不到10-20%的最终用户响应时间是花在了从服务器下载HTML源文件到用户浏览器上。如果你想达到不可思议般的用户快速浏览体验,那当然就应该去关注一下那其它的80-90%的用户体验时间花在哪儿呢?又该怎么去减少这个时间呢?后面的章节就会向您讲解与目前web优化所相关的一些基础知识,并提供14条优化性能的法则。

来关注一下web页面的性能

为了知道怎么去提高性能,我们应该先了解最终用户们都把等待的时间花在哪儿了?图A-1是在IE上访问Yahoo!的首页(http://www.yahoo.com)的HTTP响应时间图(John注:我们可以用HttpWatch(IE),Firebug(ff)工具来生成类似的图)。每一个横条都是一个HTTP请求。第一个横条,标识为html的那个,是HTML文档的初始请求(指请求HTML源文件)。然后浏览器解析这个HTML文档,并且开始下载这个页面的所有组件(John注:这里的组件是指页面所引用的图片,flash等非html文档的东西)。在我们的测试环境下,浏览器的缓存是空的,所以所有的组件都会被下载。在图上,我们可以看到,HTML源文件的下载只占整个响应时间的5%,最终用户花了近95%的时间用在等待下载组件上.还有一小部分是花在HTML,script和样式表(stylesheets)的解析上,在图中我们用每个下载时间条间的空白间隔来表示这些解析时间.

图A-2显示的是我们第二次用IE浏览这个网页时的情况.HTML文档的下载占到了整个响应时间的12%.大部分的组件都不用再下载了,因为它们已经被浏览器缓存了。

图A-1 在Internet Explorer上访问http://www.yahoo.com,空缓存

图A-2在Internet Explorer上访问http://www.yahoo.com,预先已有缓存

Ok,我们来看一下,有五个组件在第二次浏览页面时仍被下载了:

一个重定向(redirect)

这里的重定向虽然已在第一次访问被处理过了,但是浏览器还是再次请求了一次。因为它的HTTP响应状态码是302(表示”Found” 或 “move temporarily”),在响应header中没有缓存信息,所以浏览器不会去缓存它。关于这方面我们会在Chapter B中讨论HTTP时提到。

三个没有缓存的图片
接着的三个request请求是在上一次浏览时没有下载的三个图片。这些是经常变动的新闻图片和广告图片.

一个被缓存的图片
最后一个HTTP request请求是一个有条件的GET请求.这个图片是上次被缓存的,但是因为HTTP的响应头(response headers)的设置,浏览器要确认一下这个图片是不是最新的.有条件的GET请求我们也会在Chaptet B中讨论它.

 

时间都去哪儿了?

再回过来看看HTTP时间响应图,我们看到至少80%的最终用户响应时间是花在了下载页面里的组件上,如果我们来仔细分析一下这个图表的内容,我们会发现浏览器与HTTP之间的交互开始有点变的复杂了。除了上面我提到了HTTP的状态码和header会响应浏览器的缓存,另外,我们还能得到下面一些观察结果:

l 凡是被缓存的组件(图A-2)大多都不会有下载动作。相反,你看到的是紧跟在Html请求后的一个没有下载的空白时间间隔,这表示这段时间是在解析HTML,JavaScript和CSS,以及从缓存中获取相关的组件。

l 在同一时间里的HTTP请求数变化了。图A-2在同一个时间切面上最多只有三个HTTP请求,而图A-1却同时有多达六到七个HTTP请求。这是因为使用了多个不同的主机名(hostname),而无论它们是使用HTTP/1.0还是HTTP/1.1。Chapter 6将会解释这种多个同时下载的”平行下载(Parallel Downloads)”。(John注:是指同时下载)

l 这种平行下载不会发生在下载script上,因为在大多数情况下,浏览器会阻止其它下载script的HTTP请求。Chapter 6会解释为什么会这样,同时也会教你如何应用这个知识去优化你的页面载入时间。

要完完整整地指出时间都去哪儿了真是一个挑战。但至少还是很容易地能看到哪儿没花时间?它没有全花在下载HTML文档上,也没全花在后台的处理上。(几乎都花在了前端下载组件上)这就是为什么前端性能如此重要了。

 

性能黄金法则

像Yahoo!主页这样只有10%-20%的响应时间花在下载HTML源文件的现象并不是一个特例。据我分析,几乎所有与Yahoo!类似的网站都是这样(这可不包括Yahoo!Search,因为它的页面上组件的数量实在是太少了)。甚至可以进一步说,绝大多数的网站都是这样的情况。表A-1展示了由http://www.alexa.com所统计出的当今美国前10大网站。说明一下,下面提到的网站只有AOL不在前10,因为Craigslist.org本是排在前10,但是它的页面风格没有什么图片,script和样式表,不适合这里做为研究例子,所以我挑选了AOL。

图A-1 访问10大网站时的下载HTML源文件所占的时间比

所有的网站都只花了不到20%的总响应时间在获取HTML源文件上(John注:这一部分时间更多地取决于各网站的后端性能)。但只有Google在已有缓存的情况下是个例外。因为http://www.google.com只有6个组件,其中有5个被配置成被浏览器缓存。再次访问时,所有的组件被缓存,只有一个请求HTML源文件的HTTP请求和一个图片请求。

在做完所有的后台优化努力的情况下,你已经很难再有大的突破了。很显然,是时候关注前端的性能了。

首先,关注前端性能所能带来的整个性能提升到底有多少。如果我们能把后台的响应时间再优化,再砍掉一半响应时间,最终用户的响应时间也只是相应减少5% ~10%(John注:因为后台的性能只能是减少那个20%的响应HTML源文件请求)。相反的,如果我们把前端的性能提高一倍,我们可以把整个响应时间减少40~45%。

再说了,前端的改进一般不需要太多的时间和资源。而优化后台的性能时间基本上都得深入应用的构架和代码,找出优化的关健代码路径,增加或者改进硬件,分布化数据库等等,这些工作动辄就要以周和月为时间单位。在接下来的章节中介绍的前端性能优化法则都来自于最佳实践,比如修改web服务器的配置文件(Chapters3,4);将script和样式表放置到页面中相应的地方(Chapters 5 ,6);将图片,script,样式表组合到一起(Chapters 1)。这些实践只需要以小时和天为工作单位–远比提高后台性能需要的时间成本要低。

第三点,前端性能的这些实践都是经过实际考验的。在Yahoo!中有超过50个小组用这些实践减少了25%甚至更多的最终用户响应时间。在一些案例中,我们分析了运用这些要点的网站,一般都能达到25%或更多的性能提升。

在开始每个新的性能提升项目时,我都会画一张类似图A-1的图表来阐释一下性能的黄金法则:

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

俺把这句浓缩一下,就是:80-90%的用户等待时间是来自于前端的页面加载。

这本书后面的部分将会提供详细的指导法则去减少这80-90%的最终用户响应时间。为了说明这些法则,我会陆续提到很多相关的技术:HTTP headers,JavaScript,CSS,Apache等等。

因为一些HTTP的基本概念对理解这本书非常有必要,所以我会在Chapter B中重点简介。

在这之后就是分章节的14条优化法则。我把这些法则按优先级列出。每条法则都有自己的适应范围。举个例子,法则2更适合商业网站而不适合个人站点。如果您应用所有适合您网站的的优化法则,您可以将页面速度提升25-50%从而增强用户体验。这本书的最后章节会告诉您如何以性能的眼光去分析美国的10大网站。

添加评论