Responsive image markup
Responsive markup on images: srcset / picture vs plain img.
At a glance the headline numbers for Responsive image markup
Responsive markup on images: srcset / picture vs plain img.
68.6% of images ship without responsive markup.
The responsive image markup mix who uses what, and how fast each group loads
Responsive image markup. On the fleet: 68.6% none, 22.9% image, 8.5% picture. 89.1% of sites use at least one none.
Lowest-share bucket: INP 50ms. Highest-share bucket: INP 49ms. r = +0.37.
Passing INP per bucket every category and count level at once - color is the pass rate
Each row is a category, each column its own count bucket (few on the left, many on the right); the cell is the share of those sites passing INP.
No category moves the INP pass rate much, however many a site ships. computed
Few vs many - does quantity cost INP? the pass rate with few vs many of each category
Per category: the pass rate among pages with FEW of it (hollow ring) against pages with MANY (solid dot), worst trend first. Thin buckets are excluded from the endpoints.
Quantity barely moves INP here. The worst trend is None, at 0 points. computed
Why this matters for the Core Web Vitals, and where to start fixing it
srcset exists because devices disagree about pixels. A plain img serves the same file to a small phone and a 5K display: too many bytes for one, too few pixels for the other. Responsive markup lets the browser pick per device, and on the hero image the saved bytes are LCP bytes.
Responsive markup still needs width and height for the CLS side: srcset picks the file, the dimensions reserve the box. Most CMSs generate the candidates automatically. The gaps are hand-written templates.
How does this affect the Core Web Vitals?
Of the 3 categories, Picture separates passing sites from failing sites the most. Where Picture is rare: 85% pass the LCP. Where it is common: 90%.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.