首页首屏图交付：24/25 站不按屏切换，390px 中位 1,152 KB

直接答案：25 个首页里，只有 1 站（E14）用 <picture>/<source srcset> 给 390px 换了小图，0 站用 <img srcset>；其余 24 站把一张大图交给 CSS 缩小显示。24 站可计量字节：390px 首屏图片中位 1,152 KB，1440px 中位 1,145 KB——中位比值 1.00；合计 50.66 MB 对 65.29 MB（77.6%）。109 张首屏 <img> 里 56 张原图宽超过显示宽 2 倍（26 张超 3 倍）。

方法：同一页面，两种视口

2026-11-11 09:24–09:34，用 CDP 依次加载同一批 25 个首页缓存 URL，在 390×844 与 1440×900 下各测一次。两次使用同一桌面 UA，只改视口，目的是隔离 CSS 断点与响应式选择；移动 UA 跳转/独立移动站不在本轮范围。禁用缓存、不滚动，等 readyState=complete 后再等 3 秒。

首屏图片包含两类：与视口相交的 <img>（宽 ≥80、高 ≥40），以及计算样式 background-image 为 URL 的首屏元素。每页按 URL 去重，传输字节取 Network.loadingFinished.encodedDataLength（只取 200）。25 站全部可加载，其中 24 站能取到首屏图片字节；E16 的图片主机未返回可计量字节，字节统计排除该站，但仍计入属性审计。

结果一：只有 1 站按屏换图

实时 DOM 中，E14 有 7 个 <picture>、14 个 <source srcset>：390px 取 560–750px 变体，首屏合计 1,205 KB；1440px 取 1,920px，合计 2,315 KB——移动端少 48%。这是本轮唯一一个“改了 markup 且真的换了文件”的样本。

其余 24 站没有 img[srcset]；全部 25 站都没有 img[sizes]。22 站的首屏 <img> 最大原宽中位 1,434px，10 站 ≥1,920px，最大 2,880px；浏览器下载原文件，由 CSS 缩小显示。结果是两种视口的字节几乎相同：中位 1,152 KB 对 1,145 KB，中位比值 1.00；24 站里 16 站移动端达到桌面的 90% 以上，11 站甚至更高（移动布局堆叠了更多图片）。

按 390px 首屏字节排序的前 10 站；“比值”= 390px ÷ 1440px；“最大 img”按传输字节取该页最大一张 <img>。表格可横向滑动。E25 的 1,440px 层在 390 视口内被裁切，显示宽按元素盒记录。

结果二：一半首屏图宽于显示宽 2 倍

109 张首屏 <img>（原图宽 ≥300px）里，56 张原图宽超过显示宽 2 倍，26 张超过 3 倍，分布在 13 个页面。最极端的是 E29 的一张 2,596px 图，显示宽 300px（8.65 倍），传输 1,444 KB；E19 的 1,920px 轮播图显示 390px（4.92 倍），单张 2,720 KB。

传输字节最大的 10 张首屏图合计 22.83 MB，占 24 站首屏图片总字节的 45.1%。其中 E12 的一张 800×500 JPEG 传输 7,357 KB——像素不大，字节异常（服务器 gzip 后 7.36 MB，解码后 23.3 MB），说明只看像素尺寸会漏掉这类文件。

为什么“写了 srcset”也不一定生效

• 缺 sizes：只有宽度描述符、没有 sizes 时，浏览器按 100vw 估算，候选集可能仍落到最大图。
• 候选集相同：srcset 里只放同一张图的不同缩放地址，或所有候选都大于实际需要，等于没换。
• 背景图没有 srcset：首屏大图常用 CSS background-image，媒体查询只换 URL 不换尺寸时，移动端仍下原图。
• 页面构建器：模板只输出一个上传地址时，编辑无法在内容层补响应式候选。

三条验收动作

1. 给首屏图补 srcset + sizes：至少 780w 与 1440w 两档；390px 槽位用 780w（2x），桌面用 1440w。
2. 需要裁切构图时用 picture/source：E14 的做法把移动端首屏字节从 2,315 KB 降到 1,205 KB，可直接复用。
3. 把“390px 首屏图片 ≤500 KB”写进验收：在 DevTools 切换两种视口，比较 currentSrc 与 Network 字节；只改 CSS 宽度不算通过。需要把这条写进网站验收？见网站建设服务。

