[译]雅虎13个简单规则-加速您的网站的最佳实践

加速您的网站的最佳实践

原文地址：https://developer.yahoo.com/performance/rules.html

卓越绩效团队已经肯定了一些快速制做网页的最佳作法。该清单包括35个最佳实践，分为7个类别。

 

最小化HTTP请求

tag：content

80％的最终用户响应时间花费在前端。大部分时间是在下载页面中的全部组件时绑定的：图像，样式表，脚本，Flash等。减小组件数量会减小呈现页面所需的HTTP请求数。这是更快页面的关键。

减小页面中组件数量的一种方法是简化页面的设计。可是是否有一种方法来构建具备更丰富内容的页面，同时还实现快速响应时间？下面是一些减小HTTP请求数的技术，同时仍然支持丰富的页面设计。

合并的文件是由全部脚本组合成一个单一的脚本，而且相似地全部的CSS组合成单个样式表来减小HTTP请求的数量的方法。当脚本和样式表在页面之间有所不一样时，组合文件更具挑战性，但将此部分做为发布流程能够提升响应时间。

CSS精灵是减小图像的请求的数量的优选的方法。结合您的背景图片为一个图像，而后使用CSSbackground-image和background-position属性来显示所需的图像段。

图像映射合并多个图像到一个单一的形象。总体大小大体相同，但减小HTTP请求的数量加快了页面。仅当图像在页面中是连续的（例如导航栏）时，图像映射才起做用。定义图像映射的坐标多是乏味的而且容易出错。使用图像地图进行导航也不可访问，所以不建议使用。

内嵌图像使用data:URL方案嵌入到实际页面的图像数据。这可能会增长HTML文档的大小。将行内图片合并到（缓存的）样式表是一种减小HTTP请求并避免增长网页大小的方法。全部主要浏览器都不支持内联图片。

减小您网页中的HTTP请求数是开始的地方。这是提升首次访问者性能的最重要指南。正如Tenni陶依尔的博客文章中描述的浏览器缓存的使用-曝光！，您网站的每日访问者的40-60％带有一个空缓存。为您的网页快速访问这些第一次访客是更好的用户体验的关键。

顶部 | 讨论这个规则

使用内容交付网络

tag：server

用户与Web服务器的距离对响应时间有影响。在多个地理位置分散的服务器上部署内容，能够从用户的角度更快地加载网页。但你应该从哪里开始？

做为实现地理上分散的内容的第一步，不要尝试从新设计您的Web应用程序以在分布式体系结构中工做。根据应用程序，更改架构可能包括使人沮丧的任务，如跨服务器位置同步会话状态和复制数据库事务。尝试减小用户和您的内容之间的距离可能会延迟，或永远不会经过此应用程序体系结构步骤。

请记住，对最终用户的响应时间80-90％用于下载的全部组件在页面：图片，样式，脚本，Flash等这是性能的黄金法则。而不是开始从新设计您的应用程序架构的艰巨任务，最好先分散您的静态内容。这不只实现了响应时间的更大减小，可是因为内容交付网络更容易。

内容传递网络（CDN）是分布在多个位置的web服务器的集合，以更有效地向用户传递内容。被选择用于向特定用户递送内容的服务器一般基于网络接近度的测量。例如，选择具备最少网络跳数的服务器或具备最快响应时间的服务器。

一些大型互联网公司拥有本身的CDN，但它的成本效益的使用CDN服务提供商，如Akamai Technologies公司，EdgeCast或3级。对于初创公司和私人网站，CDN服务的成本多是使人望而却步的，可是随着您的目标受众变得愈来愈大并变得愈来愈全球化，CDN是实现快速响应时间所必需的。在雅虎（以上以及雅虎本身提到这两个第三方感动静态内容了他们的应用程序的网络服务器到一个CDN性能CDN提升终端用户响应由20％或更屡次）。切换到CDN是一个相对容易的代码更改，将大大提升您的网站的速度。

顶部 | 讨论这个规则

添加到期或高速缓存控制标题

tag：server

这个规则有两个方面：

• 对于静态部件：落实设置遥远的未来“永不过时”的政策Expires头
• 对于动态组件：使用适当的Cache-Control头球帮助有条件的请求浏览器

 

网页设计愈来愈丰富，这意味着页面中有更多的脚本，样式表，图像和Flash。您的网页的首次访问者可能必须发出几个HTTP请求，但经过使用Expires标头，您可使这些组件可缓存。这样可避免后续网页浏览中出现没必要要的HTTP请求。Expires头最常使用图片使用，但他们应该使用全部包括脚本，样式表和Flash组件组成。

浏览器（和代理）使用缓存减小HTTP请求的数量和大小，使网页加载更快。Web服务器使用HTTP响应中的Expires标头来告诉客户端组件能够缓存多长时间。这是一个远将来Expires标题，告诉浏览器，这个响应将不会过期，直到2010年4月15日。

      到期日：星期四，2010年4月15日20:00:00 GMT

 

若是您的服务器是Apache，请使用ExpiresDefault指令设置相对于当前日期的过时日期。ExpiresDefault指令的此示例将Expires日期设置为从请求时起10年。

      ExpiresDefault“访问加10年”

 

