不要滥用雪碧图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方式了,雪碧图也就不适用了。

posted @ 2014-05-08 00:49 Joy Ho 阅读(...) 评论(...)  编辑 收藏