Definition
What are Core Web Vitals?
Core Web Vitals are the three public measurements Google uses to assess the loading experience of a page: rendering of the largest visible element (LCP), responsiveness to interactions (INP) and visual stability (CLS). Google sets a threshold for each: 2.5 seconds, 200 milliseconds and 0.1. It highly recommends meeting them, without making them a major ranking factor.
The three measurements and their thresholds
Each measurement carries an English acronym, but it describes something simple that the visitor feels.
- LCP (Largest Contentful Paint): 2.5 seconds or less. The time before the largest visible element on the page appears, usually an image or a heading. It is the measurement that best matches the feeling of slowness.
- INP (Interaction to Next Paint): 200 milliseconds or less. The delay between a visitor's action (a click, a filter, an add to cart) and the visible response on screen. Overruns most often come from too many third-party scripts or from a list that is recalculated in full on every click.
- CLS (Cumulative Layout Shift): 0.1 or less. The amount of movement the page undergoes while it loads. A button that moves just as you tap it is the typical symptom. The usual causes are images without declared dimensions and banners inserted after the fact.
Google judges each threshold on real visits, at the 75th percentile: a page passes when at least three page loads out of four meet the threshold, on mobile and desktop separately. INP replaced the older First Input Delay (FID) measurement in March 2024: a report that still mentions FID predates that change.
What Google actually says
Google writes that it highly recommends site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience. It specifies that this recommendation aligns with what its core ranking systems seek to reward. The wording is cautious: speed is not presented as a major ranking lever. Better but slower content still beats weak, fast content.
The effect is mostly real when the measurements are poor. Going from poor to acceptable changes your visitors' experience and can improve your conversion rate. Going from acceptable to excellent pays little: three tenths of a second gained on a page that already passes is almost always better invested elsewhere.
Measuring in the right place
Field data decides, lab data diagnoses. The score out of 100 in PageSpeed Insights comes from a lab test on a simulated device: it helps find a cause. The Core Web Vitals report in Search Console (Google's free tool for site owners) is based on the real experience of your visitors. That is the one that reflects your situation.
The template matters more than the page. Search Console groups similar URLs. Your thousands of product pages often share the same template: fixing the template fixes thousands of pages at once.
The home page is the least revealing. On a catalogue, the losses are in filtered product lists, internal search, product pages with variants, the cart and third-party scripts. Test those paths on a mid-range mobile device, on an ordinary network. The method is covered in our article on the speed of a large catalogue.
Fictional example: a store with 6,000 products gets a good PageSpeed Insights score for its home page. Search Console nevertheless rates its group of category pages "needs improvement" for INP. Every filter recalculates the whole list in the browser while four third-party scripts run.
The team removes two scripts nobody uses anymore, then moves list filtering to the server. The fixed category template drops back under 200 milliseconds for the whole group, without a site redesign.
We read Core Web Vitals as a threshold to clear, not a score to maximize. A performance budget is justified by lost sales, measured on your own site: the conversion rate gap between your fast sessions and your slow sessions can be pulled in one day with your current tools. We treat that gap as an order of magnitude, because slow sessions often come from more modest devices.
We then rank fixes by return (expected revenue divided by effort) rather than by technical severity: removing an unused third-party script often comes before a redesign. A promise of ranking gains through speed rests on a generous reading of Google's documentation. On the sites we build as pre-built sites, speed comes from the construction itself, and every tool added later is measured before it is installed.
Not to be confused with
- PageSpeed Insights score
- The score out of 100 in PageSpeed Insights comes from a lab test on a simulated device. It is for diagnosis. The Core Web Vitals that Google retains are measured on real visits.
- Return per fix
- Core Web Vitals tell you whether a page passes Google's thresholds. Return per fix decides the order in which to fix things, by expected revenue divided by effort.
- Technical SEO
- Technical SEO covers everything that makes a site crawlable and indexable: crawler access, errors, redirects, canonical tags. Core Web Vitals are only one part of it. Getting the pages that sell indexed comes first.
Related concepts
- Return per fix
- Pre-built site
- Technical SEO
- Conversion rate
- ECommerce SEO
- Faceted navigation
- Mobile-first indexing
Further reading
- eCommerce site speed: prioritizing fixes for a large catalogue
- Technical SEO: finding crawl and indexing problems
- Website design for visitors, search engines and AI
- How much does a website cost in Quebec in 2026? Prices and budget
- Website redesign: defining goals before you begin
Related services
Frequently asked questions
Do Core Web Vitals push my site up in Google?
Not in a marked way. Google highly recommends meeting them and specifies that this recommendation aligns with what its ranking systems seek to reward. Better but slower content still beats weak, fast content. The budget is better justified by lost sales, which you can measure on your own site.
My PageSpeed score is low: is that serious?
Not necessarily. That score comes from a lab test and is used to find causes. Look instead at the Core Web Vitals report in Search Console, which is based on your real visitors. If your pages pass all three thresholds there, gaining points in PageSpeed pays little.
Why does my site seem fast but get sluggish as soon as someone filters?
That is responsiveness to interactions (INP) degrading. It does not measure loading: it measures the delay between an action and the response on screen. On a catalogue, the typical action (filtering, sorting, choosing a variant) is precisely the most costly. The usual causes are too many third-party scripts and a list recalculated in full on every click.
