Core Web Vitals are three Google metrics that describe what a visitor actually experiences on a page: how fast the main content appears (LCP), how quickly the site responds to a click or tap (INP), and how much the layout jumps around while loading (CLS). The "good" thresholds at the time of writing are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, and they are measured on real visitors, not on a single test run from a developer's laptop. Below we break down what each metric measures, where to find your numbers, why they are so often poor and what to do about it.
Google introduced the Web Vitals set in 2020 to boil the conversation about website loading speed down to a few numbers anyone can read. "Core" means the three that feed into ranking and into Search Console reports.
Largest Contentful Paint measures the time from the start of navigation until the largest element in the visible part of the screen has been painted: a hero banner, a heading, a product photo. It is not "fully loaded"; it is the moment a person sees that the page is actually there. If LCP is 5 seconds, the visitor stares at a blank screen for those five seconds.
Interaction to Next Paint looks at every click, tap and key press during a visit and effectively takes the worst one (with a small allowance for very long sessions). It measures the delay from the action to the next screen update. INP officially replaced First Input Delay on 12 March 2024, so if your old checklists still mention FID, it is time to update them. The difference matters: FID counted only the first interaction, INP watches the whole visit, so a catalogue filter or a cart that freezes now counts too.
Cumulative Layout Shift is not a time but a unitless score: the sum of unexpected element shifts. The classic case: a person aims at a button, a banner loads in above it, the button slides down, the click lands on an ad. Every shift like that adds to CLS.
Google splits each metric into three zones. For a page to "pass", all three metrics must be in the green zone at the 75th percentile, meaning at least three quarters of real page loads have to fit within the threshold.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | up to 2.5 s | 2.5 to 4 s | over 4 s |
| INP | up to 200 ms | 200 to 500 ms | over 500 ms |
| CLS | up to 0.1 | 0.1 to 0.25 | over 0.25 |
Pay attention to that 75th percentile. A site can open in a second from an office on fibre and still fail CWV because a quarter of visitors arrive on ageing Android phones over mobile data. That is why the mobile version is almost always worse than desktop, and it is the one Google looks at first.
This is the most common confusion we at Query run into during consultations. There are two data sources and they show different things.
The practical takeaway: judge yourself by field data and treat the lab report as a list of hints. And do not be surprised when field numbers do not move right after a fix: the window is 28 days, changes trickle in gradually.
PageSpeed Insights (PSI) is Google's free tool: enter a URL and you get two blocks, a Core Web Vitals assessment based on field data (mobile and desktop separately) and a lab audit with recommendations. It is the first thing worth opening. The 0 to 100 performance score everyone loves to screenshot applies only to the lab part and plays no role in ranking. Chasing a perfect 100 is pointless; what you need is green field metrics.
The Core Web Vitals report in Google Search Console shows the picture across the whole site: how many URLs are good, how many need improvement, how many are poor, for mobile and desktop separately. Pages there are grouped by template: if one product page is poor, the rest are too, so fixing the template clears hundreds of URLs at once. It is the easiest way to set priorities: find the largest group and the metric that fails in it.
For ongoing monitoring there is also the CrUX Dashboard in Looker Studio and the Web Vitals extension for Chrome, which shows the metrics right while you browse a page. Developers usually prefer Lighthouse in DevTools, alongside the Performance tab for tracking down a specific heavy script.
The causes repeat from site to site. In our experience it is rarely one big problem; more often it is five or six medium ones that together push a page into the red.
| Metric | "Good" threshold | Typical cause | What to do |
|---|---|---|---|
| LCP | up to 2.5 s | Heavy hero image, slow server (TTFB over 800 ms), render-blocking CSS and JS | Compress images and convert to WebP/AVIF, add fetchpriority="high" to the hero image, enable caching and a CDN, move non-critical CSS/JS out of <head> |
| INP | up to 200 ms | Third-party scripts (chats, pixels, widgets), heavy framework JS, long click handlers | Remove unused scripts, load the rest deferred (defer, async), break long tasks into chunks, check server response times for AJAX calls |
| CLS | up to 0.1 | Images and videos without dimensions, banners and ads injected at the top, web fonts loading with a text "jump" | Set width/height on all media, reserve space for banners, serve fonts with font-display: swap and preload |
A few notes on the items that most often turn out to be "the" cause.
Images. A homepage slider with five photos at 2 MB each is a standard find on sites built a few years ago. The first photo is the LCP element and should not weigh more than 150-200 KB. The other slides can load later.
Fonts. Three families with four weights each pulled from Google Fonts add both an LCP delay and a CLS jump when the system font is swapped for the custom one. Keep two weights and serve them from your own server as WOFF2.
Third-party scripts. A live chat, a few ad pixels, a map, a reviews widget: each brings its own JS, and these are what usually ruin INP. Count which ones are actually used. Switch off the ones nobody needs; load the ones you do need after the first interaction or through Tag Manager with a delay.
Hosting and TTFB. Time to First Byte, the time until the server sends the first byte of its response, is the floor for LCP: if the server thinks for 1.5 seconds, an LCP under 2.5 is physically impossible. Cheap shared hosting, no page cache, heavy database queries: all of it shows up in PSI as "Reduce initial server response time". Sometimes the cheapest fix is simply turning on server-side caching and moving to a decent hosting plan.
Part of this is covered by standard technical SEO optimisation, while deeper work such as rewriting templates or replacing a slider falls under website refinement by a developer. At Query we usually run the two together: the audit shows what is slow, the developer fixes it, and field data confirms the result.
The honest answer: they do, but not the way some people scare you with. Google confirms that Core Web Vitals are part of the page experience signals, yet this is one factor among many, and content relevance weighs far more. A site with poor metrics but a better answer to the query will, as a rule, outrank a fast site with a thin page. It works more like a tiebreaker: when competitors are close on content, the green zone gives you the edge.
The effect on conversion, on the other hand, is direct and visible without any Google involved. A slow page loses part of its visitors before the first screen renders, layout jumps cause misclicks, and a "Buy" button that hangs for half a second feels like a broken site. That is why we suggest treating CWV not as an SEO checkbox but as a measure of how much money leaks out through website loading speed. The full description of the metrics and the measurement method is in Google's official documentation at web.dev/vitals.
.jpg "Website Indexing in Simple Words: How It Works and How to Check It")
.jpg "Online Store Ideas: Promising Niches and How to Pick Yours")
.jpg "E-commerce: What It Is and How Online Commerce Works")
.jpg "Permanent Links and Behavioral Factors: How to Combine Them in SEO")
