Core Web Vitals are three Google metrics that measure how fast and how stable a page feels to a real person: LCP marks when the largest visible element is painted, INP measures how long the browser thinks after a click, and CLS tracks whether content jumps around while the page loads. Google calls the result good when 75% of real visits stay under 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS.
One confusion worth clearing up: Core Web Vitals are not a site score out of 100. The PageSpeed score comes from a robot on an emulated device; Core Web Vitals come from the Chrome browsers of your actual visitors. A green 95 and red Core Web Vitals in Search Console coexist happily on the same site.
In plain English
Think of a website as a coffee shop. LCP is how long the coffee takes to arrive: until then you stand at the counter, unsure anyone noticed you. INP is how fast the barista answers: you tap “Book a call”, and either the form opens or nothing happens and you tap again. CLS is whether the table moves while you sit down: you aim at a button, a banner loads above it, your finger lands elsewhere.
None of this is about elegant code — it measures ordinary irritation. Someone who taps a dead button twice rarely finishes the enquiry form.
The three metrics: what they measure and what breaks them
The full set as of 2026, with Google's thresholds and the causes we see most often on audits.
| Metric | What it measures | Good value | What usually breaks it |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the largest visible element is painted — hero image, big heading, main banner | under 2.5s | A heavy unprocessed image above the fold, slow hosting, render-blocking fonts and scripts |
| INP (Interaction to Next Paint) | How long the browser takes to answer a click or tap — the worst interaction of the visit counts | under 200ms | A dozen third-party scripts, heavy chat and booking widgets, JavaScript that starts calculating on click |
| CLS (Cumulative Layout Shift) | How much the content jumps while the page loads | under 0.1 | Images without declared dimensions, banners and cookie bars injected at the top, fonts swapped after load |
Why FID is not on the list
Until March 2024 the third metric was FID, First Input Delay. It only measured the delay before the browser began handling the first interaction, so nearly every site passed it even when the interface froze after the click. INP measures the whole round trip: from tap to painted response. A guide that still lists FID is two years out of date.
Lab data versus field data
PageSpeed Insights shows two blocks and they get mixed up constantly. The top one is field data from CrUX: real Chrome visits over the last 28 days. The bottom one is a Lighthouse lab run on an emulated mid-range phone with a throttled connection.
The numbers rarely match, and that is expected:
- Lab is one run on one device. Field is thousands of visits, including old phones on poor connections.
- The lab never clicks anything. INP is not truly measured there — only a potential delay is estimated.
- Field data accumulates over 28 days. You fixed LCP yesterday; Search Console will show it weeks from now.
- With little traffic there is no field data at all, and Google reports a group of similar pages instead.
The rule: lab data to find the cause, field data to judge the result.
Do Core Web Vitals affect rankings?
Honestly: yes, but weakly. They sit inside the page experience signals and work like a tiebreaker — when two pages answer the query equally well, the faster one wins. Green metrics alone will not beat a stronger competitor; relevance and authority weigh more.
Revenue is where they hit directly: bounces before anyone reads the offer, missed taps on a shifting layout, double submissions after a laggy click. More detail for healthcare projects: medical website speed.
How to check your own numbers
- Google Search Console → Experience → Core Web Vitals. Field data for the whole site, split by mobile and desktop, grouped by page type. New to the panel? Start with Google Search Console for business owners.
- PageSpeed Insights. One URL: field data on top, the lab run and concrete causes underneath.
- Chrome DevTools: Performance tab and Lighthouse panel. Where you find the cause — which element is the LCP, which script eats the response time.
- The Web Vitals Chrome extension. Shows all three metrics as you browse — handy for checking competitors.
Common mistakes
- Chasing a score of 100. A perfect PageSpeed score adds nothing to rankings. The green band is a threshold, not a competition.
- Optimising lab instead of field. The score goes up, real users notice nothing, because their bottleneck was elsewhere — usually third-party scripts the robot barely loads.
- Looking at a single page. Metrics are grouped across similar URLs. A perfect homepage does not help if every service page fails.
- Ignoring mobile. Most traffic is mobile, and mobile is exactly where LCP and INP tend to fail.
- Leaving speed until the end. Light images, sensible fonts and few third-party scripts cost nothing during build and a fortune to retrofit.
How we handle it
Speed is not an upsell here: Lighthouse Performance 90+ is part of every package, from a landing page to a custom platform — written into the terms, not the sales pitch.
The clearest example is the Efedra clinic site: an LCP of 0.8 seconds on mobile, three times better than Google's threshold. Nothing clever behind it — modern image formats, static pages, non-blocking fonts, no stray scripts above the fold.
If your live site is already in the red, we start with a technical audit inside SEO support — work out what actually holds LCP and INP before changing anything. European build quality at sensible rates.
