WebP兼容性问题本质是格式识别缺失而非性能问题，必须用<picture>+<source type="image/webp">显式声明并以<img>作兜底，否则旧浏览器（如IE、Safari≤13.1）将显示空白。
不会拖慢浏览器支持，但写错 HTML 会导致不支持 WebP 的浏览器直接空白——这不是性能问题，是兼容性缺失。
直接 <img src="x.webp"> 在旧浏览器里会显示空白
IE、Safari ≤13.1、旧版 Android WebView 等根本不认识 .webp 后缀，也不解析 MIME 类型，<img> 标签加载失败后不会自动 fallback，页面就留个空位或占位符。这不是“加载慢”，是根本没内容可加载。
- 错误写法：
<img src="banner.webp" alt="首页横幅"> - 正确思路：必须用
<picture>显式声明支持条件，让浏览器自己选 - 注意：
<img>必须作为<picture>的最后一个子元素，且src指向 JPEG/PNG 回退图，不能省略
<picture> 中 type="image/webp" 是唯一可靠判断依据
浏览器不看文件后缀，只根据 <source type="image/webp"> 的 MIME 声明决定是否选用该资源。这个判断发生在 HTML 解析阶段，无 JS 参与，零延迟。
- 有效写法：
<picture><source srcset="icon.webp" type="image/webp"><img src="icon.png" alt="图标"></picture> - 不要加
media或sizes属性来“控制加载时机”——WebP 兼容性检测跟响应式无关，只依赖type - 多个
<source>时，浏览器按顺序匹配第一个支持的type，所以 WebP 放最前
JavaScript 检测 toDataURL('image/webp') 仅用于动态场景
如果你需要在运行时决定是否加载 WebP 资源（比如懒加载、CMS 动态拼接），才需要 JS 检测。静态 HTML 页面不需要它，也别用 User-Agent 字符串判断——太容易误判。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 可靠检测代码：
const webpSupported = document.createElement('canvas').toDataURL('image/webp').startsWith('data:image/webp'); - 返回
false或"data:,"表示不支持（如 IE11、Safari 13.0） - 注意：部分老 Chrome（≤22）支持有损 WebP 但不支持 Alpha，需额外测试
toDataURL('image/webp', 0.5)是否返回有效字符串
Apache .htaccess 或 Nginx 自动回退不是“替代方案”，而是补充手段
服务端规则（如重写 .webp → .jpg）能减少前端维护成本，但它依赖请求头 Accept: image/webp，而很多旧环境（微信内置浏览器、智能电视）根本不会发这个头，照样 fallback 失败。
- Apache 示例规则中，
RewriteCond %{HTTP_ACCEPT} !image/webp是关键，但无法覆盖无 Accept 头的 UA - Nginx 配置需配合
webp模块，否则rewrite后 404，反而更糟 - 结论：服务端回退适合已有大量 WebP 图片、且流量集中在现代浏览器的站点；关键位置仍建议用
<picture>双保险
最容易被忽略的是：<img> 在 <picture> 里不是“备用图”，而是“所有不支持 <picture> 或不识别 type 的兜底”——包括 IE9 这种连 <picture> 都不认识的浏览器。漏掉它，等于主动放弃兼容性。
