是唯一零JS、不发额外请求、SEO友好、原生支持的WebP/AVIF降级方案;其生效依赖type与Content-Type严格匹配、AVIF→WebP→JPEG顺序、为静态JPEG/PNG兜底且不可省略。

是唯一能零 JS、不发额外请求、SEO 友好、原生支持的方案。别绕弯子,直接用它。
为什么 里 不生效
不是浏览器“不支持”,而是链路中某处 MIME 类型没对上。浏览器只认标准 type 字符串,且必须和服务器返回的 Content-Type 响应头完全一致。
-
type="webp"或type="image.webp"—— 缺image/前缀或用错分隔符,直接跳过该 - Nginx 未配置
types { image/webp webp; },导致返回Content-Type: text/plain或空 - CDN 没透传
Accept: image/webp请求头,后端无法判断客户端能力,统一返回 JPEG - DevTools Network 面板看到状态是
blocked:mime-type或406 Not Acceptable,基本可定位到服务端配置问题
的顺序为什么必须是 AVIF → WebP → JPEG
浏览器从上到下逐个尝试 ,遇到第一个 type 支持且媒体条件满足的就加载并停止。这不是“建议”,是执行逻辑本身。
-
必须放最前:Chrome 120+、Firefox 120+ 已稳定支持,但旧 Safari 和部分 Android WebView 仍不支持,需靠后续 fallback -
居中:覆盖 iOS 14+ Safari、Android 4.0+、几乎所有桌面浏览器 - JPEG/PNG 回退必须放在
的src属性里,不能写成第三个;否则 IE、旧 Android WebView 会空白 - 把
image/jpeg写在image/webp前面,哪怕设备支持 WebP,也永远加载不到
![]()
的 src 为什么不能带查询参数或动态地址
是所有不支持 type 的老浏览器(如 IE、旧 Android WebView)唯一能识别的入口。它必须指向一个静态、可直访、无需协商的 JPEG 或 PNG 地址。
-
src="logo.jpg?format=webp"或src="logo.jpg?x-oss-process=image/format,avif"在不支持 WebP 的浏览器里可能触发406或返回损坏数据,导致图片不显示 -
src地址要能单独粘贴进浏览器地址栏并正常显示图片 - 漏掉
,整个就失效——本身不渲染、不请求,真正触发加载的是匹配成功的或最终的 -
必须含src和alt,否则语义缺失、无障碍失败、SEO 受损
所有格式图片尺寸与构图必须一致
这是最容易被忽略的一点:如果 a.avif、a.webp、a.jpg 宽高不同、裁剪比例不同、甚至构图偏移,响应式切换时会出现拉伸、模糊或视觉跳变。
另外,fetchpriority="high" 要加在 上,不是 —— 加在后者上无效;所有 srcset 值里的图片分辨率、质量档位、裁剪比例也要一致,否则响应式切换逻辑就乱了。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