请记住，若是你使用远期的Expires标头，你必须在组件更改时更改组件的文件名。在Yahoo!，咱们常常将此步骤做为构建过程的一部分：版本号嵌入在组件的文件名中，例如，yahoo_2.0.6.js。

使用远的未来Expires标头只会在用户访问过您的网站后影响网页浏览量。当用户首次访问您的网站而且浏览器的缓存为空时，它对HTTP请求的数量没有影响。所以，此性能提高的影响取决于用户使用加载缓存访问您的网页的频率。（A“引缓存”已经包含了全部的页面组件。）咱们测得该在雅虎，发现有底漆的缓存页面浏览数为75-85％。经过使用远期的Expires标头，您能够增长浏览器缓存的组件数量，并在后续页面视图上重复使用，而无需经过用户的Internet链接发送单个字节。

顶部 | 讨论这个规则

Gzip组件

tag：server

经过网络传输HTTP请求和响应所需的时间能够经过前端工程师作出的决定大大减小。的确，终端用户的带宽速度，互联网服务提供商，对等交换点的距离等都超出了开发团队的控制范围。但还有其余影响响应时间的变量。压缩经过减小HTTP响应的大小来减小响应时间。

从HTTP / 1.1开始，Web客户机指示对HTTP请求中的Accept-Encoding头的压缩支持。

      Accept-Encoding：gzip，deflate

 

若是Web服务器在请求中看到此标头，它可使用客户端列出的方法之一来压缩响应。Web服务器经过响应中的Content-Encoding头来通知Web客户端。

      Content-Encoding：gzip

 

Gzip是目前最流行和最有效的压缩方法。它是由GNU项目开发和标准化的RFC 1952年。你可能看到的惟一其余压缩格式是deflate，但它的效率较低，不受欢迎。

Gzip一般将响应大小减少约70％。目前大约90％的互联网流量经过声称支持gzip的浏览器。若是您使用Apache，该模块配置的gzip取决于您的版本：Apache 1.3中使用mod_gzip的同时，阿帕奇2.x使用mod_deflate模块。

浏览器和代理有一些已知的问题，可能致使浏览器指望的内容不匹配，以及关于压缩内容接收的内容不匹配。幸运的是，这些边缘状况正在逐渐减小，由于旧版浏览器的使用降低了。Apache模块经过自动添加适当的Vary响应头来帮助。

服务器根据文件类型选择gzip，可是它们决定压缩的内容一般太受限制。大多数网站gzip它们的HTML文档。还有一点值得gzip你的脚本和样式表，但许多网站错过了这个机会。事实上，压缩任何文本响应，包括XML和JSON是值得的。图像和PDF文件不该该gzipped，由于它们已经压缩。尝试gzip它们不只浪费CPU，但可能增长文件大小。

Gzip尽量多的文件类型是减小页面权重和加快用户体验的简单方法。

顶部 | 讨论这个规则

将样式表放在顶部

标签：css

虽然研究在雅虎的表现！咱们发现移动样式表文件HEAD使页面看起来要加载速度更快。这是由于在HEAD中放置样式表容许页面逐步呈现。

关注性能的前端工程师须要一个页面逐步加载; 也就是说，咱们但愿浏览器尽快显示它所拥有的任何内容。这对于具备大量内容的网页和用户在较慢的Internet链接上尤为重要。给予用户视觉反馈的重要性，如进度指标，获得了很好的研究和记载。在咱们的例子中，HTML页面是进度指示器！当浏览器逐渐加载页面时，页眉，导航栏，顶部的标志等都用做对等待页面的用户的视觉反馈。这提升了总体用户体验。

将样式表放在文档底部附近的问题是，它禁止在许多浏览器（包括Internet Explorer）中进行渐进式渲染。这些浏览器阻止渲染，以免若是页面的样式发生变化，则不得不重绘页面的元素。用户卡住了查看空白白页。

在HTML规范明确规定样式将被包含在页面的头：“不象A，[连接]只能出如今文档的HEAD部分，但它可能会出现任意次数。” 没有替代品，空白的白色屏幕或闪光的未定型内容，是值得的风险。最佳解决方案是遵循HTML规范并在文档HEAD中加载样式表。

顶部 | 讨论这个规则

将脚本放在底部

标签：javascript

脚本引发的问题是它们阻止并行下载。的HTTP / 1.1规范建议的浏览器下载不超过两种组分在每主机平行。若是您从多个主机名中提供图像，则能够同时进行两次以上的下载。然而，当脚本下载时，浏览器不会启动任何其余下载，即便在不一样的主机名。

在某些状况下，将脚本移动到底部并不容易。若是，例如，脚本使用document.write插入网页内容的一部分，它不能在页移动更低。还可能存在范围问题。在许多状况下，有办法解决这些状况。

另外一个建议是常常出现的是使用延迟脚本。该DEFER属性表示脚本不包含文件撰写，是一个线索的浏览器，他们能够继续渲染。不幸的是，Firefox不支持的DEFER属性。在Internet Explorer中，脚本可能会延迟，但不会如指望的那么多。若是脚本能够延迟，它也能够移动到页面的底部。这将使您的网页加载更快。

