CSS雪碧的基本原理是把你的网站上用到的一些图片整合到一张单独的图片中，从而减少网站的HTTP请求数量，降低服务器压力，同时提高了页面的加载速度，节约服务器的流量。
优点
- 减少加载网页图片时对服务器的请求次数
可以合并多数背景图片和小图标，方便在任何位置使用，这样不同位置的请求只需要调用一个图片，从而减少对服务器的请求次数，降低服务器压力，同时提高了页面的加载速度，节约服务器的流量。 - 提高页面的加载速度
sprite 技术的其中一个好处是图片的加载时间(在有许多 sprite 时，单张图片的加载时间)。由所需图片拼成的一张 GIF 图片的尺寸会明显小于所有图片拼合前的大小。单张的 GIF 只有相关的一个色表，而单独分割的每一张 GIF 都有自己的一个色表，这就增加了总体的大小。因此，单独的一张 JPEG 或者 PNG sprite 在大小上非常可能比把一张图分成多张得来的图片总尺寸小。 - 减少鼠标滑过的一些bug
IE6不会主动预加载鼠标滑过即a:hover中的背景图片，所以，如果使用多张图片，鼠标滑过会出现闪白的现象。使用CSS雪碧，由于一张图片即可，所以不会出现这种现象。
不足
- CSS雪碧的最大问题是内存使用
除非这个雪碧图片是被非常小心的组织，你就会最终使用大量的无用的空白。一个例子是来自于WHIT TV的网站。注意这是一个1299×15,000像素的PNG图片。它也被压缩的很好——实际下载大小只有大概26K — 但是浏览器并不会渲染压缩后的图片数据。当这个图片被下载并被解压缩之后，它将占用差不多75MB的内存 (1299 * 15000 * 4)。如果这个图片并没有使用alpha透明，它将会被优化至1299 * 15000 * 3，但是要在损失渲染速度的情况下。即使那样，我们也会讨论55MB。这张图片的大部分其实就是空白，那里什么都没有，没没有任何有用的内容。只是加载 WHIT主页 就会导致你的浏览器的内存占用上升到至少75+MB，仅仅是因为那一张图片。（PS:遗憾的是，该网站最近已经改版，文中提到的图片已经不存在了） - 影响浏览器的缩放功能
如果一个使用CSS雪碧的页面使用一些浏览器提供的整页缩放功能缩放了，浏览器就需要做一些额外的工作来纠正这些图片边缘的行为——基本上来说，是为了避免雪碧中相邻的图片被“露进来”。这对于小图片没有什么问题，但是对于大图片会是一个性能下降。 - 拼图维护比较麻烦
拼合这么多图片，需要耐心。同时还要时刻思考如何在使用这个图片是不会产生相互的影响。将又瘦又高的图片和又宽又矮的图片放到一起时，不容易操作。如果要修改雪碧中的一个图片，你就要修改整张图片，这无疑会增大工作量。 - 使CSS的编写变得困难
如果CSS雪碧足够复杂，则大大增加了CSS的代码量和难度，让维护和修改变得困难起来。 - CSS 雪碧调用的图片不能被打印
CSS 雪碧调用的图片不能被打印，除非在@media中特别添加 print声明。 - 错误得使用 Sprites 影响可访问性
一些刚入门的开发人员会为了节省 HTTP 请求数(这是使用 CSS Sprite 一直强调的好处)而把所有的图片都当背景图片来处理 – 甚至是那些传达重要信息的图片。结果会导致一个缺乏可访问性的网站，也会降低 HTML 中 title 和 alt 的潜在益处。
因此，CSS sprite 本身没错，而且也不会引发可访问性问题(事实上，正确得使用会提高可访问性)。但是不分对错得过度使用 sprite 会阻碍具有可访问性和生产率方面的网页建设进程。
