Yahoo提高网站性能34条最佳实践四

 

杜绝404

HTTP请求的代价是比较大的，所以发一个没有响应的请求（如404）是极不必要的，除了让用户感到缓慢之外没有任何好处。

一些站点设计了友好的404页面，虽然有助于用户体验但依然浪费了服务器资源（如数据库等）。特别糟糕的一种情况：如果是一个外部的javascript链接出错并返回404，那么首先这个下载会阻塞其他并行下载，其次浏览器会把404响应的body体当作javascript代码来解析，尝试在里面找到一些有用的。

减少Cookie的体积

HTTP cookies被用来做身份认证，个性化等很多用途。cookie的信息在服务器和浏览器之间的交换是通过HTTP头部进行的。所以必须控制好cookie的体积来减少其对用户响应时间的冲击。

更多信息请看Tenni Theurer和Patty Chi的“When the Cookie Crumbles”。以下是这份研究的要点：

去除不必要的cookie

尽可能地减少cookie的尺寸来减少对客户端响应时间的冲击

准确地把cookie设置在一个适当的对应域名级别上，确保其他子域名不受影响

设定一个适当的过期时间。一个不会马上失效的cookie能够加速客户端的响应时间。

给不需要cookie的资源单独的域名

当浏览器请求一张静态的图片并同时发送一个cookie的时候，服务器并不需要这些cookie。因此带来了不必要的网络开销。你需要确保这些静态资源的请求不带cookie。为这些静态资源创建一个子域名。

如果你的域名是www.example.org你可以把你静态资源放在static.example.org 上，如果你已经在顶级域名example.org上设置了cookie，而不是www.example.org，那么所有的发往static.example.org的请求会被包含一个cookie。在这种情况下，你可以购买一个新的域名来放置这些静态资源。Yahoo!使用yimg.com，YouTube使用ytimg.com，Amazon使用images-amazon.com等等。

减少对DOM树的访问

用Javascript访问DOM元素是一个很慢的事情，你应该注意以下几点：

缓存DOM元素的引用。

“离线”地更新节点然后把它们添加到DOM树上。

（意思是如果你要用JS操作DOM达到改变结构/样式的目的，那么先在一个未被添加到document上的临时节点做完所有的事情，最后才把这个节点添加/替换到document上）

避免用Javascript去修正布局。

更多信息请看YUI理论部分Julien Lecomte写的“High Performance Ajax Applications”

设计良好的事件处理机制

有时候操作一些页面会感觉反应迟钝，因为页面上的元素被绑定了太多的事件处理，它们被触发的过于频繁，因此使用事件委托机制是一个好的方案。如果你在一个div里面有10个button，把事件绑定到div上而不是每一个button上。事件冒泡使你能够准确地捕捉到是哪个button被点击了。

你也不必为了需要操作DOM树而在onload上绑定事件，大多数情况你只需要操作在DOM树上可用的元素。因此你不必等待图片和其他资源下载完。

DOMContentLoaded是一个你应当考虑替换onload的事件。但在所有浏览器兼容这个事件之前，你可以使用YUI Event utility，这上面有一个onAvailable属性。（prototype的是自定义事件’dom:loaded’）

选择<link>标签而不是@import

之间讲到过CSS的一个良好实践是把所有的CSS文件放在文件的顶端来获得更好的渲染效果。在IE中@import表现的就像把CSS放在页面底部加载一样，所以最好不要去用它。

避免滤镜

IE的私有AlphaImageLoader滤镜是为了修正E7以前的版本中无法良好的支持PNG半透明的问题。这个滤镜的问题在于图片被下载完之前，它会阻止页面的渲染。同时也增加了每个DOM元素的内存消耗，而不单单是图片，因此问题被成倍地放大了。

最好的解决方案是彻底避免使用AlphaImageLoader，而用PNG8格式替代，此格式在IE（包括IE6）中能够良好的工作。如果你确实需要AlphaImageLoader，使用hack确保这个滤镜不会影响到IE7+的用户。

优化图片

设计师为网站设计了很多图片，在你把这些图片通过FTP上传到服务器之前还是可以优化一下。

你可以检查GIF图片是否用到了对应的颜色数量，imagemagick这个可以帮助你，使用以下命令：identify –verbose image.gif

如果你看到一张仅仅用了4种颜色的图片使用了256色的调色板，那么说明这里面还有改进的空间。

尝试把GIF转换成PNG格式看看是否减少了体积。要把这个养成一种习惯，开发者常常因为害怕浏览器的兼容性而不敢使用PNG，但这个已经是过去的事情了。唯一的问题是真色彩的PNG格式（GIF不是真色彩并且不支持多层透明）。因此所有GIF能做的，PNG8格式照样能做（除了GIF动画）。这是一个简单的转换命令：

Convert image.gif image.png

我们呼吁：给PNG一个机会！（哈哈）

使用pngcrush（或者其他任何PNG优化工具）为你所有的PNG图片优化。例如：

Pngcrush image.png –remalla –reduce –brute result.png

使用jpegtran 优化你所有的JPEG图片。这个工具用来对JEPG进行旋转等操作，同时也能用来对图片进行优化和去除注释等无用信息（如EXIF信息）。

jpegtran –copy none –potimize –perfect src.jpg dest.jpg

优化CSS Sprites

把图片水平分布代替垂直分布经常能起到减小图片体积的作用。

把类似颜色的图片组织到一个sprite里来保持较低的颜色数，比较好的做法是256色以下这样能匹配到PNG8格式。

对手机友好，不要在图片间留下巨大的间隙。减少图片的间隙不会减少太多文件体积，但它能够在解压图片成一个像素阵列（pixel map）的时候减少内存的开销。100X100的图片有一万像素，而1000X1000就有一百万像素。

不要在HTML里面缩放图片

不要因为你能够在HTML中重设图片的尺寸而使用超过你需要尺寸的图片。如果你需要一张100X100的图片，那么就使用一张实际尺寸等于100X100的图片而不是一张500X500的图片再缩小。

保持favicon.ico小巧，并被缓存

favicon.ico是一张放在服务器根目录下的图片。这是一个“邪恶”的需求，因为即使你不想用它，浏览器依然会请求，所以最好不要给它404的响应。同样因为处在同一服务器的缘故，每次请求的时候cookie都会被一起发送。这个图片还打乱了下载的顺序，例如在IE中如果你在onload事件中请求一个额外的资源，这玩艺会在额外资源之前被下载。

所以为了减轻favicon.ico带来的负担，确保：

它足够小，最好在1K以下。

把头部的Expire设置到一个合适的点（因为如果你没办法通过重命名的方式来更换一个ICO）。你可以把Expire设置为之后的几个月。你可以通过检查favicon.ico的上次修改时间来作出正确的决定（按照ico的更新频率来设置过期时间）。

Imagemagick可以帮助你制作出小巧的favicon。

保持（单个）资源在25K以下

这个约束建立在iPhone不缓存超过25K资源的基础上，注意25K是不经过压缩的大小。因为不能使用Gzip，所以压缩文件成了很重要的事情。

更多信息请看Wayne Shea和Tenni Theurer的“Performance Research, Part 5: iPhone Cacheability - Making it Stick”

把资源打包到一个复合文档（Multipart Document）中

把资源打包到一个复合文档中就好比一封带附件的email，它使得你能够通过一个HTTP请求来获得多个资源（记住：HTTP请求是很珍贵的）。当你使用这个技术的时候，最好先检查一下客户端是否支持（iPhone不支持）。