顶部 | 讨论这个规则

避免使用CSS表达式

标签：css

CSS表达式是一种强大的（和危险的）动态设置CSS属性的方法。他们在Internet Explorer中开始支持5.0版本，但被废弃的开始与IE8。做为示例，背景颜色能够设置为使用CSS表达式每小时交替：

      background-color：expression（（new Date（））。getHours（）％2？“＃B8D4FF”：“＃F08A00”）;

 

如图所示，该expression方法接受一个JavaScript表达式。CSS属性设置为评估JavaScript表达式的结果。该expression方法经过其余浏览器忽略，因此它是在Internet Explorer中须要建立跨浏览器提供一致的体验设置属性颇有用。

表达式的问题是它们的评价比大多数人指望的更频繁。它不只在页面呈现和调整大小时进行评估，并且还在页面滚动时，甚至在用户将鼠标移动到页面上时进行评估。向CSS表达式添加计数器容许咱们跟踪CSS表达式的计算时间和频率。在页面上移动鼠标能够轻松生成超过10,000个评估。

减小评估CSS表达式的次数的一种方法是使用一次性表达式，其中第一次评估表达式时，它将style属性设置为显式值，该值替换CSS表达式。若是样式属性必须在页面的整个生命周期中动态设置，那么使用事件处理程序而不是CSS表达式是一种替代方法。若是必须使用CSS表达式，请记住它们可能被评估数千次，并可能影响页面的性能。

顶部 | 讨论这个规则

使JavaScript和CSS外部

标签：javascript，css

许多这些性能规则处理如何管理外部组件。然而，在这些考虑出现以前，你应该问一个更基本的问题：JavaScript和CSS应包含在外部文件中，仍是内联在页面自己？

在现实世界中使用外部文件一般会产生更快的页面，由于JavaScript和CSS文件由浏览器缓存。HTML文档中内联的JavaScript和CSS在每次请求HTML文档时都会下载。这会减小所需的HTTP请求数，但会增长HTML文档的大小。另外一方面，若是JavaScript和CSS在由浏览器缓存的外部文件中，则减小HTML文档的大小而不增长HTTP请求的数量。

所以，关键因素是外部JavaScript和CSS组件相对于请求的HTML文档的数量缓存的频率。这个因素虽然难以量化，但可使用各类指标来衡量。若是您的网站上的用户每一个会话有多个网页浏览量，并且您的许多网页重复使用相同的脚本和样式表，则缓存的外部文件的潜在好处更大。

许多网站落在这些指标的中间。对于这些网站，最佳解决方案一般是将JavaScript和CSS部署为外部文件。其中，内联最好惟一的例外是主页，如雅虎头版和个人雅虎。每一个会话具备少许（也许只有一个）页面查看的主页可能会发现，内联JavaScript和CSS结果会致使更​​快的最终用户响应时间。

对于一般是许多页面视图中的第一页的前端页面，存在利用内联提供的HTTP请求减小的技术，以及经过使用外部文件实现的缓存益处。一种这样的技术是在前端页面中嵌入JavaScript和CSS，但在页面加载完成后动态下载外部文件。后续页面将引用应该已在浏览器缓存中的外部文件。

顶部 | 讨论这个规则

减小DNS查找

tag：content

域名系统（DNS）将主机名映射到IP地址，就像电话簿将人们的名字映射到他们的电话号码。当您在浏览器中键入www.yahoo.com时，浏览器联系的DNS解析器返回该服务器的IP地址。DNS有成本。DNS一般须要20-120毫秒来查找给定主机名的IP地址。在DNS查找完成以前，浏览器没法今后主机名下载任何内容。

DNS查找缓存以得到更好的性能。这种高速缓存能够发生在由用户的ISP或局域网维护的特殊高速缓存服务器上，可是也存在发生在各个用户的计算机上的高速缓存。DNS信息保留在操做系统的DNS缓存中（Microsoft Windows上的“DNS客户端服务”）。大多数浏览器都有本身的缓存，与操做系统的缓存分开。只要浏览器在其本身的高速缓存中保留DNS记录，它就不会使操做系统对记录的请求困扰。

InternetExplorer缓存DNS查找在默认状况下30分钟后，由指定的 DnsCacheTimeout注册表设置。Firefox的缓存DNS查找1分钟，由控制的network.dnsCacheExpiration配置设置。（Fasterfox将此更改成1小时。）

当客户端的DNS缓存为空（对于浏览器和操做系统），DNS查找的数量等于网页中惟一主机名的数量。这包括页面的URL，图像，脚本文件，样式表，Flash对象等中使用的主机名。减小惟一主机名的数量减小了DNS查找的数量。

减小惟一主机名的数量有可能减小页面中发生的并行下载量。避免DNS查找减小响应时间，但减小并行下载可能会增长响应时间。个人准则是将这些组件跨至少两个但不超过四个主机名。这致使在减小DNS查找和容许高度并行下载之间的良好折衷。

顶部 | 讨论这个规则

缩小JavaScript和CSS

标签：javascript，css

