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 fast each group loads
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: INP 50ms. Highest-share bucket: INP 49ms. r = +0.42.
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 Low, at 0 points. 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.