Think of Core Web Vitals as the MOT for your website. Three measurements, each one telling you something specific about whether your site is safe and pleasant for the people using it. Pass them and Google trusts you. Fail them and your site struggles to compete, no matter how good the content is.
The problem with most Core Web Vitals explanations is that they assume you already speak developer. This one does not. We will walk through what each measurement actually is, why Google cares, what the targets are, and what tends to go wrong.
What Core Web Vitals are, in one paragraph
Core Web Vitals are three numbers Google measures on every page of your site to score the real-world experience visitors are getting. The numbers come from anonymised data from actual Chrome users, not lab tests. If your scores are consistently bad, Google quietly hands ranking advantage to faster competitors. AI engines do something similar: pages with poor performance scores get cited less often.
| Core Web Vital | What it measures | Target | Fix in plain English |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content loads | Under 2.5 seconds | Compress hero image, avoid render-blocking scripts |
| INP (Interaction to Next Paint) | How fast the page responds to clicks and taps | Under 200 milliseconds | Cut heavy JavaScript, defer non-critical scripts |
| CLS (Cumulative Layout Shift) | How much the page jumps as it loads | Under 0.1 | Set width and height on images, reserve ad slots |
The three measurements
1. Largest Contentful Paint (LCP)
How long it takes for the main bit of content on the page to show up. Usually the hero image, a big headline, or a video preview. The clock starts when the user clicks the link and stops when the largest visible element has finished loading.
Think of it as how long it takes for a restaurant to bring your main course out. Two seconds is great. Four seconds and you are starting to wonder if you have been forgotten. Six seconds and you walk out.
Target: under 2.5 seconds. Above 4 seconds is a fail.
What usually goes wrong: huge unoptimised images, slow hosting, bloated themes, too many fonts and scripts loading before the main content.
2. Interaction to Next Paint (INP)
The newest of the three, replacing the older First Input Delay measurement in 2024. INP measures how long the page takes to respond when you do something on it: tap a button, open a menu, expand an FAQ. It tracks every interaction, not just the first.
If LCP is the time to your main course, INP is the time it takes the waiter to come over when you wave them down. The good ones are at your table in two seconds. The slow ones take ten and feel rude.
Target: under 200 milliseconds. Above 500 milliseconds is a fail.
What usually goes wrong: heavy third-party scripts (chat widgets, analytics tools, ads), badly-written JavaScript, slow database queries on dynamic sites.
3. Cumulative Layout Shift (CLS)
How much your page jumps around as it loads. You have seen this: you are about to tap a button, the page shifts because a banner has loaded above it, and you tap the wrong thing. CLS measures how often and how much that happens.
This is the restaurant equivalent of the waiter rearranging your cutlery while you are eating. You can still enjoy the meal, but it is annoying and it should not happen.
Target: under 0.1. Above 0.25 is a fail.
What usually goes wrong: images and ads without dimensions set, fonts that swap mid-load and shift text, banners and pop-ups that appear after the page seems settled.
Why Google actually cares
Google’s job is to send people to pages they will be happy with. A slow, jumpy, unresponsive page is the opposite of a happy result, even if the content on it is brilliant. So Google has folded these three measurements into how it decides which pages to rank.
It is not the only factor, and it is not always the deciding factor. A genuinely useful page with bad Core Web Vitals can still rank above a fast page that is shallow. But the gap closes month on month. AI engines lean even harder on these signals: a slow page is much less likely to be cited in an AI Overview.
How to check yours
Two free tools, in this order:
PageSpeed Insights. Visit pagespeed.web.dev, paste your URL, see your Core Web Vitals scores from real Chrome users. Run it on your homepage and at least one service page.
Search Console’s Core Web Vitals report. Inside Google Search Console, under Experience. Shows you which pages are passing, which are failing, and which need attention. Group by URL pattern to spot template-level issues.
Run both. PageSpeed Insights is the diagnostic; Search Console is the dashboard.
What to do if you are failing
Most service-business sites fail one or two of the three. The most common pattern is bad LCP because of huge images and slow hosting, and good CLS and INP. Fixes generally fall into one of four buckets:
Image fixes (impact on LCP). Resize and compress all images. Serve them in WebP or AVIF format. Set width and height attributes on every image. This alone fixes a third of failing sites.
Third-party script fixes (impact on INP). Audit every chat widget, analytics tool and tracking pixel on your site. Each one slows the page. Remove anything you do not actively use. Defer the rest so they load after the main content.
Font fixes (impact on CLS and LCP). Preload fonts. Use font-display: swap or font-display: optional. Limit how many font weights you load.
Hosting fixes (impact on everything). If your site is on cheap shared hosting, this is often the largest single lever. A good UK host with sensible caching transforms a slow site overnight.
Our SEO packages cover all four buckets as part of the technical workstream. If you would rather work through the foundations yourself first, the technical SEO checklist covers the wider context Core Web Vitals sits inside.
The shortcut for non-developers
If you do not have a developer and you are running on WordPress, three changes get you most of the way:
- Install a quality caching plugin (WP Rocket, FlyingPress or LiteSpeed Cache depending on your host) and apply the recommended settings.
- Run all your existing images through an image-optimisation plugin (ShortPixel, Smush, or similar). Set new uploads to compress automatically.
- Remove every plugin you do not use. Every plugin adds load time, often more than you expect.
Together these three changes typically halve LCP and improve INP meaningfully. CLS usually needs developer attention to fix properly.
Frequently asked questions
Do Core Web Vitals affect mobile and desktop the same way?
They are measured separately. Mobile is the stricter version because most UK searches happen on mobile, and mobile hardware is slower. A page can pass desktop and fail mobile easily. Optimise for mobile first.
How long does it take for fixes to show up?
The scores Google uses come from a 28-day rolling window of real user data. So a fix you apply today shows up in your scores roughly four weeks later. Be patient and watch the trend, not the day-to-day.
Are Core Web Vitals more important than content?
No. Content is still the bigger lever. But Core Web Vitals are the threshold underneath: terrible scores cap how much your content can achieve. Get them passing, then focus on content.
What is a “good” overall PageSpeed Insights score?
The headline 0 to 100 score is a lab measurement, useful as a quick diagnostic but not what Google actually ranks on. What ranks on is the real-user field data shown lower down the report. Aim for green on all three Core Web Vitals there.
Does this matter for an AI Overview citation?
It matters, more than people realise. AI engines correlate citation rates with measurable site quality, and Core Web Vitals is the cleanest measure they have. A slow page is much less likely to be cited even when it has good content.
Where to go next
If you want to know which of the three is hurting your site most and what the realistic fix sequence looks like, our audit covers Core Web Vitals as part of the wider technical health check.
Book a discovery call and we will run the scores live on the call.
