Image fetchpriority
fetchpriority attributes on images: high, low or default.
At a glance the headline numbers for Image fetchpriority
fetchpriority attributes on images: high, low or default.
2.3% of images carry fetchpriority=high.
The image fetchpriority mix who uses what, and how stable each group is
Image fetchpriority. On the fleet: 96.6% auto, 2.3% high, 1.0% low. 95.4% of sites use at least one auto.
Lowest-share bucket: CLS 0.01. Highest-share bucket: CLS 0.03. r = +0.46.
Passing CLS 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 CLS.
Low swings the hardest: 78% of sites pass CLS with few, 87% with many. computed
Few vs many - does quantity cost CLS? 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 Auto costs the most: the CLS pass rate falls from 80% with few to 76% with many. computed
Why this matters for the Core Web Vitals, and where to start fixing it
fetchpriority overrides the browser's guess about which images matter. high on the hero pulls it forward in the download queue. low on hidden carousel frames and footer logos pushes them out of the way of the critical path.
The pattern that works: exactly one high (the LCP image), low on things that visibly do not matter, default everywhere else. The signal only means something while it is rare.
How does this affect the Core Web Vitals?
Of the 3 categories, High separates passing sites from failing sites the most. Where High is rare: 88% pass the LCP. Where it is common: 80%.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.