为什么精灵图优化不生效问题出在这五处细节

精灵图优化不生效或者收益甚微，原因通常不在方案本身，而是合并前的尺寸确认、图标间距、背景定位基准、双倍图适配与缓存策略这五处细节没有闭环。精灵图优化把多张独立请求的小图标合并为一张大图，通过改变background-position的值展示对应区域，从而降低浏览器在页面加载时的并发请求压力。

据HTTP Archive《Web Almanac》数据显示，目前移动端页面的中位数请求数仍超过70个，其中图片请求长期占据总请求量的四成以上。每多一次图片请求，浏览器都要经历DNS查询、TCP连接和资源传输的过程，这些时间累积起来就是首屏渲染的主要延迟来源。精灵图优化的目标就是把这一部分请求次数压下来。

精灵图优化解决的是请求数量带来的累加延迟

精灵图优化的本质是用一张合成图片替换一组分散的小图片，让浏览器只发起一次图片请求，而不是十次甚至更多。浏览器对同一域名的并发连接数有限制，HTTP/1.1协议下通常为6个，超出部分会进入排队状态。单个小图标虽然只有几KB，但请求带来的建连成本远高于传输成本。

判断页面是否需要精灵图优化，可以看两个条件：一是页面仍然运行在HTTP/1.1环境下；二是页面上存在大量重复使用的小图标，单个体积不超过10KB。如果两个条件同时成立，精灵图优化的收益最明显。

构建精灵图时先测量尺寸再设置背景定位

正确的操作顺序是：先测量每个图标在实际页面中的渲染尺寸，再按规则拼合图片，最后通过background-position把每个图标暴露出来。

.icon-a {
  background: url(icons.png) no-repeat;
  background-position: -10px -20px;
}

background-position取的是负值坐标，基准点位于精灵图的左上角。图标在合成图里距离左上角越远，这个负值就越大。坐标写错是精灵图优化不生效最常见的原因。

五处细节直接影响精灵图优化的最终效果

以下五处细节是实践中高频率导致优化失效的原因。

• 合并前必须核对图标的实际渲染尺寸，CSS尺寸和图片自身尺寸不一致时，背景定位会出现错位；
• 图标与图标之间必须预留至少2像素的间距，避免相邻图标的边缘在浏览器缩放时互相干扰；
• 背景定位的基准始终是精灵图左上角，所有坐标都以这里为起点计算；
• 高DPI屏幕需要引入双倍尺寸的精灵图，再用background-size缩放至目标尺寸；
• 精灵图一旦上线就要配置长缓存时间，文件名内加入版本号，避免浏览器命中过期缓存。

其中双倍图适配最容易出错。Retina屏幕的逻辑像素与物理像素不同，CSS里写的尺寸是逻辑尺寸，而背景图需要对应物理像素。精灵图整体放大一倍后，background-size要设置为原设计尺寸的一半。

HTTP/2环境下的精灵图优化需要重新评估

HTTP/2的多路复用让浏览器可以在同一个连接上并行传输多个资源，单张精灵图的请求优势被削弱。但精灵图优化在两种场景下仍然成立：一是资源服务器尚未开启HTTP/2，二是首屏HTML内联样式需要避免额外的图片请求。合并后的精灵图依然能减少DNS查询和TLS握手次数，这是HTTP/2无法消除的成本。

在HTTP/2项目中，一个替代方案是把小图标转换为内联的SVG或Base64，但体积超过5KB时这个方法就会因为重复编码反而增加传输量。精灵图在10KB以上的多图标场景下，依然是传输效率最高的方案。

精灵图优化收益对比：一个典型的首页请求分析

以一个包含20个功能图标的首页为例，优化前每次图片请求的平均耗时约为120毫秒，20次请求的总耗时约为2.4秒。合并成一张精灵图后，请求数降为1次，总耗时缩减到约180毫秒。这个数据来自测试环境模拟，结果可以作为同类页面的参考基准。

精灵图优化的最终目的是让页面资源请求结构更加紧凑，而不是单纯减少图片文件的数量。把合并后的精灵图、图标字体和矢量图按场景分开使用，才能在请求数量和可维护性之间拿到平衡。