Best Practices for Speeding Up Your Web Site(1)

写在前面的一些话：

       从事IT行业，英文有时总会成为我们的硬伤，因为一些好的资料大多是英文的，为了跨越技术门槛，有时我们不得不先把英文搞定，这倒不是要求我们的英文水平有多高，要我们都能做到能拿操着一口流利的英语去和老外对骂（哈哈），但是一些起码的理解性的障碍是我们一定要克服的！所以对于挨踢人们来说，我们只好忍啦！好的技术性文章值得大家细细研读，但是语言障碍总使得我们的理解存在偏差，初次翻译，有点子费力，因为英文的语言习惯和中文的还是有很大差别的，有时很佩服那些专注于外文翻译的工作者们。   

        Web应用的设计与开发，无论何时，"性能"都是不能忽略的！ Yahoo  Developer Network 上提出的35条性能优化法则，十分值得每个Web前端工程师参考和借鉴，读罢原文后，我觉得有必要把其尝试性的翻译一下，一来作为自己学习的总结，二来也是和大家分享一下。 本文花费本人一个周末的时间，文章有的地方由于个人技术水平和英文能力的限制，可能翻译后和原文的作者所有表达的意思有不少差距，而且有的地儿自己都觉得过于生硬，忘大家多多指证和交流！希望本文能够帮助到你，这对我来说是最大的欣慰！哈哈！现把本文和大家分享一下！不过还是建议大家读一读原文！

                 Best Practices for Speeding Up Your Web Site

           站点加速的最佳实践

    经验丰富的性能团队已经发现了许多加速网页的最好实践做法。这个清单列出了35条最佳的实践，并划分为7类。

七个分类包括：

内容（Content），服务器（Server），Cookie，样式表（CSS），Javascript， 图像（Images），移动设备（Mobile）

一、

Minimize HTTP Requests

tag: content

最小化HTTP请求（Minimize HTTP Requests）

标签：内容（content）

       80%的终端用户的时间都花费在了前端（front-end）。大多数的这些时间都花在了下载页面中的所有组件上：图片，样式表，脚本，flash，等等。减少组件的数量，反过来会减少渲染页面的所必须的HTTP请求的数量。这是网页提速的关键所在。

一个减少页面中的页面组件的办法是简化页面的设计。但是有没有办法在用丰富的内容构建页面的同时，又能获得很快的响应时间呢？ 下在这有些技术用来减少HTTP请求的数量，与此同时又支持富文本设计。

       组合文件（Combined files）是一种减少HTTP请求的方式，即通过将所有的脚本组合到单一的脚本文件中，同样的将所有的CSS样式组合到一个样式文件中。当脚本和样式在不同的页面中变化各异时，组合文件是十分富有挑战性的，但是使这种方式成为你的到你的发布处理中会提高响应时间。

       CSS精灵（CSS Sprites）是一钟减少图像请求数量非常好的办法。将你的所有背景图像加入到同一张图片中，然后利用CSS的background-image和background-position属性来展现你想要的图像片段。

      图片maps（Image maps）将所有的图片加入到单一图片文件，图片的所有大小基本是相同的，但是这减少了HTTP请求并且加快了页面速度。Image maps只有在页面中的图片 是批次临近时才会有用，例如一个导航条。定义Image maps的坐标可能是冗繁和易于出错的。对于使用Image maps的导航来说也同样是不可访问的。所以这种办法不推荐使用。

      内联图片（inline imags）利用 data: URL scheme 来嵌入图像数据到实际的图片中。这会增加你的HTML文档中的页面量。将你的内联图片组合到样式表（可缓存的）中是一个既可以减少HTTP请求也能减少你的页面量的办法。然而内联图片 并不是被所有浏览器都支持。

     减少你页面中的HTTP请求的数量是起点。对于第一次访问的访问者来说，这是提升性能的最好的指导。正如在 Tenni Theurer的博客 Browser Cache Usage - Exposed!中所说的40%-60%的日常访问者会在没有缓存的情况下访问你的站点。对于这些初次访问者，确保你的页面速度，是更佳用户体验的关键。

二、

