fetchpriority 实测 27 个首页：只有 4 个站把 high 给了第一张图

实测 · 2026-09-01 · 27 个首页 · 各请求一次 · img / link / script 上的 fetchpriority

样本 / 口径：30 个站在 2026-09-01 各发一次 GET，桌面 Chrome UA（不是 Googlebot），跟随跳转，不执行 JavaScript。剔掉 3 个 —— stackoverflow.com 与 medium.com 返回 403，www.reddit.com 只回了一个 8,393 字节的空壳 —— 纳入 27 个。从服务器交付的那份 HTML 里正则取出全部 <img>、<link>、<script>、<iframe> 开标签，再在其中匹配 fetchpriority=。

2026-09-01 这天读到的 27 个首页里，把 fetchpriority="high" 写在 HTML 第一张 <img> 上的只有 4 个站。同一批页面上带 fetchpriority 的标签一共 223 个，其中 217 个带了取值 —— 而这 217 个里，129 个写的是 low，写 high 的只有 45 个。这个属性在真实首页上主要不是用来抬图的。

怎么测的

每站一次 GET，桌面 Chrome UA 而不是 Googlebot，跟随跳转，不重试。全程不渲染，所以下面每个数字说的都是服务器交付的那份 HTML。本机出口在日本大阪 —— 有些站会按地区发不同的标记，这一条得写在前面。

计数用的是正则扫开标签，不是完整解析：把 <img>、<link>、<script>、<iframe> 全部取出来，再在里面找 fetchpriority= 并读出它后面的值。这样会得到两个数，差 6 个：223 个标签带了这个属性，其中 217 个带了取值，6 个是空的。下面所有按取值的拆分都是 217 这个口径。同一遍扫描数到 1,556 个 <img>，凡是谈图片的分母都是这个数。

# 在自己的页面上数同样两个数
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ > page.html
grep -oiE '<(img|link|script|iframe)[^>]*>' page.html | grep -ci 'fetchpriority='
grep -oiE '<(img|link|script|iframe)[^>]*>' page.html \
  | grep -oiE 'fetchpriority=.?[a-z]+' | sort | uniq -c

这次有两件事测不到。脚本在运行时插进来的属性我们看不见，所以一个页面如果是加载后才补上 fetchpriority，在这份数据里就是 0。另一件更要紧：本次没有做任何性能测量 —— 没有现场数据，没有实验室跑分，27 个页面一个 LCP 元素都没识别过。这些属性有没有让其中任何一个站变快，我们不知道。

不执行脚本读到的是下限，不是判决，因为 Google 的渲染是另一条队列。Search Central 把顺序写得很直白：「Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript.」（Understand the JavaScript SEO basics，2026-09-01 访问。）

27 个站里只有 4 个把 high 给了第一张图

这个属性最标准的用法，就是首屏那张大图：给它标上 high，浏览器会先去取它。样本里做到这一步的是 arstechnica.com、astro.build、www.cloudflare.com、www.nytimes.com 四个站，剩下 23 个没有。

「第一张图」这个判据很粗，粗在哪必须说清楚。源码顺序里的第一个 <img> 只是最大绘制元素的一个候选，不等于它本身。真正的主视觉完全可以放在 CSS 里、放在 <picture> 里，或者压根在文档中段。这 27 个页面我们一个 LCP 元素都没识别，也一次速度都没测。4 是一个标记写法的计数。它不是成绩单。

129 处 low 对 45 处 high：fetchpriority 主要在压低东西

把 217 处按元素和按值拆开，形状一眼就出来了。low 那一列不是零头，它是这个属性在样本里的主要用途。

这 129 处集中在极少数几家手里。www.framer.com 一家 99 处，全是 low；github.com 12 处，全是 low；supabase.com 8 处，也全是 low。三个站，129 里的 119。一个共同动作：把可以等的东西标出来。

45 处 high 落的位置完全不同。developer.mozilla.org 一家占 20 处，全在 <link> 上，旁边还有 2 处 low。stripe.com 4 处全是 high。www.nytimes.com 有 10 处在图片上。样本里几乎找不到那种「抬起一张主图、其余不动」的干净写法。

它在 link 上出现 153 次，在 img 上只有 61 次

153 对 61，两倍半还多，而这是一批图片元素数量远超其它元素的页面。61 处里还有 43 处写的是 auto，也就是说 27 个首页、1,556 张图片，真正标了 high 的是 17 处，标 low 的 1 处。

逐站看，分布的样子和大多数构建流水线开关一样：少数几个站到处都写，多数站一处也没有。

