BRAND, WEB.
AND 3D SPACES.

· 5 min read · Vetro

Core Web Vitals: what they measure and how to pass them

LCP, INP and CLS: what each one measures, Google's thresholds, where to see your real visitors' data and the fixes that make the most difference.

Macro photograph of a drop falling into pale blue water and throwing up a crown of droplets, with ripples around it
AI-generated image

Core Web Vitals are the three metrics Google uses to measure what a page feels like: how long the main content takes to appear (LCP), how long the page takes to react when you tap it (INP) and how much it moves while it loads (CLS). A page passes when, for 75% of real visits (measured separately on mobile and desktop), all three metrics fall in the “Good” column (web.dev):

Metric Good Needs improvement Poor
LCP (loading) up to 2.5 s 2.5 to 4 s over 4 s
INP (responsiveness) up to 200 ms 200 to 500 ms over 500 ms
CLS (visual stability) up to 0.1 0.1 to 0.25 over 0.25

The acronyms stand for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. INP replaced the old FID on 12 March 2024 (web.dev). If a guide still talks about FID, it is out of date.

Do they count in Google rankings?

Yes, but they do not decide everything. Google confirms that its ranking systems use Core Web Vitals and, at the same time, that it always tries to show the most relevant content, even when the page experience is not great (Google Search Central). A fast website does not make up for content that misses what people are looking for; between two equally useful pages, it helps.

Where speed shows most is in the business. In a study Google commissioned from Deloitte and 55 across 37 European and American brands, making the mobile site 0.1 s faster raised conversions by 8.4% for online retailers and 10.1% for travel sites, and on lead-generation sites 21.6% more users reached the form submission page (web.dev). The data is from 2019 and used metrics older than today’s, but for retailers and travel sites the direction is clear.

Where to see your website’s data

  • Field data, the data Google uses: it comes from real visits in Chrome (the CrUX report). You can see it in the Core Web Vitals report in Search Console, which covers the last 28 days and groups similar pages together (Search Console Help), and at the top of PageSpeed Insights. If your website gets few visits, there may be no data yet.
  • Lab data: a simulated test, like the Lighthouse one at the bottom of PageSpeed Insights. It helps you find the problem, but it is not what Google measures. The Lighthouse test in PageSpeed Insights cannot measure INP, because nobody taps the page during the test, so it uses Total Blocking Time (TBT) instead (web.dev).

Once you have fixed something, you can click “Start Tracking” in Search Console: Google monitors those pages for 28 days before marking the issue as resolved.

How to improve each one

LCP: get the main content there first

  • Do not delay the main image. Never lazy-load it (loading="lazy"), and add fetchpriority="high" so the browser requests it earlier (web.dev).
  • Light images: in WebP or AVIF, and no larger than the size they are shown at.
  • A server that responds quickly, and a content delivery network (CDN) close to your visitors.
  • The main image in the HTML: if JavaScript adds it later, the browser cannot find it in time.

INP: make the page respond at once

  • Less JavaScript, and whatever remains split into short tasks: while the browser runs a long task, it cannot handle a tap (web.dev).
  • Review third-party scripts such as chat widgets, ad pixels or embeds: they all compete for the same thread.
  • Respond straight away with something visible, even just a “loading” state, and leave the heavy work for afterwards.
  • A page that is not too large: the more elements it has, the harder the browser has to work to draw each change.

CLS: keep everything in place

  • Width and height on every image and video (width and height, or aspect-ratio in CSS), so the browser reserves their space (web.dev).
  • Reserve space for anything that arrives late: ads, embedded videos or a notice that appears at the top. Better to float them over the page than to push the content down.
  • Web fonts with a fallback matched to their metrics (size-adjust), so text does not jump when the font swaps.
  • Animate with transform, not by moving top or left.

How we do it at Vetro

Our own website is a 3D experience, and speed is part of the design from the start:

  • the text arrives in the HTML;
  • the logo on the loading screen has high priority and its size reserved;
  • the fonts have fallbacks matched to their metrics;
  • the 3D scene only loads if the browser draws with the graphics card and the visitor has not asked for reduced motion. If not, they get a light version with the same content.

In PageSpeed Insights, which in our tests runs without graphics acceleration and therefore gets that light version, the home page scores 100 for performance on mobile (measured on 5 October 2026). It is what we apply to every website we design.

Frequently asked questions

If my website scores well in PageSpeed Insights, does it pass Core Web Vitals? Not necessarily. The score is a lab test; what counts for Google is the data from your real visits over the last 28 days.

Why does the score change every time I run the test? Because the conditions change: the network, the server or the test device (Chrome for Developers). Run it several times and look at the trend, not at a single number.

What if my website gets few visits and there is no field data? Go by the lab data and fix what it flags. Once there are enough visits, Search Console will start showing real data.

Sources

More from the blog

hi@wearevetro.comInstagramPrivacyLegal notice