WordPress Core Web Vitals: measure and fix LCP, INP and CLS

There’s a popular idea, especially among people who sell maintenance at €30 a month, that WordPress Core Web Vitals get fixed by installing a caching plugin, ticking four boxes and waiting for PageSpeed to turn green. It takes ten minutes, nobody has to touch the theme and the report you send the client afterwards looks absolutely gorgeous.

Monumental mistake.

The three metrics measure completely different things, and only one of them gets any better with caching.

Below is the order of play, covering what each one measures, how to diagnose it on your WordPress site and what to fix first. Before anyone operates you need triage, and most websites end up in theatre being treated for the wrong wound.

What each metric measures and where the threshold sits

Google assesses the 75th percentile of page loads from your real users over a rolling 28-day window.

Not the last test you ran on your laptop over fibre.

• LCP (Largest Contentful Paint) measures how long the largest visible element takes to render, which is almost always your header image, and it counts as good at 2.5 seconds or less.
• INP (Interaction to Next Paint) measures how long the page takes to respond visually when the user taps, clicks or types, and it counts as good at 200 milliseconds or less.
• CLS (Cumulative Layout Shift) measures how much the content jumps around while the page is loading, and it counts as good at a score of 0.1 or less.

That 75th percentile matters more than it looks, because it means three out of every four visits have to come in under the threshold.

Your average can be excellent and the whole set can still fail because of the worst quarter of your visitors, the ones on 4G with three-year-old phones in an area with patchy coverage.

Optimising for your own machine is optimising for the wrong percentile.

There’s a fourth figure that isn’t a Core Web Vital but holds all three back, and that’s TTFB, or Time to First Byte, the time your server takes to send back the very first byte. Above 800 milliseconds, no amount of front-end optimisation is going to save you.

The most common diagnostic mistake

Lab data and field data don’t tell you the same story.

Mixing them up is exactly what keeps a ‘green’ site failing month after month while everyone stares at the wrong report.

When you open PageSpeed Insights you see two blocks. At the top, if your site gets enough traffic, sits the data from real users over the last 28 days, and that’s what Google actually uses to assess you.

Below it is the Lighthouse simulation, which is there to find causes and never to declare the problem solved. INP can’t be measured there either, because it needs a real person touching the screen.

Your source for deciding is the ‘Core Web Vitals’ report in Search Console. Your source for investigating is Lighthouse together with the Performance panel in your browser’s developer tools.

If your site gets little traffic, the field block will be empty, and that isn’t a fault because there just isn’t a big enough sample yet.

In that case work with lab data, but always test in mobile mode with the CPU throttled. Desktop will give you lovely numbers that none of your customers will ever see on their own screens.

Before going any further, answer three questions honestly. Do you know which element sets your LCP? How many plugins load JavaScript on every single page, including the ones that never use it? Have you opened your site on a mid-range phone on mobile data, rather than on your own phone over fibre?

How to improve WordPress Core Web Vitals: four tests, worst bleed first

You operate by severity, not by convenience, and this is the order I follow on every site that lands on my table.

The server test

Measure TTFB before you touch a single image. In PageSpeed it shows up in the Lighthouse audit called ‘Reduce initial server response time’.

Above 800 ms your problem sits underneath WordPress itself, in overloaded shared hosting, an outdated PHP version, a missing page cache or a database stuffed with thousands of revisions and transients.

A caching plugin usually sorts this one out, and it’s the only one of the four tests where that plugin is genuinely the right answer.

If your TTFB stays high with caching switched on, the hosting is the explanation.

You can check that with a cheap experiment: ask another provider for a trial account, clone the site and measure exactly the same thing. If the difference runs to hundreds of milliseconds, you know where the bottleneck was and how much it costs to fix.

The big element test

Lighthouse tells you which element on the page is your LCP element.

Open it up and check three things before you start fiddling with anything else.

• Format and weight. A 900 KB JPG header weighs between 30% and 50% less as WebP or AVIF, which makes it the cheapest improvement you’ll ever make.
• Lazy load in the wrong place. If your header image carries loading="lazy", you’re delaying it on purpose, and the first visible image should never be deferred.
• Dependency chain. If the LCP element is text and it arrives late, the culprit is usually a render-blocking web font or a 400 KB stylesheet from your page builder.

On WordPress the usual suspect is the slider on your home page, with its three full-screen images, a JavaScript library and some animated text on top. It wrecks LCP and almost never adds anything you can actually measure.

The fix follows a clear order. First, remove whatever shouldn’t be there at all. Then serve the rest in the right format and at the size it’s actually displayed, which is almost never the size it was uploaded at.

Only at the very end should you preload the header image, because preloading a 900 KB image that shouldn’t exist in the first place is just speeding up the mistake.

The response test

INP is the metric that has caught out the most sites since it replaced FID as a Core Web Vital in March 2024.

On WordPress the reason is almost always the same, and it’s too much JavaScript running on the main thread at the wrong moment.

Open the Performance panel, record while you tap your menu and look for long tasks, which are the ones over 50 ms. You’ll see some very familiar names in there, such as the support chat, the consent manager, the autocomplete search and your page builder loading its animation engine.

Now type document.querySelectorAll('*').length into the console. A DOM of 3,000 nodes where 800 would do punishes your INP on any mid-range phone.

No cache fixes that, because the work isn’t in the downloading, it’s in the executing.

What does fix it is loading each script only on the pages where it’s needed. Your contact form doesn’t need its JavaScript on product pages, and the autocomplete search has no business loading on the legal notice.

On an average install, that one decision removes between a third and half of the JavaScript on inner pages, and it doesn’t force you to give up a single feature.

The jump test

CLS is easier to see than to measure. Load your home page on a real phone, on mobile data with the Wi-Fi off, and watch whether anything moves while the page appears.

