Core Web Vitals for WordPress: fixing LCP, INP, and CLS

Core Web Vitals are three numbers Google uses to describe how a page feels to a real person: how fast the main content shows up, how quickly the page responds when you tap something, and how much the layout jumps around while it loads. Get all three into the green and you have a page that feels fast, which is also a page Google is happier to rank.

Here is what each one means and how I fix it on WordPress.

LCP: how fast the main thing appears

Largest Contentful Paint measures how long it takes for the biggest visible element to render. On most pages that is the hero image or a big heading. Google’s target is under 2.5 seconds for 75 percent of visits.

When LCP is slow on a WordPress site, the cause is almost always one of these:

Slow server response. If the server takes a second to even start sending HTML, LCP cannot be fast. Page caching and decent hosting fix this.
The hero image is huge or lazy loaded. Serve it as a right-sized WebP and make sure it is not lazy loaded. The most important image should load first, not last.
Render-blocking CSS and fonts. Inline the critical CSS and load fonts so text appears immediately rather than waiting on a download.

Fix the server first, then the hero image. Those two account for most slow LCP scores I see.

INP: how fast the page responds

Interaction to Next Paint measures the delay between a user action, like a tap or a click, and the screen actually updating. Google’s target is under 200 milliseconds. INP became an official Core Web Vital in March 2024, replacing First Input Delay, and it is stricter because it watches every interaction, not just the first.

INP is a JavaScript problem. When the browser’s main thread is busy running scripts, it cannot respond to the user, so the page feels stuck. On WordPress the usual suspects are:

Page builders that ship large JavaScript bundles on every page.
Third-party scripts: chat widgets, heavy analytics, ad tags, A/B testing tools.
Plugins that run work on every interaction instead of only when needed.

The fix is to ship less JavaScript and run it less often. Remove scripts that are not used on a given page. Defer and delay what is not needed for the first paint. Audit your third-party tags honestly, because each one runs on someone else’s code that you do not control.

CLS: how much the page jumps

Cumulative Layout Shift measures unexpected movement while the page loads. You have felt it: you go to tap a button, an ad loads above it, and the button jumps down so you tap the wrong thing. Google’s target is under 0.1.

CLS is the most fixable of the three. The causes are mechanical:

Images without dimensions. Always set width and height so the browser reserves the space before the image loads.
Ads and embeds that load into a space with no reserved height. Give them a fixed container.
Web fonts that swap and reflow the text. Size your fallback font to match so the swap does not shift the layout.
Content injected at the top of the page after load, like a cookie banner or notice bar. Reserve its space or position it so it does not push everything down.

Why this matters beyond the score

Core Web Vitals are a ranking signal, so there is an SEO reason to care. But the better reason is that these three numbers are a decent proxy for whether your site feels good to use. A page that shows up fast, responds instantly, and does not jump around is a page people stay on.

The trap is treating the score as the goal. The score is a measurement of something real. Fix the real thing, the slow server or the oversized image or the script nobody needs, and the score follows.

For the broader playbook on making WordPress fast, start with how to actually speed up a WordPress site.