本文是作者調(diào)查Data URI在移動端性能表現(xiàn)的第三篇文章，第一二篇分別是：在移動平臺上，Data URI要比原鏈接慢6倍；Data URI性能：不要在Base64上指責(zé)它。下面是筆者對原文的翻譯。
大約一個月之前，我們做了一個研究，關(guān)于使用Data URI構(gòu)建Web組件性能不佳的研究。在發(fā)表調(diào)查結(jié)果后，來自Web性能社區(qū)的一個最為持久的問題也隨即顯現(xiàn)出來：
怎樣把Data URI和作為在頁面上減少HTTP請求數(shù)的CSS Sprites進行比較？
這個問題是引人深思的，在如今的Web設(shè)計中，Data URI在Web設(shè)計上的一種典型應(yīng)用方式就是替代Sprites，盡管這不是它的唯一用途：Data URI也可以被使用在其他資源上，如JavaScript。
在本文，我們將提供更多的背景知識來說明Data URI性能是一個非常重要的問題，一些實驗細(xì)節(jié)以及Data URI或CSS Sprites在移動端有哪些更好地表現(xiàn)。
關(guān)于CSS Sprites
CSS Sprites是由CSS Zen Garden和Mobify用戶體驗副總裁Dave Shea在2004年引進的一項圖像管理技術(shù)。CSS Sprites提供了一種非常巧妙的方式把多張圖片合并成一張。利用CSS Sprites能很好地減少了網(wǎng)頁的HTTP請求，從而大大的提高了頁面的性能，這也是CSS Sprites最大的優(yōu)點。
右圖是一張圖片，而通過下面的代碼，你可以分別使用圖中的三個部分。
運行結(jié)果（備注：該例子來自w3schools）：http://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_nav
關(guān)于Data URI
Data URI的官方名稱叫Data URI Scheme，開發(fā)者可以使用它把圖像的內(nèi)容直接嵌入到網(wǎng)頁里，減少HTTP 請求 (http request) 的次數(shù)，優(yōu)化網(wǎng)頁。（該部分內(nèi)容摘自：）
通常，把圖像在網(wǎng)頁上顯示出來的標(biāo)準(zhǔn)方式是這樣：
同樣的效果，使用Data URI可以寫成：
為什么要對Data URI性能進行研究？僅僅是因為細(xì)節(jié)嗎？
不！事實證明，使用Data URI和另一種技術(shù)可以輕易低于100ms這個交互體驗預(yù)算，用戶體驗大師Jakob Nielson對用戶體驗交互進行了預(yù)算，而100ms是用戶是否感覺交互反應(yīng)慢的界限。
在研究過程中，我們的團隊發(fā)現(xiàn)Data URI在手機上的性能表現(xiàn)與桌面端并不匹配，之所以會導(dǎo)致性能差，主要是把實例化的JavaScript實體作為Data URI，而不是文本節(jié)點內(nèi)部的腳本元素。
但沒人能夠解釋Data URI的這種表現(xiàn)，為什么base64應(yīng)該創(chuàng)建更多額外的負(fù)載。于是，我們開始調(diào)查這一問題是不是特定于JavaScript或者在使用Data URI的Web資源時，還存在一般的其它性能問題。
Data URI性能對Web設(shè)計師是非常重要的，它也是Web應(yīng)用程序開發(fā)者最小化HTTP請求的最佳實踐。Data URI通常被用在貫徹整個網(wǎng)站的較小圖片上，但據(jù)我所知，目前還沒有任何指導(dǎo)提供給設(shè)計師，告訴他們在一個頁面里使用Data URI的size和資源數(shù)量上限。
從更廣闊的背景來看，像Google Chrome團隊、Apple Safari團隊、Firefox團隊、WebKit開發(fā)者以及微軟的IE團隊一直在致力于構(gòu)建更快的瀏覽器，而對于Web開發(fā)者來說還遠(yuǎn)遠(yuǎn)不夠。因此，開發(fā)人員了解不同的性能概況技術(shù)是非常重要的，這樣他們才能正確的應(yīng)用。
雖然瀏覽器給我們提供了一個抽象的環(huán)境，并且免費幫大家實現(xiàn)了許多細(xì)節(jié)，但仍然有許多瀏覽器行為需要開發(fā)者去了解，尤其當(dāng)我們設(shè)計一個友好的移動網(wǎng)站時，在不到一秒的時間內(nèi)就要將所有的內(nèi)容渲染出來。
實驗方法
為了回答以上問題，我們對它們第一次加載（沒有緩存）所用時間以及一旦瀏覽器存在緩存，它們所表現(xiàn)出的性能差異有哪些都非常感興趣，我們盡可能模擬非常真實的場景進行試驗。我們選了互聯(lián)網(wǎng)上最大的電子商務(wù)網(wǎng)站：Amazon.com的actual sprite來試驗，該sprite將近25KB，并且包含39張獨立的圖片。
創(chuàng)建兩個HTML塊，并且放在iframe中進行加載。第一個iframe里包含CSS來指定sprite文件的位置和作為背景圖片的每個獨立sprite布局的偏移量；第二個iframe針對相同的圖片內(nèi)嵌了base64編碼Data URI。Sprite condition iframe HTML、Data URI condition iframe HTML分別是兩個iframe的測試鏈接。
在iframe被實例化之前，立即啟動性能測量（當(dāng)src=attribute被分配）以及當(dāng)iframe加載事件被觸發(fā)時再馬上結(jié)束。由于iOS平臺上沒有導(dǎo)航計時API，時間分辨率對精確到毫秒的日期對象是有限制的，但考慮到性能的巨大落差，它足以應(yīng)付此次的測試了。
這次試驗主要測試了緩存和沒有緩存條件下的Data URI和Sprite表現(xiàn)，總共有4個條件，每個條件都是在一個獨立的iframe里執(zhí)行。Data URI和CSS Sprites條件都是進行隨機分配的，但是每個緩存測試條件都是在未緩存的測試完成后立即啟動的。這是通過使用一個帶有父窗口的單獨iframe使緩存和沒有緩存的條件保持一致。在所有的資源中包括所有條件下的iframe HTML內(nèi)容以及CSS Sprites里都使用了cache-controlt頭：
共收集了280個樣本進行了分析。
結(jié)果&總結(jié)
值得注意的是，CSS Sprites在沒有緩存的所有瀏覽器上比Data URI明顯快了幾百毫秒，這盡管是事實，但不得不提的是，CSS Sprites實際上需要額外的鏈接并且還會帶來所有相關(guān)的鏈接開銷，包括TCP慢啟動。
從結(jié)果中我們可以發(fā)現(xiàn)，緩存條件下，Android 4.2和iOS 6的CSS Sprites大概有2倍的性能提升，不同的是，iOS條件下減少了220ms，而Android 4.2在原生瀏覽器下減少了70ms。Chrome和Firefox在Android上要表現(xiàn)的好點，在CSS Sprites情況下有50%或60ms的性能差異。
記住，這僅僅是對一個25KB的Sprite所進行的測試，你可以看到在兩種條件下顯著的性能差異。一般來說，除了給每個單獨的圖像固定成本外，性能還是對Sprite圖像尺寸收集的一個功能。如果你將大量的圖片和腳本移到Data URI中，那么，對性能的影響將會更加顯著。
基于這個研究，我建議開發(fā)者限制Data URI在較小資源上的使用，并且不要在CSS或內(nèi)聯(lián)HTML里多次使用。15-20KB已是Data URI的最大尺寸了。對于移動來說，不超過3-5個實例已是最好的經(jīng)驗法則了。
via：Mobify
