avif webp 谁在真用：27 个首页 269 张 webp、23 张 avif，还有 116 张图没有 src

实测 · 2026-08-28 · 27 个首页 · 单次抓取 · 1,675 个 img 元素

样本 / 口径：2026-08-15 起沿用的同一批 30 个站，2026-08-28 11:37（+0800）各抓一次，用浏览器 UA，不执行 JavaScript，也不请求任何一张图。每个 <img> 与 <picture> 里的每个 <source> 都记下来，格式取自 src 去掉参数之后的后缀。

搜 avif webp 的人想知道的是该换哪一个。这批 27 个首页给出的答案是：几乎没人换。1,675 个图片元素里，指向 .webp 的有 269 个，指向 .avif 的只有 23 个，而这 23 个全在两个站上。更值得独立站注意的是另一行——116 个 <img> 连 src 的值都没有。

怎么测的

每个站一次请求，不渲染、不重试。纳入规则跑数前写死：最终 200、解压后至少 10,000 字节、含 <body。stackoverflow.com 与 medium.com 返回 403，www.reddit.com 返回 8,393 字节空壳，剩 27 个站。

这里说的格式是 URL 里写着的后缀，不是服务器实际会返回的字节。每个 <img> 只进四个桶中的一个：没有 src 值、data: 内联、URL 无后缀、URL 有后缀。四个桶相加正好 1,675。

avif webp 之间，部署量差了近 12 倍

webp 出现在 27 个站里的 9 个，avif 只有 2 个。

那两个用 avif 的站是 webflow.com（22 张）和 www.cloudflare.com（1 张），两家同时还在发 webp 或 png。面板里出现的七种后缀全部在 Google 的支持清单内——《Google Images best practices》（本日抓取）写的是：Google 搜索支持 img 的 src 指向 BMP、GIF、JPEG、PNG、WebP、SVG、AVIF 这几种格式。清单里唯一一次都没出现的是 BMP。

压缩率那一头的数字来自 MDN 的图片格式指南（同日抓取）：有损 AVIF 比 JPEG「around 50% smaller」，而且总体比 WebP 压得更狠——「median 50% vs. 30% compression for the same JPG set」，MDN 在这句后面标注来源是 CTRL Blog。按这个差距，部署量本不该反过来差 12 倍。

116 张图没有 src

这一行和选哪个格式无关，但它才是真会影响收录的那一格。

116 张集中在四个站：slack.com 69 张、www.wired.com 25 张、www.nytimes.com 21 张、vercel.com 1 张。官方那页对这种形态说得很直接：「We recommend that you always specify a fallback URL using the src attribute.」——因为有些爬虫不读 srcset，也不读 <picture>。一个没有 src 的 <img>，要等别的东西跑起来才存在。

另外 113 张无后缀的是另一回事：它们是图片优化端点，linear.app 35 张、www.notion.com 31 张、nextjs.org 27 张、supabase.com 17 张。格式在请求时协商，所以 URL 本身说明不了返回什么。官方同一页还有一句可以对着读：「It's also a good idea to have the extension of your filename match with the file type.」

没有一个 source 声明 avif

27 个站里只有 7 个用了 <picture>：stripe.com、substack.com、webflow.com、www.notion.com、www.nytimes.com、www.shopify.com、www.wired.com。它们一共发了 179 个 <source>，其中 46 个声明了 type，而这 46 个全部写的是 image/webp。

剩下 133 个不声明 type，说明它们是按 media 或分辨率切换，不是按格式支持切换。整批面板里 image/avif 出现 0 次。格式升级本来就该走这条通道，而在这 27 个首页上，这条通道运的是 webp，或者什么都没运。

独立站按这个顺序改

两步，别调换。

1. 先让每个 <img> 都有一个真的 src。只多写一个属性，而它是官方明说会读的那一个。格式的事放在这一步之后。
2. 再在 webp 的 <source> 上面加一条 <source type="image/avif">，webp 保留，img src 里留 jpg 或 png 兜底。这批面板说明几乎没人这么做——换个角度看，这条路现在还不拥挤。

如果你的图走的是按 Accept 头返回格式的图片服务，那你其实已经绕过了这两步，而本次测量看不见这件事：不管服务器怎么决定，URL 都还是那个没有后缀的样子。同一批面板上还有一篇 srcset 实测，方法那一半在 seo 图片怎么做 里。至于页面本身有没有被 AI 答案引用，那是更上一层的问题，入口在 QueryWin 怎么运转。

这次没测出来的几件事

实际返回的是什么格式，不知道。一张图都没有请求过，所以那 113 个无后缀 URL 返回什么字节说不了，就算是带后缀的 1,425 个，服务器也可能在底下做内容协商。渲染后由脚本插进来的图同样看不见。体积完全不在本次范围内——挨着 png 摆的那些 webp 到底小多少，这次一个字节都没量。

常见问题

你们是怎么测的？

2026-08-28 用桌面浏览器 UA 对每个首页各抓一次，解析返回的 HTML，把每个 src 去掉参数和锚点后读后缀。四个桶互斥，所以四行相加正好是 1,675。

现在换 avif 稳不稳？

Google 把 AVIF 列在它支持的格式里。浏览器支持这件事本来就是 <picture> 兜底要解决的，而这批面板里有两个站已经在这么用了。

svg 算图片吗？

在 Google 的支持清单里。它也是这批面板里最多的一种，1,425 张带后缀的图里占 487 张。不过其中多数是图标和 logo，不是内容图——这个区分本次没做。

该不该把 png 全转成 webp？

这次的数据回答不了。它只数了 27 个首页发了什么，没有页面体积、没有加载耗时、也没有排名数据挂在任何一列上。