聲明，本文中所稱CSS雪碧即為CSS Sprites，這個詞組一直沒有一個固定或者約定俗成的中文翻譯，一些人開始稱之為CSS雪碧，我們且當作一次嘗試吧，如果大家覺得不妥，今後還會繼續直稱CSS Sprites。 ——神飛
CSS雪碧已經出現一段時間了，並上升為一種可以讓你的網站速度變快的方式。 Steve Souders剛剛在Velocity ‘09上展示了SpriteMe! (討論——為什麼在你可以使用canvase和toDataURL和及時生成雪碧的時候還要使用CSS雪碧生成器或其它基於服務器的工具？）。然而，關於CSS雪碧有一些誤解，最主要的一個就是它們沒有缺點。
CSS雪碧的基本原理是把你的網站上用到的一些圖片整合到一張單獨的圖片中，從而減少你的網站的HTTP請求數量。該圖片使用CSS background和background-position屬性渲染(值得一提的是，這也就意味著你的標籤變得更加複雜了，圖片是在CSS中定義，而非<img>標籤)。
CSS雪碧的最大問題是內存使用。除非這個雪碧圖片是被非常小心的組織，你就會最終使用大量的無用的空白。我最喜歡的例子是來自於WHIT TV的網站，那裡的這張圖片用作精靈。注意這是一個1299×15,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雪碧的不足，歡迎提出來。