缩小是从代码中删除没必要要的字符以减少其大小从而提升加载时间的实践。当代码缩小时，删除全部注释，以及没必要要的空格字符（空格，换行符和制表符）。在JavaScript的状况下，这提升了响应时间性能，由于减小了下载的文件的大小。缩小JavaScript代码的两个流行的工具是JSMin和YUI压缩机。YUI压缩程序也能够缩小CSS。

混淆是能够应用于源代码的替代优化。它比缩写更复杂，所以更可能因为混淆步骤自己而产生错误。在对十个美国顶级网站的调查中，缩减达到了21％的大小减小，而25％的混淆。虽然模糊化具备更高的大小减小，但缩小JavaScript风险较小。

除了与缩小外部脚本和样式，内联<script>和<style>块能够，也应该精缩。即便你gzip你的脚本和样式，缩小他们仍然会减小5％或更多的尺寸。随着JavaScript和CSS的使用和大小的增长，缩小代码所节省的成本也将增长。

顶部 | 讨论这个规则

避免重定向

tag：content

重定向使用301和302状态码完成。如下是301响应中HTTP标头的示例：

      HTTP / 1.1 301永久移动
      位置：http://example.com/newuri
      Content-Type：text / html

 

浏览器会自动将用户在指定的URL Location字段中。重定向所需的全部信息都在标题中。响应的主体一般为空。尽管他们的名字，既不是301，也不是302的响应在实践中，除非缓存附加头，好比Expires和Cache-Control，代表它应该是。元刷新标记和JavaScript是将用户定向到其余网址的其余方法，但若是您必须执行重定向，首选的技术是使用标准的3xx HTTP状态代码，主要是确保后退按钮正常工做。

要记住的主要事情是重定向会减慢用户体验。在用户和HTML文档之间插入重定向会延迟页面中的全部内容，由于没法呈现页面中的任何内容，而且在HTML文档到达以前，不会开始下载任何组件。

最浪费的重定向之一频繁发生，Web开发人员一般不知道它。它发生在一个URL中缺乏一个尾部斜杠（/）的状况，不然应该有一个。例如，要http://astrology.yahoo.com/astrology~~V包含重定向到一个301响应结果http://astrology.yahoo.com/astrology/~~V（注意加斜杠）。这是经过使用固定的Apache Alias或mod_rewrite，或DirectorySlash指令，若是你使用Apache处理程序。

将旧网站链接到新网站是另外一个经常使用的重定向。其余包括链接网站的不一样部分并基于特定条件（浏览器的类型，用户账户的类型等）指导用户。使用重定向链接两个网站很简单，只须要少许额外的编码。虽然在这些状况下使用重定向会下降开发人员的复杂性，但会下降用户体验。这种使用重定向方案包括使用Alias与mod_rewrite若是两个代码路径在同一台服务器上托管。若是一个域名的变化是使用重定向的缘由，另外一种是建立一个CNAME与组合（即建立从一个域名指向另外一个别名DNS记录）Alias或mod_rewrite。

顶部 | 讨论这个规则

删除重复脚本

标签：javascript

它损害性能，在一个页面中包含相同的JavaScript文件两次。这并不像你想象的那么不寻常。对十大美国网站的审查显示，其中两个包含重复的脚本。两个主要因素增长了在单个网页中复制脚本的概率：团队规模和脚本数。当它发生时，重复的脚本经过建立没必要要的HTTP请求和浪费JavaScript执行来损害性能。

没必要要的HTTP请求在Internet Explorer中发生，但在Firefox中不发生。在Internet Explorer中，若是外部脚本包含两次而且不可缓存，则在加载页面期间会生成两个HTTP请求。即便脚本是可缓存的，当用户从新加载页面时也会发生额外的HTTP请求。

除了生成浪费的HTTP请求以外，还浪费了屡次评估脚本的时间。这种冗余的JavaScript执行发生在Firefox和Internet Explorer中，不管脚本是否可缓存。

避免意外包括相同脚本两次的一种方法是在模板系统中实现脚本管理模块。包含脚本的典型方法是在HTML页面中使用SCRIPT标记。

      <script type =“text / javascript”src =“menu_1.0.17.js”> </ script>

 

在PHP另外一种方法是建立一个调用的函数insertScript。

      <？php insertScript（“menu.js”）？>

 

除了防止相同的脚本被插入屡次，此函数能够处理脚本的其余问题，例如依赖关系检查和添加版本号到脚本文件名以支持远期未来的Expires头。

顶部 | 讨论这个规则

配置ETag

tag：server

实体标签（ETag）是Web服务器和浏览器用来肯定浏览器缓存中的组件是否与源服务器上的组件匹配的机制。（“实体”是另外一个词“组件”：图像，脚本，样式表等）添加ETag以提供用于验证比上次修改日期更灵活的实体的机制。ETag是惟一标识组件的特定版本的字符串。惟一的格式约束是字符串引用。源服务器指定使用组件的ETag的ETag响应头。

      HTTP / 1.1 200 OK
      最后修改：二，2006年12月12日03:03:59 GMT
      ETag：“10c24bc-4ab-457e1c1f”
      Content-Length：12195

 

