重构工程师是掌控天平的人。

在制作雪碧图这件事上，要考虑自己行为造成的如下影响：服务器流量、HTTP请求数、可扩展性。理解了使用它的优势和劣势，才能写出更好的代码。

服务器流量

滥用雪碧图可能导致服务器流量的浪费，体现在以下4个方面：

单独来看，不同类型的图片适合使用不同类型的格式，各自使用各自适合的图片的话，并且经过额外压缩（非PS里的压缩，而是去掉文件附带信息的压缩），就能达到流量最优。当做成雪碧图时，也就是用一种类型来匹配多种图片。在这种情况之下，可能一个并不适合制作成jpg的按钮被放在一个大的jpg雪碧图中。由此造成的服务器流量增多是一个无法忽视的漏洞。更严重的是，一些需要平铺repeat的图放在雪碧图中可能会影响整个雪碧图尺寸大小的变更。

第二个由雪碧图造成的服务器流量浪费是多页面使用各自不同的图：页面1显示a.jpg，页面2显示b.jpg，页面3显示c.jpg。如果abc做到一个雪碧图中，那么用户访问页面1的时候就会读取一个包含了abc的大图，而他可能根本不会去访问页面2和页面3，这样就造成了流量浪费。这是非常大的一个浪费。

第三个因素是雪碧图中的一个小地方修改时，整个大图都需要由用户重新读取，无法长缓存。

第四个因素是：模块之间是耦合较低的，这是理想的、我们希望看到的情况。但通过雪碧图我们把几个模块连接在一起了：当一个模块弃用或者修改之后，模块的图片还在雪碧图之中，而雪碧图仍然在线上通过其他模块被用户读取。这就造成了流量浪费。

HTTP请求数

雪碧图能减少HTTP请求数，以此获得的利益被高估了：

HTTP请求数不是一个重要得不得了的优化因素，因为HTTP请求数不是越少越好，而是少到一定程度就足够好了。

就好像通过CDN增加域名数来提高并行下载数量，但CDN的数量也不是越多越好，因为增加一个域名就会增加一个域名的DNS解析时间。达到4个域名的时候，增加的额外DNS解析时间可能会完全抵消掉并行下载带来的好处。

足够好就够了。

可扩展性

雪碧图对扩展性造成的干扰体现在下面几点：

首先，降低了了组件独立性。如果希望在一个子页中调用首页的一个vip按钮，那么就必须做一个担心：担心子页中引用改模块的html或者css会导致请求一整张不需要的大图片。

其次，增加了图片，那么是在已有雪碧图中进行修改增加还是另外增加一个图片？后者会导致不一致和服务器布局混乱；前者会导致雪碧图尺寸增加，或者由于找不到PSD源码导致图片质量降低的问题，而且几个同样按钮的不同布局摆放也可能会输出大小不一的图片，后期变更往往在开始摆放的时候是无法预料到的。

再次，雪碧图尺寸变更也可能导致原有雪碧图支持的模块错乱。因为一些小icon必须处于雪碧图的中间的，如果改变宽度，那么icon就不在50%处了，会导致模块错位。

那么

使用的时候多思考，不要不加思考地使用雪碧图，不要让自己的天平太过于偏向HTTP请求数，而忽略了流量和可扩展性。