Contents
- 01
Work out which metric is failing
- 02
Fix the one that is actually failingWhat to do about it
- 03
Avoid the traps
The short answer
Three metrics make up Core Web Vitals, and each has its own threshold:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
|
Largest Contentful Paint (LCP)
|
2.5s or less | 2.5 to 4.0s | more than 4.0s |
|
Interaction to Next Paint (INP)
|
200ms or less | Not stated here | Not stated here |
|
Cumulative Layout Shift (CLS)
|
0.1 or less | 0.1 to 0.25 | more than 0.25 |
How long the biggest visible element takes to render.
How long the browser takes to respond, start to finish, to anything a visitor clicks, taps or types into.
Whether content jumps around while the page is still loading.
Time to First Byte, First Contentful Paint and Total Blocking Time show up in the same reports and get talked about in the same breath, but none of the three is a Core Web Vital. They are diagnostic metrics that help explain why LCP, INP or CLS is failing. Treat them as supporting evidence, not as a fourth or fifth vital to chase.
How it actually works
- Slow hosting / TTFB
- Unoptimized hero image
- Lazy-loaded LCP element
- Cumulative plugin JavaScript
- Page builders and sliders
- Chat widgets and ad tags
- Missing image dimensions
- Web font swaps
- Late-injected ads or cookie banners
Largest Contentful Paint
The LCP element is whichever single thing on the page is biggest by rendered area: usually a hero image, a video poster frame, a CSS background image or a large block of text. Google’s own measurement includes any redirect delay, connection time and server response time before that element can even start rendering, which is why a slow WordPress LCP is usually a hosting and Time to First Byte problem before it is an image-weight problem. Fix the server response first, or the image work does very little.
A common WordPress misconfiguration works against the reader here directly: lazy-loading the LCP element itself. Lazy-loading defers an image until it is about to enter the viewport, and a hero image is in the viewport from the first paint, so telling it to lazy-load delays the exact element the metric is timing. Preload it instead.
See the usual reasons a WordPress site loads slowly for the fuller list of causes behind a slow server response.
Confirm which element PageSpeed Insights or Search Console names as the LCP element for the page, then check whether it is set to lazy-load. If it is, that alone can explain a poor score with no other cause present.
Interaction to Next Paint
Interaction to Next Paint replaced First Input Delay on 12 March 2024. The two measure different things.
First Input Delay
Only timed the delay before the browser started processing the very first interaction.
Interaction to Next Paint
Times the full latency, start to finish, of the browser’s response to every interaction on the page, and reports the worst one observed.
On WordPress, that number is driven almost entirely by the cumulative JavaScript weight of the plugin stack: page builders, sliders, chat widgets, analytics tags and ad scripts all queue work on the same main thread a click has to wait behind.
Check whether a site that passed comfortably under First Input Delay now fails under Interaction to Next Paint with no code change at all. That gap is the clearest sign the two metrics measure different things, not that the site got slower.
Cumulative Layout Shift
The scoring formula is impact times distance: how much of the visible screen moved, multiplied by how far it moved. Two small, unrelated shifts add up the same way one big one does.
On WordPress, the usual causes are missing width and height on images, a web font swap that resizes text after the page has already rendered, and ads, cookie banners or other content injected late into the page.
Reload the page and watch the first two seconds for anything visibly jumping, a button moving as an ad loads in above it, or text reflowing as a font swaps in.
Why it matters for a WordPress site
Google Search Central’s own wording on this is worth quoting directly rather than summarizing:
“Google Search always seeks to show the most relevant content, even if the page experience is sub-par… Having a great page experience can contribute to success in Search, in such cases.”
“Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results.”
Read plainly, that makes Core Web Vitals a contributing signal among many, not a dominant one. Relevant content that scores poorly on Core Web Vitals can still outrank thin content that scores well.
What good looks like
The same three thresholds, restated as the number that gets checked: LCP at 2.5 seconds or less, CLS at 0.1 or less, and INP at 200 milliseconds or less. Google scores each one at the 75th percentile of real visits, segmented separately for mobile and desktop, so a site can pass on desktop and fail on mobile with nothing else different.
Two different reports can disagree, and it helps to know why before trusting either one on its own.
The data Search Console’s Core Web Vitals report is built on. Reflects real visits from real devices and connections over a rolling window.
One simulated visit, on one simulated connection, at one moment.
A site can score well in that single lab run and still fail in the field report, because the field data carries the slow connections and low-end phones the lab test never simulates.
Server response time also depends on infrastructure the reader is already paying for.
What to do about it
A core web vitals fix starts with the diagnosis above, not with a plugin. Each metric has its own fix, and none of the three overlaps much with the others.
For LCP
Check Time to First Byte first. Managed WordPress hosting and an edge cache (a Cloudflare-style integration in front of the site) address server response time directly. Once that is solid, move to the hero image itself: serve it in a modern format such as WebP, and preload it rather than lazy-loading it.
For INP
Audit the plugin stack for scripts running on every page load that only need to run on one or two. A slider script loading on a page with no slider, or a chat widget loading before anyone has scrolled near it, are common candidates.
For CLS
Set an explicit width and height on every image and embed, and reserve space in the layout for anything that loads in late, ads and cookie banners included.
See the full speed checklist, one item at a time for the complete list beyond these three, and have someone check which metric is actually failing before spending time on a fix that targets the wrong one.
See how this is held on the retainer.
NoDrama’s speed optimization work checks Core Web Vitals against the site on an ongoing basis, not as a one-time fix.
Common misconceptions
“A caching plugin fixes Core Web Vitals.”
It improves Time to First Byte and repeat-visit LCP. It does nothing for INP, which is client-side JavaScript running after the page has already loaded, and nothing for CLS, which is a markup and layout problem.
“The padlock and a CDN mean performance is handled.”
A CDN helps LCP through Time to First Byte and faster asset delivery. It has no effect on the JavaScript execution behind INP or the missing dimensions behind CLS.
“Core Web Vitals is a major ranking factor.”
Google’s own wording, quoted above, treats it as a contributing signal that can help when content is otherwise comparably relevant, not a dominant one that overrides relevance.
What this does not solve
Core Web Vitals measure loading, interactivity and visual stability. They say nothing about uptime, security or content quality, and a site can pass all three metrics while having an outdated plugin or no backup in place.
Conclusion
Core Web Vitals are three separate metrics with three separate causes: LCP traces to hosting and image handling, INP traces to plugin JavaScript, CLS traces to unreserved layout space. Check Search Console to see which one is actually failing before changing anything, because a fix aimed at the wrong metric leaves the score exactly where it started.