What caching actually moves in Core Web Vitals, and what it does not
Caching improves one Core Web Vital reliably and the others barely at all. Knowing which is which stops you from expecting a cache to fix a layout problem, and stops you from ignoring the one thing it genuinely does fix.
What caching actually moves
Largest Contentful Paint measures when the biggest visible element finishes rendering. Its first component is how long the server takes to send the first byte, and that is precisely what caching collapses. Removing PHP, WordPress and the database from the request can take hundreds of milliseconds out of the front of the measurement on every cached page.
Cumulative Layout Shift is about elements moving after they appear. Interaction to Next Paint is about how quickly the page responds to input. Both are decided in the browser by your markup, your images and your JavaScript. A cached page and an uncached page with identical HTML have identical scores on both.
Which means the order of work is fixed
- Cache first. Cheapest and it moves LCP on every page at once.
- Then images. The largest element is usually an image. Correct dimensions, modern format, and no lazy loading on the one above the fold.
- Then layout stability. Reserve space for images, ads and embeds so nothing jumps. This is markup work and caching cannot help.
- Then scripts. Third party tags are the usual cause of poor responsiveness, and removing one is worth more than deferring three.
The trap on a cached site
Once caching is on, your own experience of the site stops being representative. You browse warm pages; a visitor arriving on a rarely read post from three years ago gets the cold one. If you only ever test the front page, you are measuring the best case on a network where most pages are long tail.
Test a page nobody has visited recently. That number is the one your visitors mostly experience, and on a content network it is also the number search engines encounter, since crawlers spend much of their time on exactly those pages.
Measure the field, not the laboratory
A synthetic test from one location on a fast connection tells you what is possible. Real user data tells you what happens. They differ most on precisely the sites where it matters: mobile visitors on slow connections in places your test tool does not run from.
If your audience is in one region, hosting in that region removes a fixed cost from every uncached request that no amount of tuning recovers. That is the reason for keeping European sites on European addresses rather than serving them across an ocean.
What to expect, honestly
- Caching: large, immediate LCP improvement on cached pages. No effect on CLS or INP.
- Image work: the second largest LCP gain, and often the largest on image heavy pages.
- Layout reservations: the only thing that fixes CLS.
- Removing scripts: the only thing that reliably fixes INP.
Vitals are one of many signals and improving them is not a shortcut to ranking. The reason to do the work is that a page which appears quickly and does not move under the reader's finger is a better page, and that holds whether or not any algorithm notices.
Google's own definitions are at web.dev. For getting caching consistent across many sites first, see Speed and Caching, and if the server itself is the bottleneck rather than the page, Platform and Limits.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.