Skip to content
Sondeon

Guides

Updated on Reviewed by José María Salido

Core Web Vitals: what they are, what they measure and what ruins them

Three measures of how your site feels when it opens. Google uses them to rank, and visitors notice them before reading a single line.

Book a free meeting

What each one measures

LCP, the time until the largest block of the first screen is painted: good below 2.5 seconds. INP, how long the page takes to answer a tap or a click. And CLS, how much the content moves while loading, which is what makes you tap the wrong thing.

They are measured twice: in a lab, with a tool, and with real visits. The second one rules, because that is the one Google uses.

The thresholds: when each one is good

Google sets three thresholds: LCP is good up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1. They are measured at the 75th percentile of real visits, so it is not enough for the page to work well on your computer: it has to work well for three visits out of four.

INP replaced FID in March 2024. FID only measured the wait before the first response; INP measures every interaction of the visit, which is why script-heavy pages fail it more often.

web.dev (Google), "Web Vitals"

How to measure Core Web Vitals

With real visit data: the Core Web Vitals report in Search Console and PageSpeed Insights, both based on the Chrome User Experience Report. With lab data: Lighthouse and the browser developer tools, which help find the cause but do not tell you what your visitors experience.

If the site has little traffic there is no real data and only the lab is left. Then you measure several times, on mobile and on a slow network, because a single measurement misleads.

What ruins them on a site built with AI

Almost always the same: images served at their original size, fonts that arrive late and shift the text, a notice that appears once you were already reading, third party scripts that block painting, and a first screen that waits for an API call before it can draw.

None of that shows at build time: it shows by measuring the published page, on mobile and on a slow network.

How we measure them and what you get

We measure every published page on mobile and desktop, with Lighthouse and with a real browser, and we repeat the measurement before opening a finding, because a single run lies. You get which element is the LCP of each page, what delays it and how much is gained by removing it.

It is part of the website review, along with security, accessibility and visibility on Google and in AI engines.

Public website review

What you get, every time

One report for two readers: one page for leadership and the detail with evidence for your team.

  1. The health status

    For each system reviewed: code, apps, website, backend, databases, server and platforms.

  2. Every finding checked

    With the evidence of where it is and why it matters.

  3. The list ranked by impact

    What to fix first, what can wait and what doesn't matter.

  4. A meeting and a page

    We walk your team through it, and leadership gets a one-page summary.

See the sample report

Frequently asked questions

What are Core Web Vitals?

Three experience measures: LCP (when the largest block paints), INP (how long it takes to respond) and CLS (how much content moves). Google uses them for ranking.

What is a good LCP?

Below 2.5 seconds on mobile. Between 2.5 and 4 needs improvement, and above 4 counts as poor.

Do Core Web Vitals affect ranking?

Yes, as one signal among others. They do not replace content, but between two similar pages, the one that opens well wins.

What is a good INP?

Up to 200 milliseconds is good, between 200 and 500 needs improvement and above 500 counts as poor, always at the 75th percentile.

How are Core Web Vitals measured?

With real visits in Search Console and PageSpeed Insights, and in the lab with Lighthouse or the browser, which help find the cause.

Request your free meeting

Fill in the form and we email you to set a day and a time. It is 30 minutes to see what you have and what to review first.

What should we control?

We use your details to answer your request, to be able to prove we received it and to protect the form. The privacy policy explains it in detail.