At a glance the headline numbers for Cacheable responses
The share of responses that carry cacheable headers.
64.8% of responses on the typical site are cacheable.
Distribution & median LCP site count and median LCP at each level of cacheable responses
Passing LCP by cacheable responses which level passes the LCP most often
Cacheable responses 64.8%. p75 84.2%. p99 98.1%. At the low end (0–0): LCP 1.6s. At the high end (1+): LCP 1.1s. computed
Why this matters for the Core Web Vitals, and where to start fixing it
This is the share of responses a browser is allowed to keep. Everything outside that share gets re-downloaded on the next visit. Repeat visitors are in your field data too, and for them cacheability is the difference between reading from disk and crossing the network.
Uncacheable static assets are almost always an accident: a missing header on a font, a no-cache default on an image bucket. If a file has a hash in its name, there is no reason it should ever be fetched twice.
How does caching affect the Core Web Vitals?
Cacheable share correlates with the LCP. Where the cacheable share is low: 82% pass the LCP. Where it is high: 94%.
Chrome field data from 189,915 sites, representing millions of real page loads. How we measured.