图片SEO换个请求头小37%，但发哪种格式不归你定

摘要：131个海外品牌电商站，首页能打开的119个，能取到一张真实商品图逐格式对照的107个。同一条地址、同样宽度，只把请求头换一换：现代浏览器拿到的文件比老浏览器小37.0%，中位数从75092字节掉到41214字节，最大的一个差了95.6%。但真正决定发哪种格式的不是站主——107个站里只有14个在地址里写死了格式，其余全由图片服务自己挑；而当我发出一个只认AVIF的请求头，102条管线里有87条压根拿不出AVIF。

一张商品图从服务器发到用户屏幕上，中间有一个环节几乎没人盯：这次到底发JPEG、WebP还是AVIF。它不写在HTML里，不写在主题设置里，也不在任何一个后台开关上。它发生在请求发出去的那一瞬间——服务器扫一眼浏览器随手递过来的Accept头，当场就把这事定了。

它值得单独测一次，因为同时占了两条：影响大，而且大部分人不知道自己有没有参与决定。图片通常是首屏最重的那一块，格式换一种，体积能差三分之一到一半；可如果你去问一个独立站运营“你们站上的图发的是WebP还是AVIF”，十有八九答不上来，因为从来没人做过这个决定——是平台替他做的。

页面上关于图片的其他事，我已经量过几轮。srcset里写着1920w、服务器给的却是同一张140宽的图，那一轮量的是声明的宽度和真实像素对不对得上；994张交付图里属于品牌自己的版权信息一个字都没剩，量的是文件内部的元数据；alt与尺寸属性怎么批量体检则停在标记层，大图上那62%的字页面里根本找不到量的又是图里的内容。这一轮换一个方向：同一条地址，我不改地址，只改请求头，看服务器给我换不换东西。

页面上那条图片地址，最后发出去的是哪一种格式？

先说结论里最直白的那一半。按今天的Chrome会发的那种Accept头去请求，107个站页面上的那张图，回来是这样的分布：

这个分布本身没什么争议：八成以上的站已经在给现代浏览器发新格式了。真正好玩的是换个身份再问一遍。

我把Accept换成一个明确表示“我只认PNG和JPEG”的值，同样的地址、同样的一张图，回来是这样的：

八成五的站老老实实退回了老格式，说明它们确实在读请求头。剩下那16个站（15.0%）把新格式发给了一个刚刚声明自己不认识新格式的客户端。这两张表放在一起，才是这轮实测真正的入口。

怎么把“谁决定的”这件事测出来？

整套测法只有三步，但每一步都有一个必须先堵上的口子。

第一步：取到一张真正的商品图

从首页HTML里挑一张图，听起来是十分钟的活，实际上全是坑。第一版脚本在gymshark上挑中了一个MP4，因为那条地址躺在<source>标签里、扩展名又被查询串盖住了；另一个坑是地址里的HTML实体没还原，&width=300被当成一个叫amp;width的参数，结果整个尺寸参数失效、下回来的是原图。这两个错都会让后面的对照全部作废。

定稿的做法是：从img与source标签的srcset里取最宽的那一条，取不到再退回src与data-src，仍取不到就用preload as=image、内联背景图和og:image兜底；地址一律先做实体还原；命中logo、图标、国旗、占位图、雪碧图等关键词的一律跳过；下回来之后不看扩展名也不看响应头，只读文件头的magic字节，必须是JPEG、PNG、WebP、AVIF四者之一且大于3000字节才算数。131个站里首页能打开的119个，最终有107个取到了合格的样本。没取到的12个分两种：9个的HTML里压根找不到一条可用的图片地址——aliexpress、innisfree、temu这三个回来的首页只有两三千字节，是一张挡在真页面前面的壳，这跟JS渲染那一轮量到的形态对得上；另外3个（functionofbeauty.com、rapha.cc、segway.com）地址是有的，但前五个候选下下来都没通过校验。

第二步：三档请求头

三档分别模拟现代浏览器（同时接受AVIF与WebP）、只认WebP的浏览器、以及两样都不认的老浏览器。MDN对Accept头的说明把这件事讲得很清楚：这个头是客户端在告诉服务器自己能处理什么，服务器据此挑一份最合适的表示返回，这套机制叫主动内容协商，HTTP语义规范RFC 9110把它列为服务器选择表示的标准手段。

第三步：把尺寸固定住

这一步是整轮里最容易被忽略、也最要命的一步。页面上那条地址自带宽度，各站各不相同，直接拿字节数横向比等于比了两件事。所以我又把每条地址的尺寸参数统一改成800，再跑一遍三档——同一张图、同样宽度、只有请求头不同，这三个数才具备可比性。这条规矩说白了就是：在问“A和B为什么不一样”之前，先问一句“A和A自己一样吗”。

