Article body images: the top 10 take 25 MB while displayed at 242-367px

Direct answer: the 36 article pages carry 128 body-image elements (intrinsic width at least 600px, 115 unique sizes) totalling 59.05 MB; the ten largest alone take 25.1 MB (42.4%), with eight wider than 2500px and 13 above 0.8 bytes per pixel. Their display width is only 242-367px.

Method: join bytes and sizes by URL

On 2026-11-11 between 07:44 and 07:52 we loaded the 36 article pages at 390x844 with CDP (cache disabled, no scrolling) and joined each Image response's transfer bytes with the intrinsic and rendered width of document.images by URL, keeping only images at least 600px wide. The table de-duplicates by size; the element totals do not.

Result: the top ten take 25.1 MB and display at 242-367px

The extreme case is E22-2: a 2508x1672 original of 5,058 KB shown at 242px with bpp 1.24 — a 2500px photo inside a 242px box. E22-3 also carries an 8724x5818 image (2,317 KB, bpp 0.047): compression is fine, but the dimensions alone are excessive — downscaling saves most of the bytes.

Three acceptance actions

1. Export for the display width. 780px for a 390px slot at 2x, 200 KB per image; downscale originals above 2500px before upload.
2. Convert anything above 0.8 bpp. 13 images should move to WebP/JPEG; keep PNG for icons and transparency.
3. Check intrinsic-to-display ratio in the editor. Above 3, send it back for re-export instead of uploading camera originals.

Limits

• Layer threshold: only intrinsic width at least 600px counts; thumbnails and icons are excluded (see the image-attribute page).
• No scrolling: on-demand images are excluded; cache disabled measures the first visit.
• Deduplication: totals count elements, the top ten de-duplicate by size; the same image on several pages counts each time.
• bpp is not a quality score: it measures compression efficiency, not whether the image looks acceptable.
• Sample: 10 sites and 36 pages; a pilot, not an industry estimate.

Data and reproduction

Anonymised data: equipment-article-image-shortlist-2026.csv (128 rows by 7 columns: intrinsic width/height, display width, KB, bpp). The repository keeps docs/research/2026-11-article-image-shortlist.csv. No image URLs are published.

Reproduction needs the CDP loadingFinished.encodedDataLength joined with document.images naturalWidth; filter to intrinsic width at least 600px.

Sources and definitions

1. Sample: the same 10 sites and 36 article pages (cached URLs from 2026-11-03).
2. Load: 2026-11-11 07:44–07:52, 390x844, cache disabled, 2.5-second wait, no scrolling.
3. Bytes: Network.loadingFinished.encodedDataLength, status 200 only.
4. Sizes: naturalWidth/Height and getBoundingClientRect().width; bpp = bytes / (width x height).

Frequently asked questions

Why only images at least 600px wide intrinsically?

They carry the article content; thumbnails and icons are counted separately so 17x17 icons do not inflate “body image bytes”. This round has 128 image elements and 115 unique sizes.

Displayed at 242-367px, why ship 2500px originals?

Editors usually upload camera or design originals and the template only scales with CSS; the browser still downloads the original, wasting bandwidth and decode time.

How is the top-10 42.4% share calculated?

Images are sorted by transfer bytes and the first ten total 25.1 MB; the same image repeated on several pages counts per element, while the table de-duplicates by size.

What does bytes per pixel mean?

High bpp means poor compression, common for photographic PNGs; the 13 images above 0.8 should move to WebP/JPEG. A low bpp with huge dimensions (8724x5818 at 0.047) still needs downscaling first.

What size should they be?

780px wide for a 390px slot at 2x, with a 200 KB per-image budget. Downscale originals above 2500px to 780-1200px first, then choose the format.

Is this representative of the equipment industry?

No. 10 sites and 36 pages; a pilot. The numbers describe these article pages' image delivery on 2026-11-11.