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: LCP 1.4s. Highest-share bucket: LCP 1.6s. r = +0.39.
Passing LCP 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 LCP.
Picture swings the hardest: 81% of sites pass LCP with few, 89% with many. computed
Few vs many - does quantity cost LCP? 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.
More None costs the most: the LCP pass rate falls from 84% with few to 77% with many. 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, Image separates passing sites from failing sites the most. Where Image is rare: 85% pass the LCP. Where it is common: 78%.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.