Core Web Vitals from real user data

LCP, INP and CLS measured on real Chrome visits over the last 28 days, on mobile and desktop. It is what Google uses in the page experience report, not a simulated load.

  • Free
  • No sign-up
  • Real Chrome data
  • Mobile and desktop

The URL is sent to Google’s Chrome UX Report API from our function and the result is cached for six hours. We do not log what you look up.

How to use it

  1. 01

    Type the URL or the domain

    With “whole origin” every page of the domain is measured together; with “this URL”, only that page, if it has enough traffic.

  2. 02

    Look at mobile and desktop

    Google assesses each device separately and mobile is almost always the one that fails. Here you see both at once.

  3. 03

    Read the p75 and the bar

    The p75 is what decides; the bar shows how visits are spread. A metric can pass with many slow visits as long as 75% go well.

Field data versus lab data

Lighthouse loads the page once, on a simulated phone with a simulated connection, and gives a score. It is useful for finding what to fix, which is why we run it on every build. But it is an approximation: it does not know which phones your audience uses, which network, which extensions, or at what hours your server struggles.

CrUX is the opposite: it simulates nothing. It collects what happened to real Chrome users over the last 28 days and publishes the 75th percentile. It is the data Google uses in Search Console and in the page experience report, and the one that affects rankings. When the two disagree, this one wins.

Each metric, in one sentence

LCP
Largest Contentful Paint. How long the largest element of the first screen takes to appear.
INP
Interaction to Next Paint. How long the page takes to respond when tapped or typed into.
CLS
Cumulative Layout Shift. How much the content moves around while loading.
FCP
First Contentful Paint. How long the first painted content takes to appear. Does not count towards the assessment.
TTFB
Time to First Byte. How long the server takes to start answering. Does not count towards the assessment.

Passing in the lab and failing in the field has a cause

It is almost always one of three: a server that answers slowly at certain hours, third-party scripts that do not load in the simulation but do in the real visit, or an audience on more modest phones than the one Lighthouse simulates. All three can be diagnosed and fixed; what does not work is optimising for the score.

This site has performance budgets verified on every build: maximum CSS and JavaScript weight, LCP and CLS measured before deploying. It is how the field figures do not quietly degrade six months after launch.

How we approach performance and technical SEO →

Frequently asked questions

Why does PageSpeed give me 90 and here I do not pass?

Because they measure different things. The PageSpeed score comes from Lighthouse, which loads the page once, on a simulated device with a simulated connection. CrUX collects what happened to real Chrome users over the last 28 days: with their phones, their networks and their extensions. A site can ace the lab test and fail in the field because of a server that is slow at certain hours, a third-party script that does not load in the simulation, or an audience browsing on modest phones. For ranking, the one that counts is the field data.

What is the p75?

The 75th percentile: the value that 75% of visits do not exceed. If the LCP p75 is 2.1 seconds, three out of four visits saw the main content within 2.1 seconds. Google chose that percentile so a page cannot pass on a good average while a quarter of people suffer it.

How long until an improvement shows up?

The data is a rolling 28-day window updated daily. An improvement published today starts showing within days and is only fully visible once all 28 days are after the change. Here, in addition, the result is cached for six hours.

Why is there no data for my site?

Google only publishes figures once an origin or a URL has a minimum volume of Chrome visits, and it does not say how much. A small site usually has data for the whole origin but not for individual pages; a very small one, for neither. In that case the only measurement available is the lab one, and it is worth remembering that it is an approximation.

Did INP replace FID?

Yes, in March 2024. FID measured only the delay of the first interaction; INP measures the latency of every interaction in the visit and keeps one of the worst. It is stricter and it is the one failing most sites today: usually JavaScript blocking the main thread right when someone taps.

Mobile or desktop?

Google assesses each one separately and for mobile search rankings it looks at mobile. It is almost always the one that fails, because the network and the processor are worse. If you have to choose where to invest, start with mobile.

Is the URL I look up stored?

The URL goes from our function to Google’s Chrome UX Report API, which holds the data; we do not log it. The result is cached for six hours so the same query does not spend quota twice.

Does your site pass in the lab and fail with real users?

It is usually the server, third-party scripts or the weight of the JavaScript. We measure it with field data, fix it and leave performance budgets that watch it on every deploy.

We reply within one business dayBogotá · UTC−5

Message us on WhatsApp (opens in a new tab)