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"。

注：因爲我的技術水平限制，十三和二十九並未翻譯，感興趣的朋友能夠參見原文！