尺子本身也得先自查一遍。“老浏览器”那一档我写的是image/png,image/jpeg,*/*;q=0.8，末尾那个通配符其实等于“别的也行”，所以服务器发WebP严格说来不算违规。于是对那16个被喂了新格式的站，我把通配符整个去掉、只写image/jpeg,image/png再问一次——16个站里16个照样发新格式。这条路堵死之后，才敢说它们是真的没在读请求头。

那16个站，为什么把新格式发给了说不认它的浏览器？

把这16个站按图片服务归类，答案立刻浮出来：它们绝大多数根本没有在做协商，格式是在地址里写死的。

107个站里，有14个（13.1%）的图片地址上带着一个明确的格式参数：fm=webp七个、fm=avif三个，还有fmt=webp-alpha、format=auto、xg、png各一个。这14个里有10个完全不协商——请求头怎么写都不影响结果，地址里写的是什么就发什么。rituals.com那条Scene7地址上写着fmt=webp-alpha，我用只认JPEG的头去要，回来的还是同一份WebP，一个字节不差。

这就把“谁决定的”这个问题的答案说清楚了。写死格式，本质上是开发者在写模板的那一天，替未来所有访客一次性做了决定。那天做的判断可能是对的——2022年的时候，把fm=webp硬编码进模板确实比什么都不做强。问题在于这个决定被冻住了：将来AVIF普及了，浏览器再怎么声明自己认AVIF也没用，因为这条链路上已经没有一个环节会去读那句声明。

反过来看协商的那一侧：107个站里76个（71.0%）会随请求头改变返回结果。这批站什么都不用做，浏览器升级一次，它们就自动多省一截。

协商与Vary这两件事，有10个站只做了后一半

顺手量到一组对不上的数：响应头里带Vary: Accept的有84个站（78.5%），而真正会随请求头改结果的只有76个。差出来的十个站声明了自己会按Accept变，实际不变；反过来也有两个站（mejuri.com与suitsupply.com）确实在变，却没有声明。MDN关于Vary的说明里讲了这个头存在的意义：它是给中间缓存看的，告诉它们同一条地址下有多份不同的副本、不能混用。少写这个头的后果不是页面出错，是缓存可能把一个浏览器的副本发给另一个浏览器。Vary声明与真实变化的对账我单独做过一轮，结论跟这里一致：声明和行为对不上是常态，而且两个方向都有。

同一张图、同样宽度，三种格式差多少字节？

把尺寸统一到800之后，102个站拿到了完整的三格数据，其中71个站现代格式与老格式确实不是同一种。这71个站的差距是这样的：

绝对值上，老格式中位75092字节，现代格式中位41214字节。这就是文章开头那个37.0%的来处：什么都不改，只是请求头里多了两个格式名，同一张图就轻了三分之一。

不过这三档里有一档几乎是白设的。只认WebP那一档的中位数也是41214字节，跟现代那一档一模一样；再往细里看，71个站里有59个（83.1%）在这两档下拿回来的是同一串字节。多声明一句自己认AVIF，在这批站上换不来任何东西——这跟后面那个87比102是同一件事的两种说法。

再往上一层，AVIF比WebP还能再省多少？这一格样本很薄——107个站里只有10个能在同一条地址上同时给出AVIF和WebP两份，因为大部分管线要么两种都给不了，要么只给其中一种。这10个站里，AVIF比WebP再小19.7%（中位），最大的一个是suitsupply.com：同一张图，WebP是2587256字节，AVIF是1222260字节，省掉52.8%。最小的两个只省了1.9%和3.4%。图小到一定程度，新格式的固定开销就开始反噬——一张135字节的图标压成WebP之后变成560字节就是这个道理，那一轮把这笔固定费用拆得很细。

把这两级叠起来看：从JPEG到WebP是一大步，从WebP到AVIF是一小步且波动很大。这个梯度的形状，直接决定了下一段那个数字为什么重要。

想要AVIF，这条管线给不给？

协商这套机制有个隐含前提：服务器手上得真有那份东西。所以我又发了一轮请求，Accept写成image/avif,*/*;q=0.1——意思是“我最想要AVIF，别的也不是不行但很勉强”。

102个站给了回应，其中只有15个真的返回了AVIF，另外87个换来的是WebP、JPEG或PNG。Shopify那条图片CDN上的站尤其整齐：allbirds回了一张292230字节的PNG，aloyoga回了34236字节的JPEG，anker回了45002字节的JPEG——它们不是不给AVIF，是这个请求头里没有出现image/webp，于是它干脆退回了原始格式。

