CSS雪碧:要还是不要？

声明，本文中所称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雪碧的某些不足：

• CSS 雪碧调用的图片不能被打印，除非在@media中特别添加 print声明——by RichB
• 如果要修改雪碧中的一个图片，你就要修改整张图片，这无疑会增大工作量——by Tom B

如果你在使用的过程中，有发现其它的CSS雪碧的不足，欢迎提出来。

---

原文： CSS雪碧:要还是不要？
译自： To Sprite Or Not To Sprite