1,677 张首页图片：67% 标了 loading lazy，9 个站连第一张也标了
loading lazy 在 27 个首页的 1,677 张图上是什么分布：1,123 张标了 lazy、133 张 eager、421 张什么都没标。2026-08-22 单次抓取，另有 9 个站把文档里第一张图也延后了。
实测 · 2026-08-22 · 27 个首页 · 1,677 张图 · 单次抓取
样本与口径：2026-08-15 起一直在用的那 30 个站，2026-08-22 每站首页抓一次，浏览器 UA。把交付 HTML 里每个 <img> 按文档顺序记下来，连同它的 loading、fetchpriority 和 decoding 属性。
如果你正在给全站图片加 loading lazy，先看一眼这批数据落在哪一格：1,677 张图里 1,123 张标了 lazy，133 张标了 eager，421 张什么都没标。真正值得看的是另一个数 —— 27 个站里有 9 个，把文档里的第一张图也标成了 lazy。Google 自己的性能文档明说这件事不该做，不过后面有个前提要交代。
怎么测的
每站一次 HTTP 请求，不渲染、不重试。纳入规则跑数前定死：状态 200、响应体不少于 10,000 字节、含 <body。30 个里 3 个没过 —— stackoverflow.com 和 medium.com 回 403，www.reddit.com 回的是 8,393 字节的空壳 —— 剩下 27 个首页。
文档顺序不等于绘制顺序。我们记的是「HTML 里第一个 <img>」，不是「屏幕上最大的那块」。这两件事的差距，是本篇最要紧的一段。
标 loading lazy 的占了三分之二
四分之一的图什么属性都没有。按 MDN 的说法，那等于 eager —— 它是这个属性的默认值。
| 取值 | 张数 | 占比 |
|---|---|---|
loading="lazy" | 1,123 | 67.0% |
| 没有属性（默认 eager） | 421 | 25.1% |
loading="eager" | 133 | 7.9% |
三个站是全标：developer.mozilla.org（1/1）、www.netlify.com（23/23）、github.com（24/24），一张不落。三个站是全不标：www.canva.com 26 张图上一个 loading 属性都没有，Hacker News 的 3 张和 Wikipedia 的 1 张同样是光的。
Cloudflare 是这批里的反面：66 张图里 64 张显式写了 eager，1 张 lazy，1 张没属性，而第一张带的是 fetchpriority="high"。
Google 是怎么说第一张图的
web.dev 上两页说的是同一件事，语气不同。《Browser-level image lazy loading for the web》页面标注更新于 2024-08-13，2026-08-22 读到的原文：「Caution: Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.」同页还写着，首屏可见的图应当「use the browser's default eager loading so they can be available right away」。
《Optimize Largest Contentful Paint》标注更新于 2025-03-31，同日读到的原文把余地也收了：「Warning: Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.」反过来那一半它也给了：图片重要就「use Fetch Priority with fetchpriority="high"」。
懒加载是在决定「读者暂时看不到什么」。第一张图恰恰是他最先看到的。
9 个站把第一张图延后了
把这 9 张图具体是什么列出来，这个数的读法就变了。
| 站点 | 第一张图 | 属性 |
|---|---|---|
| railway.com | hero/bg-train-day-960.webp | lazy，fetchpriority="low" |
| discord.com | 品牌字标 SVG | lazy |
| techcrunch.com | 站点标识 SVG | lazy |
| www.netlify.com | 一张客户 logo SVG | lazy，fetchpriority="auto" |
| github.com | particles-170bd1fd231f4669.png | lazy |
| linear.app | CDN 下发的图 | lazy |
| www.notion.com | 导航区图标，宽 384 | lazy |
| webflow.com | CDN 下发的图 | lazy |
| developer.mozilla.org | 贡献者头像 | lazy |
大半是 logo 和图标，体积小、也不是任何人屏幕上最大的那块，延后几乎不花钱。Railway 那张是另一回事：它是主视觉背景，而紧挨着的下一张是同一张主视觉的另一种配色，标着 loading="eager" 加 fetchpriority="high"。一延一抢，这是刻意配的一对，光数属性数不出来。
几乎没人用 fetchpriority
27 个首页里只有 8 个给任何一张图设过 fetchpriority="high"，其中 6 个只设了一次。
| 站点 | 高优先级图 |
|---|---|
| www.nytimes.com | 6 张 |
| www.cloudflare.com | 1 张（主视觉） |
| arstechnica.com | 1 张（头条配图） |
| www.theverge.com | 1 张 |
| railway、webflow、shopify、techcrunch | 各 1 张 |
剩下 19 个站，所有图都留在浏览器的默认优先级上。顺带说一个小意外：The Verge 首页 HTML 里第一个 <img> 是 noscript 里那枚指向 google-analytics.com 的统计像素，第二张才是头条图，而那张确实带了高优先级。整批站一共只有 6 个 <iframe>，没有一个是懒加载的。
这次测不到的部分
测不出这 27 个页面里哪个元素是 LCP。那是绘制时由视口大小、CSS、字体和网络一起决定的，单次服务端抓取一个都看不到。所以「9 个站延迟了第一张图」是标记层的事实，只是性能层的一个假设。
我们没有量任何一个站的 LCP，也不打算拿属性计数冒充性能结论。这 9 个里可能有两个真的慢了半秒，也可能有七个只是延迟了一张 4 KB 的 logo，什么都没损失。
还有一层：CSS 背景图同样可以是 LCP 元素，而这次解析完全看不见它。主视觉是从样式表里画出来的站，它的 <img> 属性说明不了渲染有多快。
对做站的人意味着什么
这个检查两分钟就能做完，而且是一套模板做一次，不是一张图做一次。
- 打开页面，先认出首屏里最大的那块是什么，再去看那个元素的标记 —— 不是看文件里第一个。
- 给它加
fetchpriority="high"，并且不要加懒加载。这 27 个站里有 19 个从来没设过任何优先级。 - 别因为主题里有「全站图片懒加载」这个开关就整站打开。这批站三分之二已经是这样了，而在页面顶部，这个默认不是白拿的。
- 别把没写属性的
<img>当成疏漏。不写就是 eager，在首屏那是对的答案。
读交付的原始 HTML 而不是渲染后的页面，正是 QueryWin 的检查项在做的事；同一次解析还产出了这批站的图片 alt 实测。想知道这些页面回一个字节要多久，看首字节耗时那篇 —— 那次的结论是测量本身的问题比站点的问题更大。
常见问题
你们是怎么测的
2026-08-22 每站首页抓一次，浏览器 UA，不执行 JavaScript。按文档顺序记录每个 <img> 的 loading、fetchpriority、decoding。不渲染，不重试。
lazy 和 eager 有什么区别
eager 是页面加载时就取，不管它在不在视口里；lazy 是等它靠近视口才取。按 MDN 的说法 eager 是默认值，所以没写 loading 属性的图，行为就是 eager。
是不是所有图片都该加懒加载
不是。Google 的说法很明确：首屏可能可见的图，尤其是 LCP 那张，不该延后。首屏以下随便加。
懒加载会影响 SEO 吗
延迟 LCP 那张图会影响 Largest Contentful Paint，这是有文档的核心网页指标。它会不会改变你在某个搜索里的位置，这次没测，我们也不猜。