这里得给这个数字加个括号，免得说过头。这15比87不等于“87个站永远拿不到AVIF”，它只说明在我这一轮的请求条件下，这些管线没有拿出AVIF。整轮里任何一次请求吐出过AVIF的站是25个，占107个站的23.4%。换句话说，四分之三的站，今天不管来的是什么浏览器，拿到的最好也就是WebP。

两个站明明编得出更小的AVIF，却没发

那两个例外更值得琢磨。arcteryx.com和kotn.com在现代请求头下给的是WebP，我强行只要AVIF时它们给出来了，而且那份AVIF比WebP还小——23426对22986，16404对15851。差得不多，但方向是明确的：不是编不出来，是这条管线的选择规则没把它选出来。

我原本的假设是“谁小发谁”，这两个例子把它推翻了。真正的规则更像是各家管线自己的配置：给不给AVIF、什么时候给，是管线一侧写死的策略，跟这张图AVIF会不会更小没有必然关系。

开关到底在谁手上？两家平台给出了两种答案

到这里就要回答那个最实际的问题：假设你现在想让自己站上的图发AVIF，你有没有地方可以改。

Shopify这一侧，答案写在官方文档里。image_url这个Liquid过滤器的参数表里确实有一个format参数，但它只接受pjpg和jpg两个值，能做的转换也只有PNG转JPEG、PNG转渐进式JPEG、JPEG转渐进式JPEG这三条。文档紧接着有一段说明：平台会自动检测客户端支持哪些格式（原文举的例子就是WebP和AVIF），然后按画质与体积挑一个。也就是说，站主手上根本没有一个叫“发AVIF”的开关，这件事从设计上就不归他管。我这一轮量到的59个走Shopify图片CDN的站里，56个会协商、7个在某次请求里吐出过AVIF，这个比例不是这些品牌各自的选择，是平台当下的策略。

Next.js这一侧，答案完全相反。翻它的源码，packages/next/src/shared/lib/image-config.ts里那份默认配置写着formats: ['image/webp']，我对了v15.5.0和v16.0.0两个标签，值都一样。AVIF不是不支持，是默认没开；把配置改成['image/avif','image/webp']就开了，一行的事。这跟上一轮量到的那份浏览器兼容名单是一模一样的结构：一个躺在框架里、从来没人改过的出厂默认值，只不过这次它是可以改的。

这两个答案摆在一起，就是这一轮最想说的那件事。“平台替你做了决定”这句话底下藏着两种完全不同的处境：一种是没给你入口，另一种是入口一直在，只是没人去按。它们看上去一样——你的站发的都是WebP——但能不能改，差着一整个量级的行动成本。

顺带一个和直觉不符的观察：我这批里被识别为Next.js的11个站，只有2个真的把图片交给框架自带的那套优化在走，其余9个各接了一家第三方图片服务——Sanity、Contentful、imgix、Cloudinary、Scene7、Amplience各一两家。换句话说，就算你用的框架给了你开关，你也可能早就把这个决定外包出去了。这跟首页上那八个只读HTML看不见的第三方域是同一种结构：依赖是一次次加上去的，最后没人说得清哪个决定归谁。

第一个点开这张图的人，下载的是什么？

这一段是整轮里最意外的一个发现，它是从我自己犯的一个错里掉出来的。

我第一遍跑完，发现三个站出现了“倒挂”：请求头里声明的能力更强，回来的文件反而更大。theordinary.com那张图，现代请求头拿到的是33775字节的PNG，只认WebP的请求头拿到的却是12244字节的WebP，差了2.76倍。bugaboo.com和charleskeith.com也是同样的形态。

第一反应是它们的协商逻辑被image/avif这个陌生的值带偏了。为了坐实这个猜测，我把请求头拆成六种排列逐个问了一遍：AVIF在前、WebP在前、只要AVIF、SVG在前做对照、裸通配符。结果全部返回同一份WebP——猜测被自己的实验推翻了。

真正的原因是请求顺序。我用一个从没被请求过的宽度，只用同一个请求头连问三次：

三次的请求头一模一样，唯一的区别是先后。这几台图片服务器碰到一个没生成过的尺寸时，第一次请求直接回原图，转码在后台排队；从第二次起才拿得到转好的那一份。allbirds那一行是对照，Shopify的CDN从第一次就是稳定的。

