If someone has told you your website needs to “pass Core Web Vitals” without explaining what that means or why you should care, this guide is the explanation. No jargon for its own sake, and no pretending the metrics matter more than they do.
What Core Web Vitals actually are
Core Web Vitals are three measurements Google uses to judge how your website feels to a real person using it. Not how it looks, and not what it says. How it feels: how fast something useful appears, how quickly it responds when tapped, and whether things jump around while loading.
There are exactly three, and as of 2026 they are:
- Largest Contentful Paint (LCP) measures loading. Good is under 2.5 seconds.
- Interaction to Next Paint (INP) measures responsiveness. Good is under 200 milliseconds.
- Cumulative Layout Shift (CLS) measures visual stability. Good is under 0.1.
If you are reading an older guide that mentions First Input Delay, it is out of date. INP replaced FID in March 2024, and INP is considerably harder to pass because it measures every interaction in a session rather than only the first one.
The detail most articles skip
These are graded on real visitors, not on a test you run yourself. Google uses the Chrome User Experience Report, which collects data from actual Chrome users, and evaluates it at the 75th percentile across a rolling 28-day window.
Two consequences follow, and both matter:
First, a perfect score in a testing tool on your own laptop means very little. You are one visitor on good hardware and a good connection. The grade comes from everyone, including people on mid-range Android phones and patchy mobile data.
Second, fixes take weeks to show up. Because the window is 28 days and rolling, deploying an improvement today will not move the number tomorrow. Expect to wait several weeks before judging whether a change worked. A great many people conclude their fix failed when they simply measured too early.
What each metric means in plain terms
LCP: how long until something useful appears
LCP measures when the largest visible element finishes rendering. Usually that is a hero image, a headline, or a video thumbnail. It is a proxy for the question a visitor is actually asking: has this page loaded yet?
Under 2.5 seconds is good. Over 4 seconds is poor. Anything between is the needs-improvement band.
The usual causes of bad LCP are a slow server response, oversized images, and render-blocking resources that must download before anything can paint. On WordPress sites specifically, an uncompressed hero image is the single most common culprit we see.
INP: how quickly the page answers you
INP measures the delay between a visitor interacting with something and the screen visibly updating. Tapping a menu, opening an accordion, submitting a form.
Under 200 milliseconds is good. Over 500 milliseconds is poor.
INP is the metric most sites fail, and it is almost always a JavaScript problem. When the browser’s main thread is busy running scripts, it cannot respond to the tap. The visitor taps again, assumes the site is broken, and often leaves. Heavy page builders, tracking scripts, chat widgets and unused plugins all contribute.
CLS: whether the page holds still
CLS measures unexpected movement. You go to tap a button, an image finishes loading above it, the content jumps, and you tap an ad instead. Everyone has done this and everyone hates it.
Under 0.1 is good. Over 0.25 is poor.
CLS is usually the easiest to fix, because the causes are mechanical: images and iframes without width and height attributes, web fonts swapping in at a different size, and content injected above existing content after load.
How much do they actually matter for rankings?
Here is where we will be more honest than most agencies.
Core Web Vitals are a genuine ranking signal, but a modest one. They are a tiebreaker, not a trump card. A fast page with thin, unhelpful content will not outrank a slower page that answers the question properly. If someone tells you fixing your Core Web Vitals will transform your rankings, be sceptical.
The stronger argument for fixing them is commercial rather than algorithmic. Slow, unstable pages lose visitors before they read anything, and that costs you enquiries regardless of where you rank. Treat Core Web Vitals as conversion work that happens to also help SEO, and you will prioritise it correctly.
How to check your own site
- Google Search Console has a Core Web Vitals report using your real visitor data. This is the authoritative source, because it is the same data Google grades you on.
- PageSpeed Insights shows both field data (real users, top of the report) and lab data (a simulated test, below). Read the field data first. The lab score is diagnostic, not your grade.
- Chrome DevTools Performance panel helps identify which specific scripts are blocking the main thread when you are chasing an INP problem.
If Search Console says you have insufficient data, your site does not get enough traffic for Google to build a reliable sample. In that case use lab data as a rough guide and focus on the obvious mechanical fixes below.
A sensible order to fix things
Do not try to optimise everything at once. Work in this order:
- Fix anything in the poor band first. Moving a metric from poor to needs-improvement helps more than moving another from good to excellent.
- Then CLS, because it is usually cheap. Add explicit width and height to every image, video and iframe. Reserve space for anything that loads late.
- Then LCP. Compress and correctly size your hero image, serve modern formats such as WebP, preload the LCP image, and check your server response time.
- Then INP, which is the hardest and usually means removing or deferring JavaScript. Audit your plugins honestly. Most sites are carrying scripts nobody uses.
Do not optimise a metric that is already green. It wins you nothing.
The uncomfortable truth about page builders
If your site is built with a heavy page builder and dozens of add-on plugins, you will fight INP continuously. Every widget adds JavaScript, and the builder loads infrastructure whether a given page needs it or not.
This does not mean page builders are wrong. They give you editorial control, which has real value. But it does mean the honest fix is sometimes structural rather than a plugin you install. Be wary of any tool promising to fix Core Web Vitals automatically; caching and minification help genuinely, but they cannot remove work the page was never required to do.
What to take away
Core Web Vitals are three real-user measurements: loading under 2.5 seconds, response under 200 milliseconds, stability under 0.1. They are graded on your actual visitors over 28 days, so fixes take weeks to appear. They influence rankings modestly and conversions substantially, which is the better reason to care.
Start with whatever is worst, fix the mechanical CLS causes first because they are cheap, and be realistic that INP problems usually mean shipping less JavaScript rather than adding another optimisation plugin.
If you would rather not work through this yourself, performance is built into how we approach modern website development, and it is part of every website maintenance plan we run. You can also tell us about your site and we will take a look.
