不要滥用雪碧图sprite

使用雪碧图的优点：

减少加载网页图片时对服务器的请求次数

可以合并多数背景图片和小图标，方便在任何位置使用，这样不同位置的请求只需要调用一个图片，从而减少对服务器的请求次数，降低服务器压力，同时提高了页面的加载速度，节约服务器的流量。

提高页面的加载速度

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 会阻碍具有可访问性和生产率方面的网页建设进程。

 

 

上面都是百度里的内容！！！

 

下面我要说的是：

我们在使用雪碧图的时候，就必须得衡量一下我们最需要的是哪个方面的优化。

我在实际项目中碰到过的问题如下：

1.考虑网络环境比较差的情况，例如：印度的那每秒几K的网速。在那么慢的速度下，如果使用雪碧图，图的加载速度将会很慢，严重影响了用户体验。所以这种情况下，雪碧图不合适。

2.在移动端页面上夜间模式下，你知道会出现什么情况吗？

使用雪碧图，都是以背景图的方式插入页面中的，日间模式下看起来没什么区别。但是换到夜间模式下，那就是一个悲剧（如果产品不接受的话）。因为插入背景图的方式在夜间模式下会变得很不清晰，没有插入img元素那么清晰可见。但是图在一个页面中的重要性是很大，如果产品接受不了，那就必须得换成插入img方式了，雪碧图也就不适用了。