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

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

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

最小化HTTP请求

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

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

合并的站的最佳文件是由所有脚本组合成一个单一的脚本，并且类似地所有的CSS组合成单个样式表来减少HTTP请求的数量的方法。当脚本和样式表在页面之间有所不同时，组合文件更具挑战性，但将此部分作为发布流程可以提高响应时间。实践

CSS精灵是译雅减少图像的请求的数量的优选的方法。结合您的简单加速背景图片为一个图像，然后使用CSS和属性来显示所需的图像段。

图像映射合并多个图像到一个单一的规则形象。整体大小大致相同，但减少HTTP请求的站的最佳数量加快了页面。仅当图像在页面中是实践连续的（例如导航栏）时，图像映射才起作用。定义图像映射的坐标可能是乏味的并且容易出错。使用图像地图进行导航也不可访问，因此不建议使用。

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

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

顶部 | 讨论这个规则

使用内容交付网络

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

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

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

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

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

顶部 | 讨论这个规则

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

这个规则有两个方面：

网页设计越来越丰富，这意味着页面中有更多的脚本，样式表，图像和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组件

通过网络传输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尽可能多的文件类型是减少页面权重和加快用户体验的简单方法。

顶部 | 讨论这个规则

将样式表放在顶部

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

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

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

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

顶部 | 讨论这个规则

将脚本放在底部

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

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

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

顶部 | 讨论这个规则

避免使用CSS表达式

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

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

如图所示，该方法接受一个JavaScript表达式。CSS属性设置为评估JavaScript表达式的结果。该方法通过其他浏览器忽略，所以它是在Internet Explorer中需要创建跨浏览器提供一致的体验设置属性很有用。

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

减少评估CSS表达式的次数的一种方法是使用一次性表达式，其中第一次评估表达式时，它将style属性设置为显式值，该值替换CSS表达式。如果样式属性必须在页面的整个生命周期中动态设置，那么使用事件处理程序而不是CSS表达式是一种替代方法。如果必须使用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查找

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

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

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

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

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

顶部 | 讨论这个规则

缩小JavaScript和CSS

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

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

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

顶部 | 讨论这个规则

避免重定向

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

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

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

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

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

将旧网站连接到新网站是另一个常用的重定向。其他包括连接网站的不同部分并基于特定条件（浏览器的类型，用户帐户的类型等）指导用户。使用重定向连接两个网站很简单，只需要少量额外的编码。虽然在这些情况下使用重定向会降低开发人员的复杂性，但会降低用户体验。这种使用重定向方案包括使用与如果两个代码路径在同一台服务器上托管。如果一个域名的变化是使用重定向的原因，另一种是创建一个CNAME与组合（即创建从一个域名指向另一个别名DNS记录）或。

顶部 | 讨论这个规则

删除重复脚本

它损害性能，在一个页面中包含相同的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另一种方法是创建一个调用的函数。

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

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

顶部 | 讨论这个规则

配置ETag

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

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

稍后，如果浏览器有来验证组件，它使用头传回的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对于每个服务器是不同的。

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

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

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

FileETag无

顶部 | 讨论这个规则

使Ajax可缓存

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

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

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

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

顶部 | 讨论这个规则

尽早冲洗缓冲区

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

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

例：

... <！ -  css，js  - >    </ head>    

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

最佳

对AJAX请求使用GET

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

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

最佳

后负载组件

你可以仔细看看你的页面，问自己：“为了最初呈现页面绝对需要什么？其余的内容和组件可以等待。

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

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

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

最佳

预加载组件

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

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

最佳

减少DOM元素的数量

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

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

与布局有很大的帮助是YUI的CSS实用工具：grids.css可以帮助你的整体布局，fonts.css和reset.css可以帮助你剥去浏览器的默认格式。这是重新开始，想想你的标记，比如用一个机会，唯一的，当它是有意义的语义，而不是因为它呈现一个新行。

DOM元素的数量很容易测试，只需键入Firebug的控制台：

和多少DOM元素太多？检查其他具有良好标记的类似网页。例如，雅虎主页是一个非常繁忙的页面，并且仍然在700元素（HTML标签）。

最佳

跨域分割组件

拆分组件允许您最大化并行下载。请确保您使用的域名不超过2到4个，因为DNS查找会受到惩罚。例如，您可以承载你的HTML和动态内容 和之间的分裂静电元件和

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

最佳

最小化iframe的数量

Iframes允许在父文档中插入HTML文档。了解iframe如何工作以便有效使用非常重要。

 专业：

 缺点：

最佳

没有404s

HTTP请求是昂贵的，所以使得HTTP请求和获得无用的响应（即404未找到）是完全不必要的，将减慢用户体验，没有任何好处。

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

最佳

减少Cookie大小

HTTP cookie用于各种原因，例如身份验证和个性化。有关Cookie的信息在Web服务器和浏览器之间的HTTP标头中进行交换。保持Cookie的大小尽可能低，以尽可能减少对用户响应时间的影响非常重要。

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

最佳

对组件使用无Cookie的域

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

如果您的域名是，您可以承载你的静态组件上。但是，如果你已经在顶级域名设置cookie ，而不是，那么所有的请求，将包括这些cookie。在这种情况下，您可以购买一个全新的域，在那里托管您的静态组件，并保持此域无Cookie。雅虎使用，YouTube使用，亚马逊使用等。

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

最佳

最小化DOM访问

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

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

最佳

开发智能事件处理程序

有时，页面感觉不太灵敏，因为太多的事件处理程序附加到DOM树的不同元素，然后执行太频繁。这就是为什么使用事件代表团是一个不错的办法。如果你有一个内部的10个按钮，连接只有一个事件处理程序到div包装，而不是一个处理程序为每个按钮。事件冒泡，所以你可以抓住事件，弄清楚它源自哪个按钮。

你也不需要等待onload事件，以便开始使用DOM树做一些事情。通常你需要的是你想要访问的元素在树中可用。您不必等待所有图像下载。 是你可以考虑使用替代的onload事件，但直到它在所有浏览器可用，您可以使用YUI事件工具，它有一个方法。

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

最佳

选择<link> over @import

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

在IE浏览器的行为一样用在页面的底部，所以最好不要使用它。

最佳

避免过滤器

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

最好的办法是避免完全并使用优雅有辱人格的PNG8代替，这是在IE的罚款。如果你确实需要，使用下划线黑客以不惩罚你的IE7 +用户。

最佳

优化图像

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

最佳

优化CSS Sprites

最佳

不要缩放HTML中的图像

不要使用比你需要的更大的图像，因为你可以在HTML中设置宽度和高度。如果你需要
 
那么你的图像（mycat.jpg）应100x100px而不是缩小500x500px形象。

最佳

使favicon.ico小和可缓存

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

所以为了减少favicon.ico确保的缺点：

ImageMagick的可以帮助你创建favicon的小

最佳

保持组件低于25K

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

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

最佳

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

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

避免空图像src

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

1. 直的HTML
   

   <img src =“”>

2. JavaScript
   

   var img = new Image（）; 
   img.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属性的值不能为空字符串。

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

最佳