稍后，若是浏览器有来验证组件，它使用If-None-Match头传回的ETag到源服务器。若是ETag匹配，则返回304状态码，对于该示例将响应减小12195字节。

      GET /i/yahoo.gif HTTP / 1.1
      主机：us.yimg.com
      If-Modified-Since：Tue，12 Dec 2006 03:03:59 GMT
      If-None-Match：“10c24bc-4ab-457e1c1f”
      HTTP / 1.1 304未修改

 

ETag的问题是它们一般使用属性来构造，这些属性使得它们对于托管站点的特定服务器是惟一的。当浏览器从一个服务器获取原始组件，而后尝试在不一样的服务器上验证该组件时，ETag不匹配，这种状况在使用服务器集群处理请求的网站上太常见。默认状况下，Apache和IIS都在ETag中嵌入数据，这大大下降了在具备多个服务器的网站上有效性测试成功的概率。

为Apache 1.3和2.x的eTag格式inode-size-timestamp。尽管给定文件能够驻留在跨多个服务器的相同目录中，而且具备相同的文件大小，许可，时间戳等，但其inode对于每一个服务器是不一样的。

IIS 5.0和6.0对ETag有相似的问题。在IIS上的ETag的格式Filetimestamp:ChangeNumber。一个ChangeNumber是用于跟踪配置更改IIS计数器。这是不太可能的ChangeNumber是后面整个网站全部的IIS服务器相同。

最终结果是由Apache和IIS生成的ETag对于彻底相同的组件将不匹配从一个服务器到另外一个。若是ETag不匹配，则用户不接收ETag设计的小的，快速的304响应; 相反，他们将得到正常的200响应以及组件的全部数据。若是您只在一个服务器上托管您的网站，这不是问题。可是若是你有多个服务器托管你的网站，而且你使用默认的ETag配置的Apache或IIS，你的用户愈来愈慢的页面，你的服务器有更高的负载，你消耗更大的带宽，有效地缓存您的内容。即便你的组件有一个遥远的将来Expires头部，有条件的GET请求依然取得每当用户点击刷新或刷新。

若是你没有利用ETag提供的灵活的验证模型，最好只是删除ETag。该Last-Modified首标验证基于对组件的时间戳。删除ETag会减小响应和后续请求中HTTP头的大小。此Microsoft支持文章介绍了如何删除的ETag。在Apache中，这是经过简单地添加如下行到您的Apache配置文件：

      FileETag无

 

顶部 | 讨论这个规则

使Ajax可缓存

tag：content

Ajax的一个引用的优势是它向用户提供即时反馈，由于它从后端Web服务器异步请求信息。可是，使用Ajax并不能保证用户不会让他的拇指等待这些异步JavaScript和XML响应返回。在许多应用程序中，用户是否保持等待取决于如何使用Ajax。例如，在基于Web的电子邮件客户端中，用户将持续等待Ajax请求的结果，以查找与其搜索条件匹配的全部电子邮件。重要的是要记住“异步”并不意味着“瞬时”。

为了提升性能，优化这些Ajax响应很重要。以提升Ajax的性能最重要的方式是使响应缓存，在讨论添加一个Expires或Cache-Control头。一些其余规则也适用于Ajax：

• Gzip组件
• 减小DNS查找
• 缩小JavaScript
• 避免重定向
• 配置ETag

 

 

让咱们看一个例子。Web 2.0电子邮件客户端可能使用Ajax下载用户的通信录以进行自动完成。若是用户自她上次使用电子邮件网络应用程序以来没有修改她的地址簿，则能够从高速缓存读取先前的地址簿响应，若是该Ajax响应能够利用将来的Expires或Cache-Control头部可高速缓存。必须通知浏览器什么时候使用先前缓存的通信簿响应，而不是请求新的响应。这能够经过添加一个时间戳到地址簿的Ajax的URL指示最后一次用户修改了她的地址簿，例如完成，&t=1190241612。若是地址簿自从上次下载以来没有被修改，则时间戳将是相同的，而且地址簿将从浏览器的高速缓存读取，消除额外的HTTP往返。若是用户修改了她的地址簿，则时间戳确保新的URL与缓存的响应不匹配，而且浏览器将请求更新的地址簿条目。

即便您的Ajax响应是动态建立的，而且可能只适用于单个用户，仍然能够缓存它们。这样作将使您的Web 2.0应用程序更快。

顶部 | 讨论这个规则

尽早冲洗缓冲区

tag：server

当用户请求页面时，后端服务器可能须要200到500毫秒的时间来将HTML页面拼接在一块儿。在此期间，浏览器在等待数据到达时处于空闲状态。在PHP中有函数刷新（） 。它容许您将部分准备好的HTML响应发送到浏览器，以便浏览器能够开始提取组件，然后端正忙于其他的HTML页面。好处主要在繁忙的后端或光前端。

一个好的地方考虑刷新是正确的HEAD后，由于头的HTML一般更容易生产，它容许您包括任何CSS和JavaScript文件的浏览器开始并行抓取，然后端仍在处理。

例：

      ... <！ -  css，js  - >
    </ head>
    <？php flush（）; ？>
    <body>
      ... <！ -  content  - >

 

雅虎搜索独创的研究和实用户测试，以证实使用这种技术的好处。

