WebP在HTML5中需主动适配：用++降级，编码参数（如-q 75、-m 6、-alpha_q 85）影响体积与质量，Service Worker需依Accept头动态返回，且需实机测试解码性能。
WebP 在 HTML5 中确实有帮助，但效果取决于具体使用方式和浏览器支持范围。它不是“开箱即用就一定更好”，而是需要主动适配、降级处理，并注意编码参数对质量与体积的权衡。
WebP 的
直接写 
正确做法是用
@@##@@
-
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”。
