css sprites在移动端仍有效，因其可显著减少http/1.1环境下低版本android webview（4.4–6.0）的并发请求排队，合并10个小图仅需1次请求，实测降低首屏白屏300–800ms；需用png/gif格式、整数background-position、哈希命名sprite文件并配合background-size适配高清屏。
移动端H5页面首屏慢，八成卡在资源加载上；而 HTTP 请求是瓶颈中的瓶颈——Android WebView 默认并发上限仅 4 个，iOS 虽提升至 6 个，但图标类小资源一多，排队就明显。用 CSS Sprites 合并小图，是成本最低、兼容性最好、见效最快的 HTTP 请求数削减手段。
为什么 CSS Sprites 在移动端仍有效
现代浏览器虽支持 HTTP/2 多路复用，但 Android 低版本 WebView（尤其 4.4–6.0）仍广泛存在，且大量 APP 内嵌 WebView 未升级内核；这些环境仍走 HTTP/1.1，无法复用连接，每个请求都带 TCP 握手、TLS 协商开销。合并 10 个小图 → 1 次请求，实测可减少 300–800ms 首屏白屏时间。
常见错误现象：Network 面板里看到一堆 icon-home.png、icon-search.png 等 1KB 左右的请求排长队；Waterfall 图中它们的 Queueing 和 Stalled 时间远高于实际下载时间。
- 适用场景：工具栏图标、按钮状态图（normal/hover/active）、列表项前缀 icon、评分星星等尺寸固定、变化少的装饰性图片
- 不适用场景：头像、商品主图、轮播图、任何需要响应式缩放或 srcset 切换的图片
- 注意：WebP 格式本身不支持 Sprites（解码器不认），必须用
PNG或GIF；若需 WebP 压缩优势，应放弃 Sprites，改用srcset + picture
生成与使用 Sprites 的关键步骤
别手动画图拼接——容易错位、难维护。用自动化工具生成，再配精准 background-position。
- 推荐工具：
webpack-spritesmith（Webpack 项目）、gulp.spritesmith（Gulp）、或在线工具如Sprite Cow（仅辅助定位） - 生成时强制统一尺寸：所有源图裁切为相同宽高（如 48×48），避免空隙干扰定位计算
- CSS 中必须用
background-size配合background-position，否则高清屏（dpr=2/3）下会模糊：.icon-home { background: url(icon-sprite.png) no-repeat -48px 0; background-size: 200px 48px; } - 避免使用
padding或margin微调位置——应靠background-position精确到像素
容易被忽略的坑：缓存与更新失效
Sprites 文件一旦上线，缓存周期往往设得很长（Cache-Control: max-age=31536000），但内容更新后，旧 CSS 仍引用老文件名，用户看不到新图标。
- 必须给 Sprite 图片加哈希指纹：
icon-sprite.[contenthash:8].png，Webpack 默认支持；否则每次更新都得手动清 CDN 缓存 - 禁止将 Sprite 图放在
/static/或根目录硬编码路径——它必须随构建流程生成并注入 CSS，否则哈希无法联动 - 慎用 Base64 内联：虽然省一次请求，但会增大 CSS 体积，阻塞渲染；且无法单独缓存，图标一变整个 CSS 失效
- Android 4.4 WebView 有
background-position渲染 bug：小数像素偏移可能四舍五入失真，务必用整数 px 值
真正难的不是生成一张大图，而是让这张图在 dpr 不同、缓存策略各异、WebView 版本碎片化的安卓生态里，每次都能准确定位、清晰显示、及时更新——哈希命名、整数偏移、PNG 格式、分离缓存生命周期，这四点漏掉任一，Sprites 就从优化变成负优化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