最佳

对AJAX请求使用GET

tag：server

在雅虎邮件研究小组发现，当使用XMLHttpRequest，POST在浏览器中实现为两个步骤：首先发送标题，而后发送数据。因此最好使用GET，它只须要一个TCP数据包发送（除非你有不少cookie）。IE中的最大URL长度为2K，所以若是您发送超过2K的数据，您可能没法使用GET。

一个有趣的一面影响是POST没有实际发布任何数据的行为像GET。基于对HTTP规范，GET是为获取信息，所以它是有道理的（语义）使用GET当你只请求数据，而不是将数据发送到存储服务器端。

 

最佳

后负载组件

tag：content

你能够仔细看看你的页面，问本身：“为了最初呈现页面绝对须要什么？其他的内容和组件能够等待。

JavaScript是在onload事件以前和以后拆分的理想选择。例如，若是你有JavaScript代码和库拖放和动画，那些能够等待，由于拖动页面上的元素是在初始渲染以后。寻找候选人后载加载的其余地方包括隐藏内容（在用户操做后显示的内容）和非折叠图片。

工具来帮助你出你的努力：YUI图像装载机可让你延缓倍如下图片和YUI获取工具是一种简单的方法，包括JS和动态CSS。对于在野外的例子来看看雅虎主页与Firebug的网络面板打开。

当性能目标与其余Web开发最佳作法一致时，这是很好的。在这种状况下，渐进加强的想法告诉咱们，JavaScript支持时，能够改善用户体验，但你必须确保页面工做，即便没有JavaScript。所以，在确保页面正常工做后，您可使用一些后载脚原本加强它，这些脚本会为您提供更多的响铃和哨声，例如拖放和动画。

最佳

预加载组件

tag：content

预加载可能看起来像后加载的相反，但它实际上有不一样的目标。经过预加载组件，您能够利用浏览器空闲的时间，并请求未来须要的组件（如图像，样式和脚本）。这样，当用户访问下一页时，您可使大多数组件已经在缓存中，而且您的页面将为用户加载更快。

实际上有几种类型的预加载：

• 无条件预紧-尽快的onload火灾，你继续前进，获取一些额外的组件。查看google.com上有关如何请求sprite图片的示例。此sprite图片在google.com首页上不须要，但在连续搜索结果页上须要。
• 有条件的预紧力-基于用户动做你作一个猜想，用户接下来为首并据此预加载。在search.yahoo.com你能够看到你在输入框中输入开始后，一些额外的组件是如何提出要求。
• 预计推出从新设计的前预提早-预紧力。它常常发生在从新设计以后，你听到：“新网站很酷，但它比之前慢”。部分问题多是用户正在使用完整缓存访问您的旧站点，但新的站点老是空的缓存体验。您能够经过在启动从新设计以前预加载一些组件来减轻这种反作用。您的旧站点可使用浏览器空闲的时间，并请求新站点将使用的图像和脚本

最佳

减小DOM元素的数量

tag：content

复杂的页面意味着更多的字节下载，它也意味着更慢的DOM访问在JavaScript。若是您要在页面上循环500或5000个DOM元素，以便添加事件处理程序（例如），这会有所不一样。

大量的DOM元素多是一个症状，有一些应该经过页面的标记改进而没必要移除内容。您是否使用嵌套表进行布局？你更抛出<div>仅s解决布局问题？也许有更好的和更语义的正确方法来作你的标记。

与布局有很大的帮助是YUI的CSS实用工具：grids.css能够帮助你的总体布局，fonts.css和reset.css能够帮助你剥去浏览器的默认格式。这是从新开始，想一想你的标记，好比用一个机会，<div>惟一的，当它是有意义的语义，而不是由于它呈现一个新行。

DOM元素的数量很容易测试，只需键入Firebug的控制台：
document.getElementsByTagName('*').length

和多少DOM元素太多？检查其余具备良好标记的相似网页。例如，雅虎主页是一个很是繁忙的页面，而且仍然在700元素（HTML标签）。

最佳

跨域分割组件

tag：content

拆分组件容许您最大化并行下载。请确保您使用的域名不超过2到4个，由于DNS查找会受到惩罚。例如，您能够承载你的HTML和动态内容www.example.org 和之间的分裂静电元件static1.example.org和static2.example.org

欲了解更多信息，检查“ 最大化的拼车车道并行下载 ”的Tenni陶依尔和帕蒂志。

最佳

最小化iframe的数量

tag：content

Iframes容许在父文档中插入HTML文档。了解iframe如何工做以便有效使用很是重要。

<iframe> 专业：

• 有助于缓慢的第三方内容（如徽章和广告）
• 安全沙箱
• 并行下载脚本

<iframe> 缺点：

• 成本高，即便空白
• 阻止页面onload
• 非语义

最佳

没有404s

tag：content

HTTP请求是昂贵的，因此使得HTTP请求和得到无用的响应（即404未找到）是彻底没必要要的，将减慢用户体验，没有任何好处。

一些网站有帮助404s“你的意思是X？”，这是伟大的用户体验，但也浪费服务器资源（如数据库等）。特别糟糕的是当外部JavaScript的连接是错误的，结果是404.首先，这个下载将阻止并行下载。接下来，浏览器可能会尝试解析404响应正文，如同它是JavaScript代码，试图找到可用的东西。

