Core Web Vitals are the three numbers Google uses to judge whether your website actually feels fast to a real visitor, rather than just loading quickly on paper. LCP, INP and CLS sound like acronyms designed to intimidate, but each one measures something you've almost certainly experienced yourself as a frustrated visitor on someone else's site. Here's what each one really measures, what counts as a pass, and the specific things that break them on small business websites.
What Core Web Vitals actually are
Core Web Vitals are three metrics Google introduced to measure real-world page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Each measures a different kind of frustration.
LCP measures loading speed — specifically how long it takes for the biggest visible element on the page (usually a hero image or heading) to actually appear. INP measures responsiveness — how long the page takes to visibly react after someone taps a button, opens a menu or fills in a field. CLS measures visual stability — whether things jump around on screen while the page is loading, which is what causes people to accidentally tap the wrong link.
You can read a general breakdown of how Google scores overall page speed in our guide to PageSpeed Insights, but Core Web Vitals are the specific three numbers that sit underneath that broader score.
LCP measures loading speed — specifically how long it takes for the biggest visible element on the page (usually a hero image or heading) to actually appear. INP measures responsiveness — how long the page takes to visibly react after someone taps a button, opens a menu or fills in a field. CLS measures visual stability — whether things jump around on screen while the page is loading, which is what causes people to accidentally tap the wrong link.
You can read a general breakdown of how Google scores overall page speed in our guide to PageSpeed Insights, but Core Web Vitals are the specific three numbers that sit underneath that broader score.
LCP: Largest Contentful Paint
LCP measures the time from when a page starts loading to when its largest visible piece of content is fully rendered. For most small business homepages, that's a hero image or a big heading above the fold.
Google's threshold for a "good" LCP is under 2.5 seconds. Between 2.5 and 4 seconds is "needs improvement", and anything above 4 seconds is classed as "poor".
On small business sites, LCP almost always breaks for the same handful of reasons:
The fix is usually a combination of a properly compressed, correctly sized hero image, a hosting setup that responds quickly to the first request, and making sure nothing unnecessary loads before the visible content. We go into the image side of this in detail in our guide to image optimisation.
Google's threshold for a "good" LCP is under 2.5 seconds. Between 2.5 and 4 seconds is "needs improvement", and anything above 4 seconds is classed as "poor".
On small business sites, LCP almost always breaks for the same handful of reasons:
- An unoptimised hero image, often several megabytes straight off a phone camera
- Slow hosting or a shared server that takes too long to respond to the first request
- Render-blocking CSS or JavaScript that has to finish loading before the browser can draw anything
- Web fonts that delay text from appearing until they've downloaded
- A hero image that's lazy-loaded, which is one of the most common self-inflicted mistakes we see
The fix is usually a combination of a properly compressed, correctly sized hero image, a hosting setup that responds quickly to the first request, and making sure nothing unnecessary loads before the visible content. We go into the image side of this in detail in our guide to image optimisation.
INP: Interaction to Next Paint
INP replaced an older metric called First Input Delay in 2024, and it's a stricter, more honest measurement. It looks at every interaction a visitor makes on a page — every tap, click and keypress — and reports the slowest one, measuring the time between the interaction and the browser visibly updating in response.
A good INP is under 200 milliseconds. Between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. That might sound like a tiny window, but delays this small are exactly what make a mobile menu feel "sticky" or a form feel unresponsive.
INP problems are almost always caused by too much JavaScript running on the main thread — usually third-party scripts. Chat widgets, tracking pixels, cookie consent tools, carousel plugins and social embeds are the usual suspects. Each one is small in isolation, but stack five or six of them on a WordPress site and the browser spends so long processing scripts in the background that it can't respond to a tap in time.
The fix is to genuinely reduce how much runs on the page, not just defer it. That means auditing every third-party script and asking whether it earns its place, and it's one of the reasons a lean, hand-coded build tends to score dramatically better than a plugin-heavy one straight out of the box.
A good INP is under 200 milliseconds. Between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. That might sound like a tiny window, but delays this small are exactly what make a mobile menu feel "sticky" or a form feel unresponsive.
INP problems are almost always caused by too much JavaScript running on the main thread — usually third-party scripts. Chat widgets, tracking pixels, cookie consent tools, carousel plugins and social embeds are the usual suspects. Each one is small in isolation, but stack five or six of them on a WordPress site and the browser spends so long processing scripts in the background that it can't respond to a tap in time.
The fix is to genuinely reduce how much runs on the page, not just defer it. That means auditing every third-party script and asking whether it earns its place, and it's one of the reasons a lean, hand-coded build tends to score dramatically better than a plugin-heavy one straight out of the box.
CLS: Cumulative Layout Shift
CLS measures how much visible content moves around unexpectedly while a page is loading. You'll recognise this one instantly: you go to tap a link, an ad or image loads in above it at the last second, and you end up tapping something else entirely.
A good CLS score is under 0.1. Between 0.1 and 0.25 needs improvement, and above 0.25 is poor. Unlike LCP and INP, CLS is measured as a unitless score based on how much of the viewport moved and how far, rather than in seconds or milliseconds.
The usual causes are images and embeds without a reserved width and height, web fonts that load in and change the size of text after the page has already rendered, and content — often cookie banners or promotional bars — that gets injected above existing content rather than reserving space for itself in advance.
The fix is almost always to explicitly set width and height attributes (or aspect-ratio in CSS) on every image and embed, so the browser reserves the correct space before the file has even downloaded.
A good CLS score is under 0.1. Between 0.1 and 0.25 needs improvement, and above 0.25 is poor. Unlike LCP and INP, CLS is measured as a unitless score based on how much of the viewport moved and how far, rather than in seconds or milliseconds.
The usual causes are images and embeds without a reserved width and height, web fonts that load in and change the size of text after the page has already rendered, and content — often cookie banners or promotional bars — that gets injected above existing content rather than reserving space for itself in advance.
The fix is almost always to explicitly set width and height attributes (or aspect-ratio in CSS) on every image and embed, so the browser reserves the correct space before the file has even downloaded.
Lab data vs field data
This is where most small business owners get confused, because two different tools can show two different scores for the same page. A tool like Lighthouse or PageSpeed Insights' lab section runs a single simulated test on a fixed, throttled connection — useful for debugging, but it's a snapshot, not the truth Google uses.
Field data, sometimes shown as the Chrome User Experience Report (CrUX), is collected from real visitors using real devices over the previous 28 days. This is what Google actually uses to decide whether your site passes Core Web Vitals as a ranking signal. If your lab score is good but your field data is poor, it usually means real visitors — often on older phones or patchy mobile signal — are having a noticeably worse experience than your test device.
If a page doesn't have enough traffic to generate field data, Google falls back to data from similar pages on the same site, or origin-level data for the whole domain.
Field data, sometimes shown as the Chrome User Experience Report (CrUX), is collected from real visitors using real devices over the previous 28 days. This is what Google actually uses to decide whether your site passes Core Web Vitals as a ranking signal. If your lab score is good but your field data is poor, it usually means real visitors — often on older phones or patchy mobile signal — are having a noticeably worse experience than your test device.
If a page doesn't have enough traffic to generate field data, Google falls back to data from similar pages on the same site, or origin-level data for the whole domain.
How mobile makes all three worse
Every one of these metrics is judged primarily on mobile, because that's where most visits happen and because Google indexes and ranks the mobile version of your site by default. A page that scores well on a fast office broadband connection can fail badly on a 4G connection on a mid-range phone, which is the reality for a large share of local searchers.
We cover the wider implications of this in our guide to mobile-first indexing, but the short version is: test on mobile, fix for mobile, and treat your desktop score as the less important number.
We cover the wider implications of this in our guide to mobile-first indexing, but the short version is: test on mobile, fix for mobile, and treat your desktop score as the less important number.
Does any of this actually affect your business?
Core Web Vitals are a genuine but modest ranking signal — Google has been consistent about that. They're unlikely to outrank a page with far better content and authority, but they can act as a tie-breaker between similar pages, and a poor score is one more small disadvantage stacked on top of others.
The bigger, more measurable effect is on your visitors directly. Slow, jumpy, unresponsive pages lose people before they ever read your offer, and that's true whether or not Google is watching. This is one of the reasons every site we build through our web design service is hand-coded rather than built on a heavy plugin stack, and why our managed hosting includes an edge CDN as standard — both directly affect LCP and INP before a single line of content is even written.
The bigger, more measurable effect is on your visitors directly. Slow, jumpy, unresponsive pages lose people before they ever read your offer, and that's true whether or not Google is watching. This is one of the reasons every site we build through our web design service is hand-coded rather than built on a heavy plugin stack, and why our managed hosting includes an edge CDN as standard — both directly affect LCP and INP before a single line of content is even written.
Common questions
What are good Core Web Vitals scores?
Google's thresholds are an LCP under 2.5 seconds, an INP under 200 milliseconds and a CLS under 0.1. You need to hit all three on at least 75% of real visits to be counted as passing.
Do Core Web Vitals actually affect rankings?
They are a genuine ranking signal, but a modest one. They rarely beat relevance or authority on their own — they act as a tie-breaker between similar pages, and they have a much bigger effect on how many visitors stay long enough to enquire.
Why do my lab scores and field scores disagree?
Lab scores come from a single simulated test on a throttled connection. Field data comes from real Chrome users on real devices and networks over 28 days. Field data is what Google uses, so treat lab tests as a debugging tool rather than the verdict.
Can a WordPress site pass Core Web Vitals?
Yes, but it takes work — a lean theme, few plugins, proper caching and disciplined image handling. The more plugins and third-party scripts a site loads, the harder INP in particular becomes to keep under control.
Want a website that does this automatically?
Every site we build is hand-coded for performance, SEO and security from day one. Free, no-pressure chat — usually within a day.