Improving Core Web Vitals: The Order That Really Helps

Switching on a caching plugin is the first step and often the only one anyone takes. After that, the score sits at “needs improvement” and stays there. The reason: the three metrics measure three different things, and caching only really helps with one of them.

The three metrics, one sentence each

That dictates the order: images first, then scripts, then layout. Caching mainly affects server time — so part of LCP, and INP hardly at all.

Step 1: The largest image

On most pages, the hero image is the LCP candidate. Three things help right away, in this order:

1. Scale it down to the size actually needed — a 4000-pixel-wide photo in a 1200-pixel-wide area is the most common single cause.
2. Convert it to a modern format (WebP or AVIF), with a fallback for older browsers.
3. Do NOT lazy-load it. The image at the very top should load immediately — Lazy-Load makes the score worse here instead of better.

Check where the conversion happens. Some plugins send your images to a service run by the vendor for this. If you don't want that, you need a tool that converts locally — the first pass takes longer, but nothing leaves the building.

Step 2: The JavaScript

INP is the metric that caching doesn't help with. It measures how long the browser takes to respond to a click — and it gets blocked by scripts that are busy at exactly that moment.

The most effective lever is leaving things out: a slider nobody uses; a chat window on every page; three font families, two of which nobody notices. Only after that do defer, combining, and delaying until the first interaction pay off.

Step 3: Stop the jumping

• Every image needs width and height in the markup — then the browser reserves the space
• Put embedded content in a container with a fixed height
• Serve fonts locally and control them with font-display instead of loading them from outside
• Build cookie banners and notice bars so they overlay the content instead of pushing it around

Only then: caching, Minify, Preload

A page cache saves generating the page — that's a lot when the server is slow, and little when it's fast. Minify saves bytes and is the most common cause of broken pages after an optimization. Preload is an instruction, not a request: too many of them crowd out exactly what's needed first.

Switch on Minify one setting at a time and check a form page, the cart, and a page with a video each time. If you switch everything on at once, you'll be searching through ten toggles when something goes wrong.

Measuring correctly

Two kinds of measurement need to be kept apart. A lab test measures under fixed conditions and is good for comparing before and after. Field data comes from real visitors with real devices and connections — it decides how Google rates the page.

So: always measure under the same conditions, three times instead of once — and field data takes weeks before a change shows up. If you check after an hour and notice nothing, you haven't optimized too little; you've looked too soon.

When the plugin no longer helps

There's a limit beyond which no caching plugin can get any further: an overloaded page builder with thirty scripts, a hosting provider with a high base load, a theme that loads everything on every page. If the server response is already slow without any content, the plugin isn't the problem.

Frequently asked questions