回想n年前刚写前端的时候，在处理一个'鼠标hover切换背景图会闪'的问题时，将两张背景图合成一张图片，顺利解决问题。这应该是我第一次用到雪碧图的情况。

雪碧图作为背景在切换时不会有因为需要等待下载而产生的闪现

如今，打开一个站点，呈现铺天盖地的图片资源的页面随处可见。而多数站点更会用一套包含几十个风格统一的图标的图标库，加之移动端的占比与日俱增，雪碧图这项技术被运用的就越来越普遍。

制作“雪碧图”一般是前端优化的重要一步，主要作用当然就是减少HTTP请求数。但是由于传统方法的雪碧图制作和维护成本都极高，加之现代浏览器支持的并发数也不断提高，所以很多人开始质疑做这项工作的必要性。但并发支持度变高，并不代表无限支持，网页首屏需要加载十几张图片资源还是很常见，再算上js、css以及一些数据的ajax请求，HTTP数上五十也是轻轻松，于是，用户体验就不那么好了。所以，这个工作不能省，但是开发成本又不得不考虑，于是，"雪碧图自动化"是自然而然就会产生的想法。

先看下雪碧图的发展历史:

原文：Responsive Images in Practice

作者：Eric Portis

译者注：感谢米粽、我佛山人和otakustay为译文提出的宝贵意见。

魔鬼因一切我们享受的东西而惩罚我们。

—阿尔伯特·爱因斯坦

图片已经占了 Web 内容的 62%，而且我们每天都在制造更多。如果所有图片内容都能被好好加以利用那的确很赞。但是对小屏或低分辨率屏来说，其中大部分数据都被浪费了。

为什么？尽管 Web 设计初衷是让所有人能通过任何途径来访问，但直到最近，设备的碎片化才迫使业界全面转向了响应式设计。我们在进行响应式设计时，内容可以优雅且高效地流入任何设备。这说的是除了位图以外的所有内容。位图是固定分辨率的。而且他们的容器——敬爱的 img 和它那孤零零的 src——没有任何适配能力可言。

设计师们面临这样一个苏菲的选择¹：让页面在有些情况下变模糊，还是在所有情况下变慢。大多数人倾向于后者，给所有人发送能适配最大、最高分辨率屏幕的图片。浪费啊。

但是！经过三年的辩论，我们有了一些新的标记来解决响应式图片这个问题：