CSS Sprite的優缺點分析

　　目前大多數的開發人員對這個技術都有至關地掌握，也有不少關於它的教程和文章。幾乎全部的文章中都宣稱設計師和開發人員都應該使用 CSS sprite 來減小 HTTP 請求數，而且節省一些流量。這個技術被大量網站使用，包括使用了大型 sprite 的 Amazon .

　　可是這些被普遍熱議的好處真的是值得的嗎？設計師們是否在沒有全面考慮到全部狀況的狀況下，在盲目地使用這個技術呢？設計師們是否是過於關注 CSS sprite 的流行，而忽略了其它應該仔細斟酌的因素了呢？ 這篇文章會討論下使用 CSS sprite 的好處和壞處，尤爲關注」濫用」 sprites 的狀況，並且會解釋下爲何「濫用」 sprite 實際上是浪費時間。

瀏覽器緩存全部圖片

　　sprite 技術的其中一個好處是圖片的加載時間(在有許多 sprite 時，單張圖片的加載時間)。由所需圖片拼成的一張 GIF 圖片的尺寸會明顯小於全部圖片拼合前的大小。單張的 GIF 只有相關的一個色表，而單獨分割的每一張 GIF 都有本身的一個色表，這就增長了整體的大小。所以，單獨的一張 JPEG 或者 PNG sprite 在大小上很是可能比把一張圖分紅多張得來的圖片總尺寸小。可是這真的有想象的那麼好嗎？

通常來講，瀏覽器會緩存全部的圖片 – 不管圖片 sprite 與否。sprite 技術只是在頁面第一次加載的時候纔會節省帶寬，同時緩存也會對使用相同圖片的其餘頁面有效。

　　Firefox 緩存顯示的瀏覽器緩存的來自 amazon.com 的圖片(在 Firefox 地址欄輸入 「about:cache」 來查看)。

　　考慮到如今的廣泛網速已經比 2003-2004 年時提出這個技術的時候要快多了，所以大量使用 sprite 技術就不是那麼必要了。有一點須要明確，不是說不該該用 sprite，而是不該該爲了有限的好處來濫用這個技術。

拼合圖片的時間成本會增長

　　想象一下一個有三個狀態的圖片按鈕是怎麼製做的：表明不一樣的狀態的圖片須要臨近放置在一塊兒組成一張圖片。在使用 Photoshop 或其餘軟件切圖時，不一樣的狀態並不會在一塊兒；須要把他們單獨切出來再合併爲一張圖片。

　　若是其中任一個圖片狀態須要改變，整個圖片就須要從新制做保存。對一些設計師來講這不是什麼問題，也許他們會單獨保留不一樣按鈕狀態的源文件，這樣須要合併的時候就簡單了。可是這個過程有點複雜，遠沒有切出一個單獨圖片來的簡單。

　　爲了節省幾 k 的流量和幾個服務器請求(還只發生在第一次加載頁面時)，sprite 技術是否真的值得？

編碼和維護的時間成本會增長

　　圖片切片輸出以後，麻煩依然存在。雖然習慣這個過程以後，按鈕 sprite 能夠很簡單地編碼到 CSS 中，可是其餘的 sprites 就不這麼簡單了。

　　單一的一個按鈕通常會是個有定寬的 <ul> 元素。假如按鈕的 sprite 是彼此獨立的，就比較簡單：<ul> 的寬高會和列表項和錨點的寬高一致，每一個狀態的 sprite 對齊擺放。sprite 的位置也能夠很容易地根據每一個按鈕的寬高計算出來。

　　可是遇到以前提到的，像 Amazon 或者 Google 用到的大型 sprite 的狀況時，會怎麼樣呢？你能想象到到維護這麼一個文件，而且在 CSS 中改變 sprite 項的位置會是什麼樣嗎？還有第一次建立 CSS 代碼的狀況？相對於一個能夠輕鬆計算出來狀態位置的簡單按鈕來講，大型的 sprite 會致使無盡地測試和圖片狀態的從新擺放。

　　一些用於定位 Google 的 sprite 圖片的樣式

　　Amazon 的 sprites 確實節省了至少 30 個 HTTP 鏈接，性能方面也確實有了很大的提升。可是把這些好處拿來和開發以及維護成本作個比較，再把緩存和網速等因素考慮進來，決定使用如此大型的 sprites 也許就不那麼使人信服了。

Sprites 是否真的須要「維護」？

　　固然了，有些人不以爲 sprite 是首要引發頭疼的問題。大部分狀況下，一個 sprite 建立並編碼完以後，就不多會被改動了，也不會受進行中的網站維護的影響。假如你感受 sprite 維護不是個問題的話，那麼也許使用大型 sprite 是最好的選擇。