Use a Content Delivery Network

tag: server

使用内容发布网络

标签：服务器

      用户到你的服务器的距离远近对于响应时间来说有重大的影响。多重部署你的内容，从用户角度来说，地理上分散的服务器会使你的页面加载速度更快。但是你如何开始呢？

       对于实现地理上分布内容的第一步来说，不要试图重新设计你的web应用以使其能够工作在分布式的架构中。根据你的应用，改变架构云会包括令人生畏的任务，如跨服务器地点的同步session状态，复制数据库事务。尝试缩短用户和你的内容服务器的距离可能会被应用本身的架构步骤所耽误。

       记住80-90%的终端用户的响应时间都花费在了下载页面中的所有组件上了，包括：图像，样式表，脚本，flash等等。这是“性能的黄金法则”。与其十分困难的开始重新设计应用架构，倒不如分散你的静态内容（static content）。这不但获得了更短的响应时间，而且还因为分布网络而变得更加容易。

        一个内容分布网（Content Delivery Network）CDN是一个跨多地点更加高效分发内容到用户的分布式web服务器的集合。分发内容到具体用户的服务器，通常是依据网络距离的测量来选择的。例如有更少网络跳数的服务器，或者响应时间最快的服务器会被选中。

         一些大型的网络公司会拥有自己的CDN，但是使用CDN服务提供商提供的服务会划算，例如： Akamai Technologies, EdgeCast, 或者 level3。对于起步公司和私营站点来说，CDN服务的这部分花销可能会去掉。但是随着目标用户的增长和国家化加速，一个CDN对于获得更快的响应速度来说是十分必要的。在雅虎，将静态内容与应用所在的web服务器分隔并移动到 CDN上，缩短了20%或者更多的用户响应时间。转换到CDN在编码改变上会变得容易些并且显著的提高了你的站点速度。

三、

Add an Expires or a Cache-Control Header

tag: server

添加一个 Expires 或者一个 Cache-Control 头部信息

内容：服务器

这条原则包括两方面：

    对于静态组件：通过设置未来的Expires 信息头来实现 "Never expire"策略

    对于动态组件：通过合理的使用Cache-Control 头来帮助浏览器有选择性的请求。

Web页面的设计变得越来越丰富，这意味着更多的脚本，样式表，图片和flash会出现在页面中。初次访问站点的用户可能不得不发送多次HTTP请求，但是通过使用Expires头，你可以使得这些组件成为可缓存的（Cacheable）。这避免了之后页面展示总的不必要的请求。Expires头多数用于图片上，但是它应该被用在所有的组件上，包括脚本，样式表，以及Flash。

    

        浏览器（和代理）里用缓存机制来减少之后页面展示中HTTP请求的数量和大小。一个Web服务器使用一个包含Expires头的响应来通知客户端一个组件可以被缓存多长时间。下面是一个Expires头信息，通知浏览器该响应内容直到2010年4月15日才会失效

    Expires: Thu, 15 Apr 2010 20:00:00 GMT

    

        如果你的服务器是Apache，使用ExpiresDefault 指令来设置一个相对当前时间的失效时间。

 

            ExpiresDefault "access plus 10 years"

        记住如果你使用Expires，你不得不改变组件的文件名称，只要组件发生变化。在雅虎，我们经常使这些成为构建进程的一部分：一个版本号会被嵌入到组件的文件名中，例如： yahoo_2.0.6.js。

        只有在一个用户访问过你的站点后,才能使用Expires头来影响页面的视图。对于初次访问你站点的用户，以及那些用户浏览器缓存是空白用户，这个办法对于以上两种情况下发出的HTTP请求的数量是没有任何影响的。所以这条性能提升的影响取决于你的用户在一个“待发缓存“（待发缓存中已经包含了页面中的所有组件）下访问你站点的频率。我们在雅虎上进行了 测试，并且发现在75%-80%的情况下用户会在有组件缓存的情况下访问站点。通过利用Expires 你可以增加被浏览器缓存的组件数量，并且在之后的页面视图中，在没有通过用户网络连接发送任何一个字节的情况下，继续重用这些组件。