移動端效能大比拼：CSS Sprites vs. Data URI

　　本文是作者調查Data URI在移動端效能表現的第三篇文章，第一二篇分別是：在移動平臺上，Data URI要比原連結慢6倍；Data URI效能：不要在Base64上指責它。下面是筆者對原文的翻譯。

　　大約一個月之前，我們做了一個研究，關於使用Data URI構建Web元件效能不佳的研究。在發表調查結果後，來自Web效能社群的一個最為持久的問題也隨即顯現出來：

 怎樣把Data URI和作為在頁面上減少HTTP請求數的CSS Sprites進行比較？

　　這個問題是引人深思的，在如今的Web設計中，Data URI在Web設計上的一種典型應用方式就是替代Sprites，儘管這不是它的唯一用途：Data URI也可以被使用在其他資源上，如JavaScript。

　　在本文，我們將提供更多的背景知識來說明Data URI效能是一個非常重要的問題，一些實驗細節以及Data URI或CSS Sprites在移動端有哪些更好地表現。

　　關於CSS Sprites

　　CSS Sprites是由CSS Zen Garden和Mobify使用者體驗副總裁Dave Shea在2004年引進的一項影像管理技術。CSS Sprites提供了一種非常巧妙的方式把多張圖片合併成一張。利用CSS Sprites能很好地減少了網頁的HTTP請求，從而大大的提高了頁面的效能，這也是CSS Sprites最大的優點。

　　下圖是一張圖片，而通過下面的程式碼，你可以分別使用圖中的三個部分。

#home{left:0px;width:46px;}
#home{background:url('img_navsprites.gif') 0 0;}

#prev{left:63px;width:43px;}
#prev{background:url('img_navsprites.gif') -47px 0;}

#next{left:129px;width:43px;}
#next{background:url('img_navsprites.gif') -91px 0;}

　　執行結果（備註：該例子來自w3schools）：http://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_nav

　　關於Data URI

　　Data URI的官方名稱叫Data URI Scheme，開發者可以使用它把影像的內容直接嵌入到網頁裡，減少HTTP 請求 (http request) 的次數，優化網頁。（該部分內容摘自：Sjolzy'blog）

　　通常，把影像在網頁上顯示出來的標準方式是這樣：

<img src="http://sjolzy.cn/images/A.png"/>

　　同樣的效果，使用Data URI可以寫成：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAADCAIAAAA
7ljmRAAAAGElEQVQIW2P4DwcMDAxAfBvMAhEQMYgcACEHG8ELxtbPAAAAAElFTkSuQmCC" />

　　為什麼要對Data URI效能進行研究？僅僅是因為細節嗎？

　　不！事實證明，使用Data URI和另一種技術可以輕易低於100ms這個互動體驗預算，使用者體驗大師Jakob Nielson對使用者體驗互動進行了預算，而100ms是使用者是否感覺互動反應慢的界限。

　　在研究過程中，我們的團隊發現Data URI在手機上的效能表現與桌面端並不匹配，之所以會導致效能差，主要是把例項化的JavaScript實體作為Data URI，而不是文字節點內部的指令碼元素。

　　但沒人能夠解釋Data URI的這種表現，為什麼base64應該建立更多額外的負載。於是，我們開始調查這一問題是不是特定於JavaScript或者在使用Data URI的Web資源時，還存在一般的其它效能問題。

　　Data URI效能對Web設計師是非常重要的，它也是Web應用程式開發者最小化HTTP請求的最佳實踐。Data URI通常被用在貫徹整個網站的較小圖片上，但據我所知，目前還沒有任何指導提供給設計師，告訴他們在一個頁面裡使用Data URI的size和資源數量上限。

　　從更廣闊的背景來看，像Google Chrome團隊、Apple Safari團隊、Firefox團隊、WebKit開發者以及微軟的IE團隊一直在致力於構建更快的瀏覽器，而對於Web開發者來說還遠遠不夠。因此，開發人員瞭解不同的效能概況技術是非常重要的，這樣他們才能正確的應用。

　　雖然瀏覽器給我們提供了一個抽象的環境，並且免費幫大家實現了許多細節，但仍然有許多瀏覽器行為需要開發者去了解，尤其當我們設計一個友好的移動網站時，在不到一秒的時間內就要將所有的內容渲染出來。

　　實驗方法

　　為了回答以上問題，我們對它們第一次載入（沒有快取）所用時間以及一旦瀏覽器存在快取，它們所表現出的效能差異有哪些都非常感興趣，我們儘可能模擬非常真實的場景進行試驗。我們選了網際網路上最大的電子商務網站：Amazon.com的actual sprite來試驗，該sprite將近25KB，並且包含39張獨立的圖片。

　　建立兩個HTML塊，並且放在iframe中進行載入。第一個iframe裡包含CSS來指定sprite檔案的位置和作為背景圖片的每個獨立sprite佈局的偏移量；第二個iframe針對相同的圖片內嵌了base64編碼Data URI。Sprite condition iframe HTML、Data URI condition iframe HTML分別是兩個iframe的測試連結。

　　在iframe被例項化之前，立即啟動效能測量（當src=attribute被分配）以及當iframe載入事件被觸發時再馬上結束。由於iOS平臺上沒有導航計時API，時間解析度對精確到毫秒的日期物件是有限制的，但考慮到效能的巨大落差，它足以應付此次的測試了。

　　這次試驗主要測試了快取和沒有快取條件下的Data URI和Sprite表現，總共有4個條件，每個條件都是在一個獨立的iframe裡執行。Data URI和CSS Sprites條件都是進行隨機分配的，但是每個快取測試條件都是在未快取的測試完成後立即啟動的。這是通過使用一個帶有父視窗的單獨iframe使快取和沒有快取的條件保持一致。在所有的資源中包括所有條件下的iframe HTML內容以及CSS Sprites裡都使用了cache-controlt頭：

 Cache-Control: public, max-age=2592000

　　共收集了280個樣本進行了分析。

　　結果&總結

　　值得注意的是，CSS Sprites在沒有快取的所有瀏覽器上比Data URI明顯快了幾百毫秒，這儘管是事實，但不得不提的是，CSS Sprites實際上需要額外的連結並且還會帶來所有相關的連結開銷，包括TCP慢啟動。

　　從結果中我們可以發現，快取條件下，Android 4.2和iOS 6的CSS Sprites大概有2倍的效能提升，不同的是，iOS條件下減少了220ms，而Android 4.2在原生瀏覽器下減少了70ms。Chrome和Firefox在Android上要表現的好點，在CSS Sprites情況下有50%或60ms的效能差異。

　　記住，這僅僅是對一個25KB的Sprite所進行的測試，你可以看到在兩種條件下顯著的效能差異。一般來說，除了給每個單獨的影像固定成本外，效能還是對Sprite影像尺寸收集的一個功能。如果你將大量的圖片和指令碼移到Data URI中，那麼，對效能的影響將會更加顯著。

　　基於這個研究，我建議開發者限制Data URI在較小資源上的使用，並且不要在CSS或內聯HTML裡多次使用。15-20KB已是Data URI的最大尺寸了。對於移動來說，不超過3-5個例項已是最好的經驗法則了。

　　英文來自：Mobify