17370845950

WebP在HTML5中需主动适配：用++降级，编码参数（如-q 75、-m 6、-alpha_q 85）影响体积与质量，Service Worker需依Accept头动态返回，且需实机测试解码性能。

WebP 在 HTML5 中确实有帮助，但效果取决于具体使用方式和浏览器支持范围。它不是“开箱即用就一定更好”，而是需要主动适配、降级处理，并注意编码参数对质量与体积的权衡。

WebP 的 写法必须带 降级

直接写 会导致 Safari 13.1 之前、旧版 Edge 等浏览器显示空白——它们不识别 WebP 格式且不会自动 fallback。

正确做法是用 包裹多个 ，并以 作为最终兜底：

  
  @@##@@

• type="image/webp" 是关键标识，浏览器靠它跳过不支持的 source
• 必须存在，且不能省略 src 和 alt，否则语义和可访问性出问题
• 不要只写一个 ，否则无降级能力；也不要漏掉 标签

WebP 编码参数影响显著：cwebp -q 和 -m 要调

同样一张图，用默认参数转 WebP 可能比优化后的 JPEG 还大。WebP 的压缩质量（-q）和压缩方法（-m）对结果影响极大。

• -q 75 是较安全起点，-q 85 以上体积增长快但人眼难辨提升
• -m 6（最慢模式）比 -m 0（最快）平均再省 5–10% 体积，CI 构建中值得加
• 含透明通道的图必须加 -alpha_q 85 单独控制透明度质量，否则边缘发灰

Service Worker 缓存 WebP 需检查 Accept 请求头

如果用 Service Worker 拦截图片请求并动态返回 WebP，不能简单替换后缀。浏览器是否支持 WebP 是通过请求头 Accept: image/webp 告知的。

• 服务端或 SW 中必须读取 event.request.headers.get('Accept')
• 仅当包含 image/webp 才返回 WebP，否则返回原格式（如 JPEG/PNG）
• 忽略该头直接返回 WebP，会导致旧版 Safari / Firefox 加载失败且无提示

最容易被忽略的是：WebP 的优势在「高压缩率」，但它的解码开销略高于 JPEG，低端 Android 设备滚动长图页时可能出现卡顿。上线前务必在真实低端机上测首屏渲染帧率，别只看 Lighthouse 的“节省了 XX KB”。