所以我原来的读法错在哪：我把“排在前面的那次请求”的结果，当成了“那个请求头得到的答案”。三档请求头是顺序发出去的，现代那一档排第一，替后面两档承担了生成变体的成本，于是它显得最吃亏。

把定宽那一组全部重跑一遍之后，102个站里有5个站的答案变了，而且五个全是第一遍拿到的更大：theordinary多2.76倍、bugaboo多1.54倍、charleskeith多1.22倍，kotn和arcteryx各多百分之二三。五个站合计多下载了243327字节，中位16493字节。

这件事对读者的意义比对我这把尺子的意义大得多。它不只是一个测量陷阱——真实世界里，第一个访问某个尺寸的那个人，拿到的就是那份没转码的原图。如果你刚上线一个新的图片尺寸，或者刚清过一遍缓存，那么最先到的那批访客承担的是完整体积——而最先到的那位，有时候恰好是爬虫。更麻烦的是你未必知道缓存什么时候空了，缓存指令写给谁、谁真的听这件事本身就常常和你以为的不一样。静态资源的地址一年后还剩多少能取回来那一轮讲的是缓存与文件生命周期的另一头，这里是同一条链路的入口端。

格式这件事，对搜索到底有多大影响？

这一节我想把话说得保守些。图片格式这个题目上，过度承诺的说法实在太多了。

先说那16个把新格式发给老浏览器的站。今天不支持WebP的浏览器已经很少，兼容性数据上AVIF的覆盖情况虽然还没到WebP那个程度，但WebP本身早就是绝大多数环境的默认能力。所以这16个站的直接损失，接近于零——不会有多少真实用户因此看不到图。

但它仍然值得记一笔，理由不在今天而在以后。不读请求头意味着这条链路上没有任何一个环节会因为客户端变强而改变行为。格式升级唯一的自动通道就是协商，掐掉它，将来每一次升级都得靠人去改模板。这跟排名没关系，跟五年后的维护成本有关系。

真正跟搜索沾边的是体积那一头，而且路径是间接的：图片通常是首屏最大的那个元素，体积直接反映在加载速度上，速度是页面体验的一部分。关键渲染路径那一篇把这条链路拆得比较细，首屏那张图该不该抢优先级则是fetchpriority那一篇的题目。但有三条得跟上：第一，格式换新省下的字节，只有在图片确实是首屏瓶颈时才转化成可感知的提速；第二，监控这一头本身就有盲区，页面上近一半的跨源资源在监控里是一排零，图片恰恰是重灾区；第三，图片文件名不是排名因素、alt也帮不上网页排名，格式同理——它不是一个独立的排名信号。

抓取那一侧还有一笔账容易被忽略。爬虫每次抓一张图也要下载完整字节，图多的电商站上这笔账不小。压缩类型协商那一轮算的是文本资源的同一笔账，图片这一头的量级只会更大。条件请求能不能省下重复抓取则是从另一个方向省。

最后一点老实话：这一轮没有测Googlebot自己会发什么Accept头。我用的是普通浏览器的身份，得到的结论只覆盖真实用户这一侧。爬虫拿到哪一种格式，需要另一套测法，这是本文明确的口径边界。

自己站上怎么查一遍，按什么顺序改？

整套自查不需要任何工具，一条命令行就够，五步走完大概二十分钟。顺序别乱，后面三步都建立在前两步的答案上。

先确认自己在不在协商

拿首页上一张真实的商品图地址，用两种请求头各要一次，比对回来的Content-Type。两次一样就说明没在协商，两次不同就说明在协商。注意别只看响应头里的Vary，前面那10个站已经证明了声明和行为可以对不上。

再确认自己有没有把格式写死

看地址里有没有fm=、fmt=、format=这类参数。有，就说明决定是在模板里做的；这时候要问的问题是：这个值是谁在哪一年写下的，当时的判断今天还成立吗。第三方默认值会自己漂移，而写死的值只会一直躺在那儿。

第三步是问一句“AVIF给不给”

发一个偏向AVIF的请求头试试。给不了，就去查你的图片服务商有没有这个能力、要不要额外开；给得了但平时不给，那就是它的选择策略，你多半改不动。

第四步是把新尺寸预热一遍

这一条是这轮实测的直接产物。改版、换主题、上新的图片尺寸之后，别指望第一个访客替你承担转码：拿脚本把新尺寸的地址扫一遍，让转码提前发生。成本是几十个请求，收益是所有真实访客都拿到转好的那一份。

最后才轮到改模板

顺序很重要。前面四步都是在摸清“这个决定归谁”，只有确认了决定权在自己手上，改模板才有意义。如果你用的是Shopify这类不给入口的平台，把时间花在写死格式上是白费；Shopify上哪些页面元素能改、哪些被平台锁死这个问题在别的维度上也一样成立。