Four causes cover nearly every case I come across in WordPress sites:

• Images that go out without width and height declared in the markup.
• Cookie banners injected after the first paint that push the rest of the page down.
• Web fonts that change the line height when they finally replace the fallback font.
• Blocks that a plugin drops in on top of content that’s already visible.

Every one of them is fixed by reserving the space before the element arrives, and none of them is fixed by caching.

It’s the cheapest metric to fix and the most irritating one when it fails, because it causes the wrong click right at the moment someone is making a decision.

A button that shifts half a second after it appears sends your customer to a page they never wanted. That’s no longer a lab figure, it’s one sale fewer.

I’ve done it on my own website (with numbers)

Preaching is free. This is what came out when I applied the protocol to this very website in November 2026.

These are lab figures, Lighthouse on mobile with a throttled CPU, and they’re for finding causes. The verdict arrives in the field report, 28 days later.

A CLS of 0.8 you couldn’t see on desktop

The home page moved on its own while you scrolled. On a big screen it looked like an effect. On a phone it was a CLS of 0.8, eight times the limit.

Today it’s at 0. The cause was in the website’s own code, not in a plugin, which is why no plugin was ever going to fix it.

When PageSpeed swears you take 4.2 seconds

The home page paints the headline as soon as the HTML arrives. Even so, Lighthouse kept insisting on an LCP of 4.2 s.

It isn’t lying, it’s simulating: it works out the load from downloads that tread on each other, and in that sum any resource that starts before your LCP adds time, even when the text is already painted on a real phone.

I tried inlining the logo in the HTML to save one download. Three measurements out of three: 4.2 s. Not a millisecond less. When the lab doesn’t match what you see on a real phone, field data wins.

Entrance animations count too

Elementor hides every block with an entrance animation until its JavaScript wakes up. If that block sits on the first screen, your LCP waits for the script.

I removed the animation only from the first block of each inner page and left the rest alone. Services and contact went from a score of 80-84 to 95 and 100.

A start-up split into pieces beats ten plugins

On load, the page builder’s scripts and mine ran in one go, and until they finished the browser couldn’t attend to anything else.

Splitting that start-up into separate tasks, without removing a single feature, brought the portfolio’s blocking time on desktop down to 10 ms.

The pretty background that sank mobile

The dotted background you see on 41 of the 53 pages was redrawn in full on every frame. On a low-end phone it left scrolling at 4-8 frames per second.

Now the grid is CSS, only what fits on screen gets animated and it stops when you scroll past it. Same look, a fraction of the work.

What the cache hides from you

With a warm cache, the home page comes out green. Without it, the same page took 6.8 s on the server: 5.9 s just to assemble the page builder’s content, with 549 database queries and the hosting’s PHP cache full to the brim.

Your regular visitor doesn’t notice. The first one to arrive after every change does. That’s why I always measure without the cache before calling anything done.

The overall picture? Today, in the mobile lab: 93 for the home page, 98 for services, 98 for contact, 93 for the portfolio and a CLS of 0 on every one of them. It isn’t a screenshot to show off. It’s the starting point for the next 28 days of real data.

What doesn’t fix them (and how often to check)

No magic buttons.

An all-in-one optimisation plugin does three useful things (page caching, minification and script deferral) and one dangerous thing, which is letting you believe the problem is solved because the traffic light changed colour in a lab test. There are still 70 requests on the page. There’s still a page builder loading its full engine on every single URL. And your user is still sitting there waiting.

Real optimisation isn’t about ticking boxes but about removing work your page has no need to do in the first place. That work is the Core Web Vitals optimisation I carry out as part of technical SEO.

There’s also a side effect that almost nobody selling these plugins ever mentions.

Deferring scripts blindly breaks things, and it breaks them quietly: the form that stops sending, the catalogue filter that stops responding, the video that refuses to start.

If you switch those options on, test the whole purchase or contact journey on a real phone afterwards, and not just the home page.

Frequency works in a similar way, so check your field report once a month and save lab tests for after each big change.

Field data takes up to 28 days to reflect an improvement. If you fix your LCP today and you’re still in the red on Monday, the fix hasn’t failed, the window simply hasn’t caught up yet.

That’s why you measure before touching anything, and why you save the screenshot with the date on it.

This is part of looking after the site once it’s live, not a one-off job. An optimised site that picks up four new plugins in six months ends up right back where it started. That’s why your WordPress maintenance should include checking the field report, not just clicking update on plugins.

Where this fits with the rest of your site

The three metrics don’t tell you whether your website sells. What they tell you is whether your website lets your content compete in the first place. The business impact, with conversion rates and cost per click, comes down to what load time does to your sales.

There’s one part no metric captures, and that’s the real friction someone goes through while trying to buy from you. You spot that by watching sessions rather than charts, and it’s where UX work on the friction your users hit comes in. If you need the full map of your site, with technical SEO and content in the same report, that’s a website audit.

And there’s a ceiling you simply can’t break through from the admin dashboard.

When performance is capped by the theme or the page builder, none of the four tests will get you out of the red, because the problem is what your site is made of and not how it’s configured.

At that point the decision stops being technical and becomes a question of budget, and you’ll find it laid out in what it costs to rebuild it properly and in what gets cut when the price drops.

When performance goes in from day one, this article is redundant. That’s why I start every project with the structure and not with the design of the home page.

I don’t hand over green screenshots. I hand over your field report before and after, with the date of every measurement, and I tell you which part of the improvement is structural and which part is cosmetic. When the ceiling is set by your theme or page builder, I say that too, even if it means the job is bigger than you expected.

On the Framely media portfolio I kept the load time at 1.1 s with video and animation on the page. It can be done, as long as you measure from the very start. And if the problem isn’t only about performance, what you need is an SEO audit.