Best Practices for Speeding Up Your Web Site(6)

三十、

Optimize CSS Sprites

tag: images

优化CSS精灵

标签：图片

•   在CSS精灵中将你的图片水平放置而不是垂直放置通常会产生一个更小的文件大小。
• 结合相似颜色到同一个CSS精灵中帮助你降低颜色数，最理想的情况是256中颜色，来适合PNG8
• "移动设备友好的"并且在一个CSS精灵中不要在图片之间留出太大的缝隙。这不会过多影响文件大小但是用户代理会用较少的内存来将图片解压成像素图。100*100的图像是1万像素，1000*1000是一百万像素。

三十一、

Don't Scale Images in HTML

tag: images

不要在HTML中缩放图片

标签：图片

不要使用一个比你实际需要还大的图片，因为在HTML你可以设置高度和宽度。如果你需要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" /> 

那么你的图片（mycat.jpg）应该是100px*100px而不是一个缩放的500px*500px的图片。

三十二、

Make favicon.ico Small and Cacheable

tag: images

使 favicon.ico小且可缓存的

标签：图片

        favicon.ico是一张放置在你的服务器根下面的图片。它是个必须的“弊病”，因为尽管你并不在意它，浏览器仍就会请求它，所以最好不要用404 Not Found响应。同样由于在同一台服务器上，cookie在每次favicon.ico被请求也会被一起发送。这个图片同样会妨碍下载顺序，例如在IE中当你在onload中请求额外组件时，favicon.ico会在其它组件之前优先被下载。

        

        So to mitigate the drawbacks of having a favicon.ico make sure:

• It's small, preferably under 1K.
• Set Expires header with what you feel comfortable (since you cannot rename it if you decide to change it). You can probably safely set the Expires header a few months in the future. You can check the last modified date of your current favicon.ico to make an informed decision.

         Imagemagick can help you create small favicons 

        

三十三、

Keep Components under 25K

tag: mobile

保持组件小于25K

标签：移动设备

        该限制是基于这样一个事实，即iPhone不会缓存超过25K的组件。注意这是未压缩的大小。这就是缩小的重要性所在，因为单独的gzip是不能满足所有要求的。

 

        要获得更多信息，请查看由Wayne Shea 和 Tenni Theurer发表的 "Performance Research, Part 5: iPhone Cacheability - Making it Stick"

三十四、

Pack Components into a Multipart Document

tag: mobile

将组件打包成一个符合文档

标签：移动设备

        将组件打包到一个多文档中就像一封邮件附带附件一样，这会帮助你在一次HTTP请求（记住HTTP请求的代价是昂贵的）中获取多个组件。在你使用这项技术之前，首先要检查用户代理是否支持它（iPhone不支持）。

三十五、

Avoid Empty Image src

tag: server

避免Image标签的src空白

标签：服务器

src属性是空字符串的image标签常常在我们意料之外出现。它有以下两种形式：

        1、straight HTML

                <img src="">

        2、JavaScript

                var img = new Image();

                img.src = "";

两个形式都会导致相同的效果：浏览器会向服务器发出另一个请求。

• IE向页面所在目录下发出一个请求。
• Safari 和 Chrome会向实际的页面本身发出请求。
• Firefox 3 和其早期的版本的行为同Safari和Chrome，但是Firefox3.5处理了这个问题并且不再发送请求。
• Opera在遇到一个src为空的image标签时不做任何动作。

为什么该行为是不好的呢？

1、通过发送大量意外的通信量削弱了服务器，尤其是对于那些每天有成百上千综合浏览量的页面来说。

2、浪费了服务器的计算周期产生一个根本不会被访问的页面。

3、可能会损坏用户数据。如果你跟踪请求状态，无论是通过cookie还是其它方式，你很有可能遇到坏损的数据。尽管图片请求并不会返回 一个图片，但是所有的头部信息都会被浏览器接受和阅读，包含所有的cookie。然而剩下的响应数据却被丢弃，但是可能已经造成了损坏。

        这个行为的根源是URI是在浏览器中被解析的。该行为时在 RFC 3986 - Uniform Resource Identifiers中定义的。当一个空字符串被当做是URI时,它会被认为是一个相对URI并且会根据5.2章节中定义的算法进行解析。空字符串的具体的例子被列在了5，4章节中。 Firefox, Safari, 和 Chrome都会按照按照说明正确的解析空字符串，然而IE会非正常解析，这与先前的版本：RFC 2396 - Uniform Resource Identifiers （这已经在RFC 3986被废弃 ）保持一致。 所以从技术角度来说，浏览器都按照他们应该做的来解析相对URIs。问题是在这个情形下，空白字符串显然是无意义的。

        

        HTML5中，在4.8.2节中增加了最标签中src属性的描述来告之浏览器不要发送额外的请求。

        The src attribute must be present, and must contain a valid URL referencing a non-interactive, optionally animated,

        image resource that is neither paged nor scripted. If the base URI of the element is the same as the document's          address, then the src attribute's value must not be the empty string.

        希望在未来浏览器中不在有这个问题。不幸的是，还没有针对于<script src=""> 和 <link href="">类似的条款。可能仍旧有时间来做出调整以确保浏览器不会偶然间的实现这个动作。

这条规则是由Yahoo 的Javascript专家Nicolas C. Zakas。要获得更多信息，请查看他的文章" Empty image src can destroy your site"。

注：由于个人技术水平限制，十三和二十九并未翻译，感兴趣的朋友可以参见原文！