Homepage first-screen images: 24 of 25 don't adapt at 390px

Direct answer: of 25 homepages, only one (E14) uses <picture>/<source srcset> to serve smaller files at 390px, and none uses <img srcset>; the other 24 scale a large image down with CSS. Across 24 measurable sites the first-screen image median is 1,152 KB at 390px and 1,145 KB at 1440px — a median ratio of 1.00 — with totals of 50.66 MB versus 65.29 MB (77.6%). Of 109 first-screen <img> elements, 56 are more than twice their display width (26 above 3x).

Method: one page, two viewports

Between 09:24 and 09:34 on 2026-11-11 we loaded the same 25 cached homepage URLs through CDP at 390x844 and at 1440x900. Both runs use the same desktop user agent; only the viewport changes, isolating CSS breakpoints and responsive selection. Mobile-UA redirects and separate mobile sites are out of scope. Cache is disabled, we do not scroll, and we wait three seconds after readyState=complete.

First-screen images cover two kinds: <img> elements intersecting the viewport (width at least 80, height at least 40), and first-screen elements whose computed background-image resolves to a URL. Each page is de-duplicated by URL, and transfer bytes come from Network.loadingFinished.encodedDataLength (status 200 only). All 25 pages loaded; 24 yielded measurable first-screen bytes. E16's image host returned no measurable bytes, so it is excluded from byte totals but kept in the attribute audit.

Result 1: only one site switches files

In the live DOM, E14 has seven <picture> elements and 14 <source srcset> entries: 390px receives 560-750px variants for 1,205 KB, while 1440px receives 1,920px for 2,315 KB, 48% less on mobile. It is the only sample that both ships the markup and actually changes the file.

The other 24 have no img[srcset], and none of the 25 has img[sizes]. Across the 22 sites with a first-screen <img>, the largest intrinsic width has a median of 1,434px; 10 reach 1,920px or more, up to 2,880px. The browser downloads the original and CSS shrinks it. The consequence is near-identical bytes: a median of 1,152 KB versus 1,145 KB, a median ratio of 1.00. On 16 of 24 sites mobile reaches at least 90% of desktop bytes, and on 11 it is higher, because mobile layouts stack more images above the fold.

Top ten sites by 390px first-screen bytes. Ratio = 390px / 1440px. Largest img is the heaviest <img> on that page. The table scrolls sideways. E25's 1,440px layer is cropped by the 390px viewport; display width is the element box.

Result 2: half the first-screen images are at least 2x their display width

Of 109 first-screen <img> elements (intrinsic width at least 300px), 56 are more than twice their display width, 26 exceed 3x, spread over 13 pages. The extreme is a 2,596px image on E29 displayed at 300px (8.65x) for 1,444 KB; E19's 1,920px carousel image is shown at 390px (4.92x) for 2,720 KB.

The ten heaviest first-screen images total 22.83 MB, 45.1% of all first-screen image bytes on the 24 sites. Among them, an 800x500 JPEG on E12 transfers 7,357 KB — small in pixels, extreme in bytes (7.36 MB gzip-encoded, 23.3 MB decoded), a reminder that pixel dimensions alone hide such files.

Why srcset alone may not change anything

• Missing sizes: with width descriptors but no sizes, the browser assumes 100vw and may still pick the largest candidate.
• Same candidate set: srcset entries that all point at the same effective size change nothing.
• Background images: hero images set through CSS cannot carry srcset; media queries that swap URLs without swapping sizes still ship originals.
• Page builders: when the template emits one uploaded URL, editors cannot add responsive candidates in content.

Three acceptance actions

1. Add srcset + sizes to first-screen images: at least 780w and 1440w; 780w covers a 390px slot at 2x, 1440w covers desktop.
2. Use picture/source for art direction: E14's pattern cuts mobile first-screen bytes from 2,315 KB to 1,205 KB and is directly reusable.
3. Write "first-screen images at 390px under 500 KB" into acceptance: compare currentSrc and Network bytes at both widths; a CSS width change alone does not pass. To put this into a website acceptance checklist, see website services.

