Best Practices for Speeding Up Your Web Site(6)

三10、

Optimize CSS Sprites

tag: images

优化CSS精灵

标签：图片

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

三11、

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的图片。

三12、

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 

        

三十3、

Keep Components under 25K

tag: mobile

保持组件小于25K

标签：移动设备

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

 

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

三十4、

Pack Components into a Multipart Document

tag: mobile

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

标签：移动设备

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

三十5、

Avoid Empty Image src

tag: server

避免Image标签的src空白

标签：服务器

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

        一、straight HTML

                <img src="">

        二、JavaScript

                var img = new Image();

                img.src = "";

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

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

为何该行为是很差的呢？

一、经过发送大量意外的通讯量削弱了服务器，尤为是对于那些天天有成百上千综合浏览量的页面来讲。

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

三、可能会损坏用户数据。若是你跟踪请求状态，不管是经过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"。

注：因为我的技术水平限制，十三和二十九并未翻译，感兴趣的朋友能够参见原文！