最佳

减小Cookie大小

标签：cookie

HTTP cookie用于各类缘由，例如身份验证和个性化。有关Cookie的信息在Web服务器和浏览器之间的HTTP标头中进行交换。保持Cookie的大小尽量低，以尽量减小对用户响应时间的影响很是重要。

欲了解更多信息，请查看 “当曲奇崩溃”由Tenni陶依尔和帕蒂志。这项研究的收获：

 

• 消除没必要要的Cookie
• 保持Cookie大小尽量低，以最小化对用户响应时间的影响
• 请注意将Cookie设置为适当的域级别，以便其余子域不受影响
• 适当设置过时日期。较早的Expires日期或无早期删除Cookie，从而提升用户响应时间

最佳

对组件使用无Cookie的域

标签：cookie

当浏览器请求静态图像并与请求一块儿发送Cookie时，服务器对这些Cookie没有任何用途。因此他们只建立网络流量没有好的理由。你应该确保静态组件被请求无cookie的请求。建立一个子域并托管全部静态组件。

若是您的域名是www.example.org，您能够承载你的静态组件上static.example.org。可是，若是你已经在顶级域名设置cookie example.org，而不是www.example.org，那么全部的请求，static.example.org将包括这些cookie。在这种状况下，您能够购买一个全新的域，在那里托管您的静态组件，并保持此域无Cookie。雅虎使用yimg.com，YouTube使用ytimg.com，亚马逊使用images-amazon.com等。

在无Cookie的域上托管静态组件的另外一个好处是，一些代理可能拒绝缓存使用Cookie请求的组件。在一个相关的说明，若是你想知道是否应该使用example.org或www.example.org为您的主页，请考虑cookie影响。省略WWW离开你别无选择，只能写饼干*.example.org，因此对于性能方面的缘由，最好使用www子域名和写入Cookie传送给子域。

最佳

最小化DOM访问

标签：javascript

使用JavaScript访问DOM元素的速度很慢，为了得到更灵敏的页面，您应该：

• 缓存对访问的元素的引用
• 更新节点“脱机”，而后将其添加到树
• 避免使用JavaScript固定布局

欲了解更多信息，请检查YUI剧院的 “高性能Ajax应用程序” 由朱利安·勒孔特。

最佳

开发智能事件处理程序

标签：javascript

有时，页面感受不太灵敏，由于太多的事件处理程序附加到DOM树的不一样元素，而后执行太频繁。这就是为何使用事件表明团是一个不错的办法。若是你有一个内部的10个按钮div，链接只有一个事件处理程序到div包装，而不是一个处理程序为每一个按钮。事件冒泡，因此你能够抓住事件，弄清楚它源自哪一个按钮。

你也不须要等待onload事件，以便开始使用DOM树作一些事情。一般你须要的是你想要访问的元素在树中可用。您没必要等待全部图像下载。 DOMContentLoaded是你能够考虑使用替代的onload事件，但直到它在全部浏览器可用，您可使用YUI事件工具，它有一个onAvailable方法。

欲了解更多信息，请检查YUI剧院的 “高性能Ajax应用程序” 由朱利安·勒孔特。

最佳

选择<link> over @import

标签：css

先前的最佳实践之一指出CSS应该在顶部，以便容许渐进渲染。

在IE浏览器@import的行为同样用<link>在页面的底部，因此最好不要使用它。

最佳

避免过滤器

标签：css

IE的专有AlphaImageLoader过滤器的目的是解决一个问题，在IE版本<7.半透明真彩色的PNG用此过滤器的问题是，它的块渲染和当图像正在下载冻结浏览器。它也增长了内存消耗，并应用于每一个元素，而不是每一个图像，因此问题倍增。

最好的办法是避免AlphaImageLoader彻底并使用优雅有辱人格的PNG8代替，这是在IE的罚款。若是你确实须要AlphaImageLoader，使用下划线黑客_filter以不惩罚你的IE7 +用户。

最佳

优化图像

tag：images

设计师完成为您的网页建立图像后，在将这些图像FTP到您的Web服务器以前，仍然能够尝试一些操做。

• 您能够检查GIF，看看它们是否使用与图像中颜色数量相对应的调色板大小。使用ImageMagick的它很容易检查使用 
  identify -verbose image.gif 
  当你看到使用4种颜色，并在调色板中的256色“槽”的图像，还有改进的余地。
• 尝试将GIF转换为PNG，并查看是否有保存。一般，有。开发人员常常犹豫使用PNG，由于浏览器支持有限，但如今已通过去了。惟一真正的问题是真正的颜色PNG的alpha透明度，但而后，GIFs不是真正的颜色，也不支持变量的透明度。所以，GIF能够作的任何事情，调色板PNG（PNG8）也能够作（动画除外）。这个简单的命令ImageMagick的结果彻底安全使用的PNG图片：
  convert image.gif image.png 
  “全部咱们要说的是：给PING一个机会”
• 运行pngcrush（或任何其余PNG优化工具）在全部的PNG图片。例： 
  pngcrush image.png -rem alla -reduce -brute result.png