再往下是 techcrunch.com 4 处，railway.com、webflow.com、www.theverge.com 各 2 处，还有九个站各 1 处。27 个里有 7 个一处都没写：about.gitlab.com、news.ycombinator.com、react.dev、slack.com、www.bbc.com、www.notion.com、www.wikipedia.org。

43 处 auto 写了等于没写，其中 23 处来自同一个站

auto 是这个属性的默认值。写上它，浏览器待的位置和什么都不写完全一样，所以这 43 处是「属性在，但不产生任何差别」。

www.netlify.com 一家占了 23 处，而且是彻底的：它那 23 张图，每一张都带 fetchpriority="auto"。另外 20 处在 www.nytimes.com，那个站同时还有 10 张图标着 high。一个值被一模一样地铺到页面上每一张图，读起来更像模板批量输出的默认值，不像有人逐张图判断过。这没什么错 —— 它只是几十字节，不改变任何行为，代价比同一页上的一行 CSS 还小。

被 217 这个口径排除在外的那 6 个，是同一件事再往前一步。6 个全在 webflow.com 上，写法都是 fetchpriority=""，而且每一个所在的 <img> 上还配着一个同样空着的 loading=""。模板把属性名打出来了，没走到填值那一步。netlify 那 23 张是填了默认值，这 6 个是连值都还没填上。

116 条图片预加载，只有 8 条带优先级

27 个首页合计发出 116 条 <link rel="preload" as="image">。其中 8 条同时写了优先级：stripe.com 4 条，substack.com、webflow.com、www.theverge.com、www.wired.com 各 1 条。

预加载图片最多的三个站一条都没写。react.dev 30 条、www.notion.com 24 条、supabase.com 22 条 —— 76 条预加载，0 条优先级。不管这些预加载清单是怎么定下来的，优先级显然是另一场没发生的讨论。

「预加载」和「给优先级」是两个决定。这 27 个首页上，116 条预加载里有 108 条只做了前一个。

这对你的站意味着什么

四件事，按回报排。第一件不花钱，也最常被跳过。

1. 先数清楚你的框架已经替你写了多少，再决定要不要加。本篇最大的两个站内数字 99 和 23，看形状都像构建工具在给某一类元素批量盖章。
2. 想让某一张图早点到，就只给那一张写 high，别的都不写。同一个值铺满全部图片，等于没有排出任何先后。
3. 看到 auto 就删掉。它是默认值，删掉之后行为一点不变，HTML 还小一圈。
4. 已经在预加载图片的，把优先级当成另一个单独的决定来做。这批样本里，两个属性同时出现的比例是 116 分之 8。

同一批站、同一天、换个属性量：同一张图给了几档文件写在 srcset 实测 1,664 张首页图片，加载时机写在 首页第一张图的懒加载。这些东西到底影不影响搜索结果，是个更旧也更难说清的问题，放在 core web vitals 值不值得做。想看引擎在不跑脚本的情况下从你自己的页面拿到什么，可以 看看 QueryWin 怎么读一个页面。

常见问题

你们是怎么测的？

2026-09-01 每个首页发一次 GET，桌面 Chrome UA，跟随跳转，正文落盘，然后用正则扫过全部 <img>、<link>、<script>、<iframe> 开标签，找 fetchpriority= 和它的值。223 个标签带这个属性，217 个带取值，6 个是空值，按取值的表都是 217 的口径。不执行 JavaScript。出口在日本大阪。

fetchpriority=auto 有用吗？

它是默认值，写与不写浏览器的行为一样。这批样本 217 处里有 43 处是 auto，其中 23 处来自同一个站 —— 它给自己全部 23 张图都写了这一个值。要说它有什么用，也就是让人一眼看出这段标记是模板生成的。

preload 和 fetchpriority 要一起写吗？

这两件事回答的问题不同，样本里多数站只回答了其中一个。2026-09-01 数到的 116 条图片预加载中，8 条同时设了优先级。哪种写法更快，我们没有测量，要拿到结论得跑一轮这次没做的实验室测试。

这个属性会影响排名吗？

这份数据说不了这件事。我们在一天里数了交付 HTML 里的属性，没有速度、没有 LCP 元素、没有任何搜索位置。谁要是从这类数字里读出了方向，那个方向不是数字给的。

为什么要连 link 和 script 一起数？

因为这个属性主要就长在那儿。只数 <img> 的话会得到 61 处，漏掉另外 156 处，包括 <link> 上那 125 处 low —— 而本篇的结论正是它们撑起来的。