局限

• 只算 img 与背景图：video poster、canvas、内联 SVG 不计；装饰性背景可能被算进首屏字节。
• 不滚动：首屏以下的懒加载图片不在内；首屏内延迟加载的图可能被低估。
• 同一桌面 UA：移动 UA 跳转、独立移动站与 APP 下载页不在本轮范围。
• 字节不等于 LCP：只测传输量，不测解码、渲染与 LCP 时间。
• 异常样本：E12 的 800×500 JPEG 传输 7,357 KB（解码 23.3 MB），会抬高总字节与 Top10 占比。
• 样本：25 个首页、24 站可计量，属 pilot，不外推行业。

数据与复算

页面级数据：equipment-home-firstscreen-pages-2026.csv（25 行：两种视口首屏字节、比值、图片数、srcset/picture 计数、最大图尺寸与倍数）。图片级数据：equipment-home-firstscreen-images-2026.csv（220 个 390px 首屏条目，来自 50 条视口记录：类型、原图宽高、显示宽高、KB、倍数、字节/显示像素）。仓库内为 docs/research/2026-11-home-firstscreen-pages.csv 与 docs/research/2026-11-home-firstscreen-images.csv。不发布站点名、图片 URL。

复算需要 CDP：设置视口 → 禁用缓存 → 加载 → 收集 document.images 与计算样式 background-image 的首屏元素 → 按 URL 对齐 loadingFinished.encodedDataLength。比值 = naturalWidth ÷ 显示宽。

数据来源与口径

1. 样本：同一批 25 个首页（2026-11-02 缓存 URL，E01–E30 中可用的 25 个）。
2. 加载：2026-11-11 09:24–09:34，390×844 与 1440×900，同一桌面 UA、禁用缓存、不滚动、等待 3 秒。
3. 字节：Network.loadingFinished.encodedDataLength，只取 HTTP 200；每页按图片 URL 去重。
4. 首屏：元素与视口相交，宽 ≥80、高 ≥40；<img> 另要求原图宽 ≥300 才进入“倍数”统计。

常见问题

为什么 390px 与 1440px 中位几乎一样？

24 站可计量页面的首屏图片传输字节中位为 390px 1,152 KB、1440px 1,145 KB，中位比值 1.00。多数页面只有一张大图，靠 CSS 宽度缩放；浏览器在两种视口下载同一文件。

怎样算“按屏切换”？

以实时 DOM 的 srcset/sizes/picture/source 为准，并在 390 与 1440 下比较 currentSrc 与字节。只有属性、但 sizes 缺失或候选集相同，不算真正切换。

25 站里只有 1 站做了？

本轮实时 DOM 中，E14 有 7 个 picture、14 个 source[srcset]，390px 取 560–750px 变体，1440px 取 1920px；其余 24 站没有 img[srcset]，0 站有 img[sizes]。25 站属 pilot，不能外推行业。

为什么 390px 有时比 1440px 还大？

24 站里 11 站移动端首屏字节更高：移动布局把轮播、卡片纵向堆叠，首屏出现更多图片；桌面端只露出一部分。字节应按版式比较，不能假设移动一定更轻。

背景图也算进去了吗？

算。除了 img 元素，还统计首屏内计算样式 background-image 的元素，并按 URL 去重取传输字节；纯装饰背景可能被计入，这是口径的一部分。

E12 的 7,357 KB 是怎么回事？

E12 首屏一张 800×500 的 JPEG 传输 7,357 KB（服务器 gzip 后的传输字节，解码后 23.3 MB），显示 390×244。它是异常样本，说明“像素不大”不等于“字节不大”。

能代表装备行业吗？

不能。25 个首页、24 站可计量，属 pilot；结论只描述这批页面在 2026-11-11 的首屏图片交付。

和正文图 780px 重编码那篇什么关系？

那篇测“把图缩到 780px 能省多少”，这篇测“首页实际有没有按屏交付”。一个给改造收益，一个给现状缺口；两批样本不同，不能直接相乘。