顺带说一件不该做的事：别为了图片格式去堆<picture>标签。我这批里59个站用了picture，但真正用source标签上的type属性声明格式的少得可怜——WebP九处、AVIF三处、JPEG两处、PNG一处。原因很简单：只要图片服务在做协商，标记层就不需要重复一遍同样的事，多写一层反而把逻辑分散到两个地方。MDN对picture元素的定位说得很明确，它解决的是艺术指导和尺寸选择，格式回退只是顺带能力。

这一轮的口径限制，一次说清

有几条边界得写在正文里，否则上面那些数字会被读得比它们该有的分量重。

每个站只测了一张图。挑的是首页上第一张能通过校验的真实商品图，它代表这个站的主图片管线，但不代表这个站所有的图——同一个站上完全可能有几条管线并行，尤其是那些既有自有CDN又接了第三方图片服务的。

定宽800这个数是我定的，不是各站的真实展示宽度。它的作用是把尺寸这个变量固定住，让三种格式之间可比；它不适合拿来讨论“这个站的图该是多宽”，那是声明宽度与真实像素那一轮的题目。

格式判定只认文件头的magic字节，不认扩展名也不认响应头。这个选择让判定极其可靠，代价是无法区分同一格式内部的编码差异——比如渐进式JPEG和基线JPEG在我这把尺子下都叫JPEG。

最后，13个站在采集尾段撞上了429。它们不是拦爬虫，是我自己的请求密度累到了共享边缘的阈值——同一批站在上一轮前端库版本普查里全都是200。把间隔拉长单独补跑之后，13个站全部恢复，数据完整。这条教训值得单独记：请求密度的瓶颈不只在“每个站发几个请求”，还在于这些请求是不是都落在同一家共享CDN上。

常见问题解答

我的站发的是WebP还是AVIF，怎么最快看出来？

用命令行请求一张商品图，看响应的Content-Type。更稳的做法是把文件下下来读前十二个字节：JPEG开头是两个固定字节，PNG有八字节签名，WebP是RIFF加WEBP，AVIF在第五到第十二字节能读到ftyp和avif。别看地址后缀，我这批里63个站的地址后缀写着jpg，实际发出去的多数不是JPEG。

把图片格式换成AVIF，排名会涨吗？

不会直接涨。格式不是排名信号，它影响的是文件体积，体积影响加载速度，速度是页面体验的一部分——这条链路有三级传导，每一级都会衰减。真正能感知到的场景是首屏那张大图确实卡住了加载，其余情况下省下的字节更多体现在带宽账单和抓取成本上。

为什么我在浏览器里看到的是WebP，用命令行请求却拿到JPEG？

因为命令行工具默认发的Accept头通常是一个裸通配符，服务器读到之后没有任何理由挑新格式，就退回原始格式了。测协商必须自己把请求头写全，否则量到的是工具的行为不是站点的行为。

地址里写死fm=webp算不算好做法？

在今天不算错，但它把一个本该由客户端参与的决定固化成了模板里的常量。代价不在当下而在以后：将来想升级到新格式，得回去改模板；而做协商的那批站什么都不用做。如果你的图片服务支持自动格式，优先用自动那一档。

Shopify站主真的完全没法指定图片格式吗？

就image_url这个过滤器而言是的，它的format参数只接受pjpg和jpg。想绕过去只有一条路：把图片托管到平台之外的图片服务上，那样你就把决定权换了一个地方放，同时也换来了一套新的依赖。

那16个把WebP发给老浏览器的站，会有用户看不到图吗？

今天基本不会，因为不支持WebP的浏览器份额已经很小。真正的问题不是兼容性，是这条链路没有在读请求头——这意味着它也永远不会因为浏览器变强而自动给出更好的格式。

第一个访客拿到未转码原图这件事，我该怎么防？

上线新尺寸或清完缓存之后，用脚本把关键页面上的图片地址扫一遍，让转码提前发生。这件事只需要几十个请求，但能让所有真实访客避开那一次冷启动。要注意的是并不是所有管线都有这个问题，我这批102个站里只有5个出现，先测再动手。

这批数据能代表我的站吗？

样本是131个海外品牌电商站，Shopify占了大头，所以“六成发WebP”这个比例带着明显的平台色彩。能迁移的不是比例而是方法：三档请求头、定宽对照、连问三次看稳不稳，这三步在任何站上都能复现，二十分钟就能测出自己那一份答案。

权威参考资料