- A+
11 避免重定向 (Avoid Redirects)
tag:content
重定向结束于 301或302状态码。这里有一个301响应的HTTP头的例子：
浏览器会自动把用户转向Location域中指明的Url地址。HTTP头里包含了重定向所需的所有信息。响应的主体一般是空的。301或者302响应都不会被实际缓存，除非添加额外的头部，比如 Expires或者Cache- Control指明了它应该被缓存。meta refresh标签和JavaScript也可以将用户重定向到不同的URL，但如果你必须执行重定向，最好的方法是使用标准的3XX HTTP状态代码，以便使后退按钮工作正常。
需要谨记的是，重定向降低了用户体验。在用户和HTML文档之间插入的重定向延误了页面的呈现和组件下载，因为它们都不可能在获得HTML文档之前开始。
一种最浪费性能的重定向频繁发生而网络开发者们却往往没有意识到，那就是当地址中应当有一个左斜线（/）却没有的时候。比如，访问http://astrology.yahoo.com/astrology会导致一个301效应并重定向到http://astrology.yahoo.com/astrology/（注意这里加了一个左斜线）。在Apache中，这可以使用mod_rewrite,或者在Apache事件处理中使用DirectorySlash指令来修补。
使用重定向的另一个常见场景是连接旧网站和新网站。还包括连接网站的不同部分，或者在不同情况下（比如依据浏览器的类型，用户的类型等）重定向用户。使用重定向来连接两个网站很简单而且需要很少的额外代码。虽然在这些情况下使用重定向减少了开发者的麻烦，但却降低了用户体验。如果两部分在同一个服务器上，可以使用Alias 和rewrite来替代重定向。如果域名变更引起了重定向，可以创建一个CNAME（一种可以创建一个别名使一个域名指向另一个的DNS记录）结合 Alias 或者mod_rewrite来替代重定向。
12 移除重复的脚本 (Remove Duplicate Scripts)
tag:javascript
在同一个页面中包含两个相同的脚本文件降低了性能。这并不如你想象的那么罕见。在对美国十大网站中的检查中，发现它们中的两个包含了重复的脚本。有两个主要因素增加了一个页面包含两个相同脚本的几率——团队的大小和脚本的数量。当脚本被重复包含时，由于增加了不必要的HTTP请求和JavaScript的执行，影响了性能。
不必要的HTTP请求在IE中存在，而Firefox终没有。在IE中，如果一个外部脚本被包含了两次而且没有被缓存，在页面加载的过程中会产生两次HTTP请求。即使脚本被缓存了，当用户重载页面时，多余的HTTP请求也会发生。
产生多余的HTTP请求的同时，多次执行脚本也会浪费时间。在Firefox和IE中，无论是否被缓存，脚本都会被重复执行。
避免脚本被意外加载两次的一个方法是在你的模板系统中执行一个脚本管理模块。通常的方式是在HTML页面中使用SCRIPT标签来添加一个脚本：
<script type="text/javascript" src="menu_1.0.17.js"></script>
HP 中，可以选择创建一个叫做insertScript的方法：
<?php insertScript("menu.js") ?>
这个函数不仅仅能防止脚本被重复加载多次，还可以解决脚本的其他问题，比如独立性检测以及为脚本添加版本号码以应对far future Expires头部。
13 设定ETags (Configure ETags)
tag:server
实体标签（ETags）是服务器和浏览器用于确定浏览器中缓存的组件和服务器中的是否对应的一种机制。（"entity"是组件的另一种说法：图片、脚本、样式表等等）添加 ETags用于辨别组件提供了比单纯利用“最后修改时间”更为灵活的机制。ETag是一个唯一标识组件的特定版本的字符串。它的唯一格式规范是字符串必须被引号引用。来源服务器使用ETag响应头来设定一个组件的ETag：
当浏览器晚些时候需要检测一个组件时，它使用If-None-Match 头部把ETag传回来源服务器。如果ETag匹配了，会返回一个304状态码，在这个例子里它会减少12195个字节的响应：
ETag的问题是它们往往在网站的一个服务器中被设为唯一的，当浏览器从一个服务器得到了组件并在稍后试图到另一个服务器验证时，ETag会不匹配，而这在使用多个服务器来处理请求的网站中是很常见的。默认情况下，Apache和IIS在ETag中嵌入的数据戏剧性的减少了应用多台服务器的网站的ETag验证成功几率。
Apache1.3和2.新版本的ETag格式是inode-size- timestamp。虽然一个给定的文件在多台服务器中处于同一个目录，而且有同样的大小，权限，时间戳，但它的inode在不同服务器中是不同的。
IIS5.0和6.0有同样的问题。IIS中ETag的格式是Filetimestamp:ChangeNumber。 ChangeNumber用来跟踪IIS配置的改变次数。一个网站的所有IIS不可能有相同的ChangeNumber。
这导致的结果是，Apache和IIS对完全相同的组件产生的ETag在不同服务器间不能匹配。如果ETags不匹配，用户不会得到小而快的304响应，而是一个普通的200响应和组件的所有数据。如果你把你的网站放在了一个服务器里，这不会是一个问题。但如果你的网站有多台服务器，而且你使用了Apache和IIS 默认的ETag配置，你的用户会访问页面的速度会变慢，你的服务器加载的程度更高，消耗了更大的带宽，代理服务器不能有效的缓存你的内容。即使你的组件有一个ar future Expires头部，当用户重载或者刷新页面时，依然会发送一个GET请求。
如果你不打算利用ETags提供的灵活的验证模式，你最好把ETag统统移除。Last-Modified头部的验证方式给予组件的时间戳。移除ETag 同时减少响应和随后的请求中的HTTP头部大小。这篇微软的支持文档描述了怎样在IIS中移除 ETags。在Apache中，你只要在Apache配置文件中添加如下一行：
14 让Ajax可以缓存 (Make Ajax Cacheable)
tag:content
Ajax 的好处之一是它能给用户提供瞬间的响应，因为它从服务端异步请求数据。但Ajax不能保证用户在等候那些异步的JavaScript和XML响应返回时什么都不做。在应用程序中，用户是否继续等待取决于Ajax怎样应用。比如，在一个基于Web的Email客户端用户会等候Ajax返回他们所搜索的邮件信息。记住异步并不代表“即刻”。
为了提高性能，优化Ajax响应很重要。提高Ajax性能最重要的方式是使响应缓存，正如“添加一个过期期限和缓存控制头”这一节讨论的。这些原则同样适用于Ajax。
我们看一个例子。一个Web2，0的邮件客户端可能会用Ajax自动下载用户地址簿。如果用户从上次使用邮件网站以来没有修改她的地址簿，那么如果Ajax响应使用了长期失效时间或者缓存控制头部，地址簿就可以从缓存中读取出来。浏览器必须被告知“使用之前的缓存地址簿”而不是“请求一个新的地址簿”。可以在地址簿Ajax的URL中添加一个标识用户最后一次修改地址簿的时间戳，比如，&t=1190241612。如果地址簿从最后一次下载后没有被更改，时间戳将相同而地址簿将会从浏览器的缓存中得到来替代额外的HTTP传输。如果用户更改了她的地址簿，时间戳会保证新的URL不会和缓存中的匹配，而且浏览器会请求会请求更新的地址簿记录。
即使你的Ajax响应时动态创建的，而且只适用于一个用户，它们依然会被缓存。这样做会让你的Web2.0应用程序更快。
15 更早的刷新缓冲区 (Flush the Buffer Early)
tag:server
当用户请求一个页面，服务端会花费200至500毫秒的时间组合HTML页面。在这期间，浏览器会静静等待数据到来。PHP中有flush（）函数，它允许你向浏览器发送部分就绪的HTML响应，这样浏览器可以在服务器处理余下的HTML页面时去获取组件。这样的好处主要在忙碌的后台和轻松的前台间可以看到。
在HEAD后面是放置刷新操作的好地方，因为头部的HTML代码更容易产生，而且可以让你放置任何CSS和JavaScript文件，以便浏览器在后台工作依然进行时并行开始获取组件。
例子：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
Yahoo! search先行研究并且进行了真人测试证明了使用这项技术的好处。
16 在Ajax请求中使用GET方法 (Use GET for AJAX Requests)
tag:server
Yahoo! Mail 团队发现进行XMLHttpRequest的时候，POST方法在浏览器中分两步执行：先发送头部，然后发送数据。所以最好使用只发送一个TCP包（除非你有很多的cookie）的GET方法。IE中URL的最大长度是2000，所以如果你发送超过 2000的数据就不能使用GET方法。
一个有趣的现象是，POST方法并不像GET那样实际发送数据（而Get则名副其实）。基于 HTTP规范，GET方法意味着取回数据，所以当你只是请求数据时使用GET方法更为有意义（从语义上来说），而在发送需要储存在服务器端的数据时则相反使用POST。
17 后加载组件 (Post-load Components)
tag:content
你可以仔细端详下你的页面然后自问：“什么是在页面初始化时必须的？”那么其余的内容和组件可以放在后面。
JavaScript是理想的用来分割onload事件之前和之后的选择。例如你有执行拖放、下拉和动画的JavaScript代码和菜单，它们可以稍后加载，因为用户在初始呈现之后才会在页面上拖动元素。其他的可以被后加载的地方包括隐藏的内容（当用户做某项操作才会展现的内容）和被折叠的图片。
可以帮助你的工具有： YUI Image Loader能帮助你延缓加载折叠的图片，而且YUI Get utility 能够很简单的包装运行中的JS和CSS。比如，打开Firebug的网络选项卡去查看Yahoo! Home Page。
当性能指标和其它网站开发的好的实践一致时是不错的。渐进增强的观念告诉我们当支持JavaScript时，会提高用户体验，但你必须确保在没有JavaScript时页面也能工作。所以当你确保页面工作正常时，你会通过延后加载的那些更花哨的脚本比如拖放和动画，来增强你的页面。
18 预先加载组件 (Preload Components)
tag:content
预加载看起来和后加载原则是个矛盾，但它其实是为了另外一个目的。预加载组件让你可以利用浏览器的空闲时间来加载之后需要的组件（比如图片，样式表和脚本）。这样当用户浏览下一个页面的时候，大部分组件都已经在缓存里了而页面会加载的更快。
有几种预加载的类型：
19 减小DOM元素的数量 (Reduce the Number of DOM Elements)
tag:content
复杂的页面意味着更多的字节需要被下载而且也意味着在JavaScript中遍历DOM更慢。比如你在页面中添加一个事件，让它在500或者 5000个DOM元素中循环，它们的效率是不同的。
更多的DOM元素表明有些标签需要被改良而并不一定需要移除实际内容。你是否为了布局而使用繁琐的网一样的表格？你是否只是为了弥补一些布局的问题而使用了更多的div标签？也许还有更好和更符合语义的标签可以使用。
DOM 元素的数量很好检测，只要在Firebug的控制台里输入：
document.getElementsByTagName_r('*').length
那么多少DOM元素算多呢？查看下类似的使用较好的标签的页面。比如Yahoo! Home Page是一个很丰富的页面但只有700以下的DOM元素（HTML 标签）。
20 分域部署部件：Split Components Across Domains
tag：内容
将部件分割能使你获得最大的并行下载效率。但你同时需要注意不使用多于2~4个域名，以避免DNS查询导致的问题。例如，你可以将HTML内容和动态的组建放于 www.example.org域名下，将静态组件分别放于static1.example.org和static2.example.org之下。
查看Tenni Theurer和Patty Chi的"Maximizing Parallel Downloads in the Carpool Lane"获取更多关于并行下载的信息。
