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

csdn發表於2013-09-25

  本文是作者調查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 HTMLData 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 vs. Data URI

  值得注意的是,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

相關文章