文章正文图压缩清单：10 张占 25 MB，显示宽度只有 242–367px

直接答案：36 篇文章页有 128 个正文图片元素（原图宽 ≥600px，115 个唯一尺寸），合计 59.05 MB；最大的 10 张就占 25.1 MB（42.4%），其中 8 张宽超 2500px、13 张字节/像素（bpp）>0.8。它们的显示宽度只有 242–367px。

方法：字节与尺寸按 URL 对齐

2026-11-11 07:44–07:52，36 篇文章页在 390×844 下用 CDP 加载（禁用缓存、不滚动），把每个 Image 响应的传输字节与 document.images 的原图/显示宽度按 URL 对齐；只保留原图宽 ≥600px 的图片。表内前十按尺寸去重，元素总数不去重。

结果：前十张 25.1 MB，显示只有 242–367px

最极端的 E22-2：原图 2508×1672、5,058 KB，显示宽度 242px，bpp 1.24——等于把一张 2500px 的照片塞进 242px 的框。E22-3 还有一张 8724×5818 的图（2,317 KB，bpp 0.047）：压缩效率不差，但尺寸本身过大，先缩尺寸就能省下大部分字节。

三条验收动作

1. 先按显示宽度出图。 390px 显示、2x 屏用 780px 宽；单图 ≤200 KB；超过 2500px 的原图先缩再传。
2. bpp >0.8 的转格式。 13 张优先转 WebP/JPEG；PNG 留给图标与透明图。
3. 把“原图宽 / 显示宽”作为编辑检查项。 比值超过 3 就退回重出，避免把相机原图直接上传。

局限

• 分层阈值：只统计原图宽 ≥600px；缩略图与图标不在内，相关结果见图片属性页。
• 不滚动：按需加载的图片不计；禁用缓存测首次访问。
• 去重口径：总量按元素计，前十按尺寸去重；同一图片跨页出现会分别计数。
• bpp 不是质量评分：只看压缩效率，不判断画质是否达标。
• 样本：10 站 36 页，属 pilot，不外推行业。

数据与复算

匿名数据：equipment-article-image-shortlist-2026.csv（128 行 × 7 列：原图宽高、显示宽、KB、bpp）。仓库内为 docs/research/2026-11-article-image-shortlist.csv。不发布图片 URL。

复算需要 CDP 的 loadingFinished.encodedDataLength 与 document.images 的 naturalWidth 对齐；只筛原图宽 ≥600 的图片。

数据来源与口径

1. 样本：同一批 10 站 36 篇文章页（2026-11-03 缓存 URL）。
2. 加载：2026-11-11 07:44–07:52，390×844、禁用缓存、2.5 秒等待、不滚动。
3. 字节：Network.loadingFinished.encodedDataLength，只取状态 200。
4. 尺寸：naturalWidth/Height 与 getBoundingClientRect().width；bpp = 字节 ÷（宽×高）。

常见问题

为什么只统计原图宽 ≥600px 的图？

这类图承担正文信息；缩略图/图标单独统计，避免把 17×17 图标混进“正文图字节”。本轮 128 个图片元素、115 个唯一尺寸。

显示宽度 242–367px，为什么原图要 2500px 以上？

多是编辑直接上传相机/设计原图，模板只做 CSS 缩放；浏览器仍下载原图，浪费带宽与解码时间。

最大的 10 张占 42.4%，怎么算的？

按每张图片的传输字节排序，前十张合计 25.1 MB；同一图片在多页重复出现时分别计入元素，表内按尺寸去重展示。

字节/像素（bpp）说明什么？

bpp 高说明压缩效率低，常见于 PNG 照片；>0.8 的 13 张优先转 WebP/JPEG。bpp 低但尺寸巨大（如 8724×5818、0.047）仍要先缩尺寸。

应该缩到多大？

按 390px 显示、2x 屏需要 780px 宽；单图 200 KB 以内。超过 2500px 的原图先缩到 780–1200px，再决定格式。

能代表装备行业吗？

不能。10 站 36 页，属 pilot；数字只描述这批文章页在 2026-11-11 的图片交付。