Improving Core Web Vitals, without pretending it is a ranking lever.

What you are aiming at

Three metrics, each with a threshold, and the page has to hit it for the 75th percentile of real visits. That last part matters more than the numbers: you are not optimising a page, you are optimising the experience of three quarters of the people loading it, which is why a fast test on your own laptop proves nothing.

INP replaced FID in 2024, and it was a genuine tightening rather than a rename. FID only measured the delay before the browser began handling your first interaction, which most sites passed comfortably. INP measures the full round trip to a visible response, across every interaction on the page, and reports near the worst of them. Sites that sailed through FID routinely fail INP.

LCP: break it into four parts before touching anything

This is the metric people waste the most effort on, because they treat it as one number. It is four consecutive phases, and the fix is completely different depending on which phase is eating the time.

Time to first byte. The server thinking. If this is most of your LCP, no image work will help. On WordPress this is usually missing page caching, an overloaded database, or a host you have outgrown.

Resource load delay. The gap between the HTML arriving and the browser starting to fetch the LCP element. This is the phase almost nobody looks at and it is often the biggest. It happens when the image is discovered late, because it is set in CSS, injected by JavaScript, or sitting inside a carousel that has to initialise first. The fix is to make it discoverable in the initial HTML and preload it.

Resource load duration. Downloading it. This is the one everyone optimises: modern formats, correct dimensions, compression.

Element render delay. The image has arrived and is not on screen yet, usually because a render-blocking stylesheet or a font is still holding things up.

Two specific mistakes worth naming. Lazy-loading the LCP image, which plugins do enthusiastically and which directly delays the thing being measured: it should be eager and preloaded. And treating LCP as an image problem when the element is actually a heading held back by a web font.

INP: the work is on the main thread

INP is made of three parts: the delay before your handler runs, the handler itself, and the time to paint the result. Long tasks are the cause of the first, your own code is the second, and layout complexity is the third.

The practical fixes, in order. Break up long tasks so the browser can respond between them, which usually means yielding rather than making the work faster. Do the visible part of the response first and defer the rest, so a click that opens a menu paints the menu before it fires the analytics event. And audit third-party scripts honestly, because chat widgets, consent banners, heat-mapping and tag managers all execute on the same thread your interactions need.

On WordPress the specific offender is usually a page builder attaching handlers to everything, plus the accumulated script weight described in the four causes of a slow WordPress site.

CLS: three causes, all preventable

Layout shift is the easiest of the three to fix and the most annoying to experience, which is a good ratio. Nearly all of it comes from three things.

Images and embeds without dimensions, so the browser cannot reserve space and everything jumps when they land. Set width and height, or an aspect ratio, on every one.

Content injected above existing content: cookie banners, promo bars, consent dialogs and late-loading ads. Reserve the space or overlay it rather than pushing the page down.

Fonts. A fallback swapping to a webfont with different metrics reflows the text under the reader. Use font-display:swap with a metrics-matched fallback, preload the fonts you use above the fold, and accept that the last few percent of CLS is usually font-related.

The order to work in

Field data first, to confirm there is a problem. Then whichever metric is actually failing rather than all three. Then, within LCP, the phase that is eating the time rather than the phase you know how to fix.

Fix one thing, deploy it, and wait. Field data moves on a 28-day rolling window, so changing five things and checking tomorrow tells you nothing about which one worked. This is the single most common way this work gets done badly.

When to stop

When the field data passes. Not when the lab score is 100, which is a different test measuring a simulation, and not when every audit item is green. The ranking effect is small and it is a tiebreaker, so the return on going from a comfortable pass to a perfect score is close to zero.

If the pages still are not ranking after passing, the constraint was never speed. It is somewhere in the four questions, or it is that nothing links to you yet. Speed work is genuinely worth doing and it will not substitute for either.