Limits

• img and backgrounds only: video posters, canvas and inline SVG are excluded; decorative backgrounds may be counted.
• No scrolling: below-the-fold lazy images are out; first-screen images that load late may be undercounted.
• Same desktop UA: mobile-UA redirects, separate mobile sites and app download pages are out of scope.
• Bytes are not LCP: transfer only; decode, render and LCP timing are not measured.
• Outlier: E12's 800x500 JPEG transfers 7,357 KB (23.3 MB decoded), inflating totals and the Top-10 share.
• Sample: 25 homepages, 24 measurable; a pilot, not an industry estimate.

Data and reproduction

Page-level data: equipment-home-firstscreen-pages-2026.csv (25 rows: bytes at both viewports, ratio, image counts, srcset/picture counts, largest image size and multiple). Image-level data: equipment-home-firstscreen-images-2026.csv (220 first-screen entries at 390px: kind, intrinsic and display size, KB, multiple, bytes per displayed pixel). In the repository they are docs/research/2026-11-home-firstscreen-pages.csv and docs/research/2026-11-home-firstscreen-images.csv. No site names or image URLs are published.

Reproduction needs CDP: set the viewport, disable cache, load, collect first-screen document.images and elements with a computed background-image, then join URLs with loadingFinished.encodedDataLength. Multiple = naturalWidth / display width.

Sources and definitions

1. Sample: the same 25 homepages (cached URLs from 2026-11-02, the 25 usable E01-E30 entries).
2. Load: 2026-11-11 09:24–09:34, 390x844 and 1440x900, same desktop UA, cache disabled, no scrolling, 3-second wait.
3. Bytes: Network.loadingFinished.encodedDataLength, HTTP 200 only, de-duplicated by image URL per page.
4. First screen: element intersects the viewport, width at least 80 and height at least 40; an <img> needs intrinsic width at least 300 to enter the multiple statistics.

Frequently asked questions

Why are the medians at 390px and 1440px almost the same?

Across the 24 measurable sites the first-screen image transfer median is 1,152 KB at 390px and 1,145 KB at 1440px, a median ratio of 1.00. Most pages ship one large file and scale it with CSS, so both viewports download the same bytes.

What counts as adapting to the screen?

Live-DOM srcset/sizes/picture/source plus a comparison of currentSrc and bytes at 390 and 1440. An attribute alone, with missing sizes or an unchanged candidate set, does not count.

Only one of 25 sites does this?

In the live DOM, E14 has seven picture elements and 14 source[srcset] entries; it serves 560-750px variants at 390px and 1920px at 1440px. The other 24 have no img[srcset], and none has img[sizes]. Twenty-five sites are a pilot, not an industry estimate.

Why is 390px sometimes heavier than 1440px?

On 11 of 24 sites the mobile first screen carries more image bytes: mobile layouts stack carousels and cards, so more images appear above the fold while desktop shows only part of them. Compare bytes per layout, not per assumption.

Are CSS background images included?

Yes. Besides img elements we counted first-screen elements whose computed background-image resolves to a URL, de-duplicated by URL and joined with transfer bytes. Purely decorative backgrounds may be included; that is part of the definition.

What is the 7,357 KB image on E12?

A single 800x500 JPEG on E12 transfers 7,357 KB (gzip-encoded transfer; 23.3 MB decoded) while displayed at 390x244. It is an outlier showing that small pixel dimensions do not guarantee small bytes.

Is this representative of the equipment industry?

No. Twenty-five homepages with 24 measurable are a pilot; the results describe these pages' first-screen image delivery on 2026-11-11.

How does this relate to the 780px re-encode article?

That article measures how much a 780px re-encode saves; this one measures whether homepages actually adapt delivery. One is the upside of a fix, the other the current gap; the samples differ and must not be multiplied.