• 在全部JPEG上运行jpegtran。此工具执行无损JPEG操做（如旋转），也可用于优化和删除您的图像中的注释和其余无用的信息（如EXIF信息）。 
  jpegtran -copy none -optimize -perfect src.jpg dest.jpg

最佳

优化CSS Sprites

tag：images

• 在水平方向上而不是垂直方向上将图像排列在子画面中一般致使较小的文件大小。
• 在sprite中组合类似的颜色有助于保持色彩计数低，理想状况下在256色下，以适应PNG8。
• “适合移动设备”，而且不要在sprite中留下很大的图像间隙。这不会影响文件大小，但须要更少的内存，用户代理将图像解压缩为像素映射。100x100图像为10,000像素，其中1000x1000是100万像素

最佳

不要缩放HTML中的图像

tag：images

不要使用比你须要的更大的图像，由于你能够在HTML中设置宽度和高度。若是你须要
<img width="100" height="100" src="mycat.jpg" alt="My Cat" /> 
那么你的图像（mycat.jpg）应100x100px而不是缩小500x500px形象。

最佳

使favicon.ico小和可缓存

tag：images

favicon.ico是驻留在服务器根目录中的图像。这是一个必要的邪恶，由于即便你不关心它的浏览器仍然会提出要求，因此最好不要与回应404 Not Found。此外，因为它在同一个服务器上，Cookie会在每次请求时发送。这个图像也干扰下载顺序，例如在IE中，当您在onload中请求额外的组件时，favicon将在这些额外的组件以前下载。

因此为了减小favicon.ico确保的缺点：

• 它很小，最好低于1K。
• 设置过时标题与您以为温馨（由于你不能重命名，若是你决定更改它）。您能够在将来几个月内安全地设置Expires标头。您能够检查您当前favicon.ico的最后修改日期，以作出明智的决定。

ImageMagick的能够帮助你建立favicon的小

最佳

保持组件低于25K

tag：mobile

这个限制与iPhone不会缓存大于25K的组件有关。注意，这是未压缩的大小。这是缩小重要的地方，由于gzip单独可能不够。

欲了解更多信息，请查看“ 性能的研究，第5部分：iPhone缓存能力-使之成为坚持 ”由韦恩·谢伊和Tenni陶依尔。

最佳

将组件打包到多部分文档中

tag：mobile

将组件包装到多部分文档中就像是一个带有附件的电子邮件，它能够帮助您使用一个HTTP请求获取多个组件（请记住：HTTP请求很昂贵）。当您使用此技术时，首先检查用户代理是否支持它（iPhone不支持）。

避免空图像src

tag：server

空字符串图像SRC属性出现超过一会的指望。它以两种形式出现：

1. 直的HTML
   

   <img src =“”>

2. JavaScript
   

   var img = new Image（）; 
   img.src =“”;

 

这两种形式都产生相同的效果：浏览器向您的服务器发出另外一个请求。

• Internet Explorer中使得在该页面所在的目录的请求。
• Safari和Chrome作出实际的页面自己的请求。
• 火狐 3和早期版本的行为相同，Safari和Chrome，但3.5版本解决了这个问题[错误444931]再也不发送请求。
• 歌剧遇到一个空的图片src时，不会作任何事情。

 

 

为何这种行为很差？

1. 经过发送大量意外流量来削弱您的服务器，特别是对于天天得到数百万次网页浏览量的网页。
2. 废弃服务器计算周期生成永远不会被查看的页面。
3. 可能损坏用户数据。若是您要经过Cookie或以其余方式跟踪请求中的状态，您可能会销毁数据。即便图像请求没有返回图像，全部的头部都被浏览器读取和接受，包括全部的cookie。而其他的响应被抛弃，损害可能已经完成。

 

 

这种行为的根本缘由是在浏览器中执行URI解析的方式。此行为在RFC 3986 - 统一资源标识符中定义。当遇到一个空字符串做为URI时，它被认为是一个相对URI，并根据第5.2节中定义的算法进行解析。此特定示例，一个空字符串，在5.4节中列出。Firefox，Safari和Chrome都按照规范正确地解析了一个空字符串，而Internet Explorer正在不正确地解析它，这显然符合规范的早期版本RFC 2396 - 统一资源标识符（这已被RFC 3986废弃） 。所以，技术上，浏览器正在作他们应该作的，以解决相对URI。问题是，在这种状况下，空字符串显然是无心的。

HTML5增长了的描述标签的src属性指示浏览器不做出第4.8.2额外要求：

src属性必须存在，而且必须包含引用不是分页或脚本的非交互式，可选动画的图像资源的有效URL。若是元素的基本URI与文档的地址相同，那么src属性的值不能为空字符串。

但愿，浏览器在未来不会有这个问题。不幸的是，对于<script src =“”>和<link href =“”>没有这样的子句。也许仍有时间进行调整，以确保浏览器不会意外地实现此行为。

 

这条规则的灵感来自雅虎的JavaScript大师Nicolas C. Zakas。欲了解更多信息，请查阅他的文章“ 空图片src能够摧毁你的网站 ”。

最佳