Core Web Vitals in Plain English: LCP, INP and CLS

Core Web Vitals get talked about as an SEO checkbox. They’re better understood as three measurements of whether your site feels broken to a real person on a mediocre phone. Fixing them helps rankings a little; it helps conversions a lot more.

That distinction matters for how much you spend. As a ranking factor, page experience is a tie-breaker — it will not lift thin content above good content. As a business input, a page that takes six seconds to become usable loses people before they read a word. Optimise for the second reason and the first comes free.

There are three metrics, and each has a clear threshold.

Metric	Measures	Good	Poor
LCP	Time until the page looks loaded	≤ 2.5s	> 4.0s
INP	Delay when you tap or click	≤ 200ms	> 500ms
CLS	How much the layout jumps	≤ 0.1	> 0.25

LCP — how long until the page looks loaded

Largest Contentful Paint measures when the biggest visible element in the viewport finishes rendering. Usually that’s your hero image or headline.

What actually causes bad LCP, roughly in order of how often I find it:

• A huge hero image. A 3MB, 4000px-wide JPEG scaled down by the browser. Resize it to the size it’s actually displayed at, serve WebP, and compress it. This one fix often moves LCP by a second or more on its own.
• Lazy-loading the hero. Lazy loading is good — except for the image at the top of the page, where it does the exact opposite of what you want. Never lazy-load anything above the fold, and set fetchpriority="high" on the hero image.
• Slow server response. If the server takes 800ms to send the first byte, everything else starts late. Aim for under 200ms on a cached page. Usually the culprit is cheap hosting, a missing page cache, or a plugin querying the database on every load.
• Render-blocking CSS and JavaScript. The browser can’t paint until it’s processed them. Fewer plugins loading stylesheets on every page is the real fix here.
• Web fonts. Text stays invisible while a font downloads. Use font-display: swap, preload the one font you actually need, and self-host it.

A quick way to find your own LCP element: run PageSpeed Insights and look at the LCP entry in the diagnostics — it names the exact element. It is a hero image about eight times out of ten, and people are frequently surprised by which one.

INP — how quickly the page responds when you touch it

Interaction to Next Paint replaced FID in 2024, and it’s a much stricter test. FID only measured the delay before the browser started handling your first interaction. INP measures the full round trip — tap to visible response — across the whole visit, and reports close to the worst one.

That change caught a lot of sites out. Plenty of pages that scored perfectly on FID score poorly on INP, because the problem was never the first click — it was the menu that takes half a second to open on the fourth.

INP problems are almost always JavaScript problems. The main thread is busy running something, so it can’t respond to the tap for 400ms. Common culprits:

• Third-party scripts. Chat widgets, analytics, heat mapping, three ad pixels, a review widget. Each one is someone else’s JavaScript running on your main thread. Audit them honestly — most sites are carrying two or three nobody remembers adding.
• Page builder overhead. Heavy builders ship a lot of JavaScript for interactions you may not be using.
• Long tasks. Any single script running more than 50ms blocks everything. Defer what isn’t needed for the first interaction.

The cheapest win: delay non-essential third-party scripts until after the first user interaction. Most tracking doesn’t need to run in the first two seconds, and several caching plugins can do this for you with a checkbox.

CLS — how much the page jumps around

Cumulative Layout Shift measures unexpected movement of content while the page loads. You know the feeling: you go to tap a button, an ad loads above it, and you tap something else.

Causes are boringly consistent:

• Images without width and height attributes. The browser doesn’t know how much space to reserve, so it reflows when the image arrives. Always set dimensions, or an aspect ratio in CSS.
• Embeds and ads with no reserved space. Same problem — give the container a fixed minimum height.
• Cookie banners and notification bars injected at the top after the page renders, pushing everything down. Overlay them instead, or reserve the space.
• Font swapping between a fallback and your web font, when the two have very different metrics.

CLS is usually the fastest of the three to fix, and it’s the one users feel most directly.

On WordPress specifically

Most WordPress sites fail these for the same handful of reasons, and they’re fixable without a rebuild:

Symptom	Usual cause	Fix
Slow first byte	No page cache; shared hosting	A caching plugin, or server-level caching
Enormous images	Full-size uploads used directly	Resize, convert to WebP, check the size actually served
Dozens of CSS/JS files	Plugins loading on every page	Only load what each page needs
Poor INP	Page builder + widgets	Delay third-party scripts; reduce builder use on key pages
Layout jumps	Sliders, ads, cookie bars	Reserve space; overlay rather than push

The heaviest single win on a builder-based site is usually converting the most important templates to clean, native markup, because it removes the JavaScript rather than deferring it. That’s a bigger job than a plugin setting, but it’s the one that holds — see WordPress speed optimization.

Be wary of stacking three optimisation plugins. They fight, and the usual result is a broken layout plus a slower site. One caching/optimisation plugin, configured properly, beats three configured hopefully.

Field data vs lab data — the part that confuses everyone

Running PageSpeed Insights gives you two sets of numbers. The lab test is a simulation on a fixed device — useful for debugging, not what Google uses. The field data comes from real Chrome users on your site, taken at the 75th percentile over the previous 28 days. That’s the assessment that counts.

Two practical consequences. First, your score can be fine in the lab and poor in the field, because your real visitors are on slower phones and worse connections than your test machine. Second, after you fix something, the field data won’t fully catch up for up to 28 days. Don’t panic on day three and undo your work.

A related trap: the 75th percentile means one in four visits is worse than your reported number. If LCP reads 2.4s you are not comfortably passing — a quarter of your visitors are having a slower experience than that.

Google Search Console’s Core Web Vitals report is the place to look, because it groups URLs by type — so you fix one template and it improves 200 pages at once. If a page gets too little traffic to have field data, Search Console will group it with similar pages rather than report on it directly.

Do it in this order

1. Get field data from Search Console. Find which template is failing and on which metric.
2. Fix the single biggest cause first — usually the hero image or an oversized script bundle.
3. Re-measure in the lab immediately to confirm the change worked.
4. Wait for the field data to catch up before judging the result.
5. Re-test on a real mid-range phone on mobile data, not just on your laptop. It is a genuinely different experience and it recalibrates your judgement fast.

One last thing, since it comes up on every project: a perfect 100 score is not the goal. Going from 6 seconds to 2.4 seconds changes how many people stay. Going from 2.4 to 2.1 changes a number on a dashboard. Spend your budget on the first one, then go and improve something a visitor will actually notice.

If your site is slow because of how it was built rather than how it’s configured, a WordPress redesign that keeps your content and URLs is often cheaper than optimising around the problem indefinitely. And if you’re planning a new build, structuring it well from the start saves this conversation entirely.