原文：CSS雪碧:要還是不要？
譯自：To Sprite Or Not To Sprite
聲明，本文所稱CSS雪碧即為CSS Sprites ，這個詞組一直沒有一個固定或約定俗成的中文翻譯，有些人開始稱之為CSS雪碧，我們且當作一次嘗試吧，如果大家覺得不妥，今後還會繼續直稱CSS Sprites。神飛(vocal)
CSS雪碧已經出現一段時間了，並且上升為一種可以讓你的網站速度變快的方式。 Steve Souders剛剛在Velocity 09上展示了SpriteMe! (討論為什麼在你可以使用canvase和toDataURL和及時生成雪碧的時候還要使用CSS雪碧生成器或其它基於伺服器的工具？）。然而，關於CSS雪碧有一些誤解，最主要的一個就是它們沒有缺點。
CSS雪碧的基本原理是把你的網站上用到的一些圖片整合到一張單獨的圖片中，從而減少你的網站的HTTP請求數量。該圖片使用CSS background和background-position屬性渲染(值得一提的是，這也意味著你的標籤變得更加複雜了，圖片是在CSS中定義，而非<img>標籤)。
CSS雪碧的最大問題是記憶體使用。除非這個雪碧圖片是被非常小心的組織，你最終會使用大量的無用的空白。我最喜歡的例子是來自於WHIT TV的網站，那裡的這張圖片 用作精靈。注意這是一個129915,000像素的PNG圖片。它也被壓縮的很好實際下載大小只有大概26K — 但是瀏覽器並不會渲染壓縮後的圖片資料。當這張圖片被下載並被解壓縮之後，它將佔用差不多75MB的記憶體(1299 * 15000 * 4)。如果這張圖片並沒有使用alpha透明，它將會被優化至1299 * 15000 * 3，但是要在損失渲染速度的情況下。即使那樣，我們也會討論55MB。這張圖片的大部分其實就是空白，那裡什麼都沒有，沒沒有任何有用的內容。只是載入WHIT主頁就會導致你的瀏覽器的記憶體佔用上升到至少75+MB，只是因為那一張圖片。 （ PS:遺憾的是，該網站最近已經改版，文中提到的圖片已經不存在了）
有利於網站的正確的取捨並不存在。
另外一個(雖然並沒有那麼重要)不足就是如果一個使用CSS雪碧的頁面使用一些瀏覽器提供的整頁縮放功能縮放了，瀏覽器就需要做一些額外的工作來糾正這些圖片邊緣的行為基本上來說，是為了避免雪碧中相鄰的圖片被露出來。這對於小圖片沒有什麼問題，但是對於大圖片會是一個效能下降。
當然有一些顯示CSS 雪碧的明顯的好處的例子，主要的例子就是合併一批相同大小的圖片到一個檔案。例如，一系列用作標識你的網站中的很多東西的16×16圖標，或者是一些用作分類的頭之類的32*32 的圖標。但是整合嚴重不同尺寸的圖片，特別是將又瘦又高的圖片和又寬又矮的圖片放到一起從來不是什麼好主意。
然而，CSS雪碧確實提高頁面載入時間(至少在初始的頁面載入中在後續的頁面載入中，瀏覽器就將圖片快取了)。有沒有什麼可以取代的？不幸的是，還沒有一個可以取代的方案。很多瀏覽器開始支援離線清單了，將其擴展到允許下載一個包含一系列資源和對應的URL的清單的文件(比如一個jar/zip檔)或許是有可能的。但是任何此類做法在一段時間內還不會見到……
所以，在決定是否要使用CSS雪碧的時候，要注意在最初頁面載入效能之外還有很多的因素。作為一個普通的經驗法則，如果你的CSS 雪碧的大部分地方不包含真正的圖片內容，你應該相應的避免使用它。同樣，關注將來可能出現的既保持頁面載入速度，同時注意避免記憶體的缺陷和雪碧的效能影響。
其它的CSS雪碧的不足
以下是一些網友在該文評論中提到的CSS雪碧的某些不足：
CSS 雪碧呼叫的圖片不能被列印，除非在@media中特別加入print聲明by RichB
如果要修改雪碧中的一張圖片，你就要修改整張圖片，這無疑會增大工作量by Tom B
如果你在使用的過程中，有發現其它的CSS雪碧的不足，歡迎提出來。