不是全部圖片都是背景

　　另外一個不提倡濫用 CSS sprite 的理由是這會致使開發人員錯誤地使用背景圖片。有經驗的開發人員會在項目中考慮可訪問性問題，他們明白並非每一個圖片都是背景。背景圖片應該留給按鈕以及用來裝飾元素，而用來傳達重要信息的圖像應該內聯在 XHTML 中。

　　Amazon 正確是使用了內聯圖像元素和裝飾用的背景。

錯誤得使用 Sprites 影響可訪問性

　　一些剛入門的開發人員會爲了節省 HTTP 請求數(這是使用 CSS Sprite 一直強調的好處)而把全部的圖片都當背景圖片來處理 – 甚至是那些傳達重要信息的圖片。結果會致使一個缺少可訪問性的網站，也會下降 HTML 中 title 和 alt 的潛在益處。

　　所以，CSS sprite 自己沒錯，並且也不會引起可訪問性問題(事實上，正確得使用會提升可訪問性)。可是不分對錯得過分使用 sprite 會阻礙具備可訪問性和生產率方面的網頁建設進程。

HTTP 請求數又如何？

　　許多人會力排衆議，改善網站性能最重要的部分就是減小 HTTP 請求數。也要知道一項研究代表一個網站平常的訪問者中 40-60% 比例都是沒有瀏覽器緩存的。這是否足以說明應該在全部狀況下使用大型 sprites 呢？或許是這樣。尤爲是考慮到用戶的首次來訪對一個網站的重要性。

　　Firefox 的 YSlow 插件顯示 HTTP 請求數

　　以往的瀏覽器通常只容許 2 個併發 HTTP 鏈接，3.0 版本以來的 Firefox 和 IE8 默認容許 6 個併發 HTTP 鏈接。這意味着每臺服務器有 6 個併發鏈接。引用 Steve Souders 的話：

　　「明白這是服務器的基礎是很重要的。使用多個域名，如 1.mydomain.com, 2.mydomain.com, 3.mydomain.com, 等等，使開發人員能夠徹底利用服務器鏈接數。在全部域名是同一 IP 地址的 CNAME 時依然有效。」

　　所以，或許在按鈕狀態以外使用 CSS sprites 也是有益的，在將來，隨着網絡鏈接速度的加快和新版瀏覽器的性能提高，使用大型 sprites 所帶來的好處將會變得不值一提。

那些 Sprites 生成器呢？

　　另外一個喜好大型 sprite 的理由是能夠利用一些 sprite 生成器來簡單得生成 sprite。對此類工具的詳細討論和評測不在本文討論範圍。可是從做者對此類工具的研究來看，幫助很是有限，而且維護這些 sprites 同樣須要可觀的工做量，這也是須要和收益權衡的。

　　有些工具，例如來自 Fondue 項目的這個，提供輸出 CSS 選項。Steve Souders’ 的工具 SpriteMe 是另外一個提供 CSS 編碼選項的。SpriteMe 會把現有的網站背景圖片轉換成單張 sprite 圖片（我以前提到的「大型」 sprite）並提供下載以供編碼入頁面之中。然而這些工具只是有助於建立 sprite，並不能在維護方面提供多少幫助。Souder 的工具貌似對從新設計或佈局的網站無效，並且只對那些現有的沒有使用 sprite 方法的網站有用。

　　能夠改進現有的工具，並且將來也會有新的工具出現。可是，鑑於以上提到的這些缺點，是否還存在這種可能，就是開發人員依然把精力集中在有限的所得上？

關注多個性能提高點

　　上面提到，HTTP 請求數是提高網站性能須要考慮的一個很是重要的因素。可是有別的方法能夠減小鏈接數，包括合併腳本和樣式表，使用遠程庫文件（即便用 Google 或者 Yahoo！提供的庫文件託管）。

　　除了 HTTP 請求數以外還有不少開發人員能夠關注的用於提高網站性能的因素。包括服務器啓用 Gzip，正確的放置外鏈腳本，優化 CSS 語法，壓縮較大的 JavaScript 文件，提高 Ajax 性能，避免使用已知的會引發性能問題的 JavaScript 語法，等等。

　　YSlow 顯示了 HTTP 請求數以外能夠提高網站性能的因素

　　若是開發人員花點時間來考慮下全部能夠提高網站性能的因素，再權衡下利弊，也許就有較好的理由能夠避免濫用 CSS sprite 了，而且會把精力放在那些物有所值的方面。

 

原文來自：http://www.jb51.net/css/25893.html