There Is No Core Web Vitals Score (and Why That Matters)

"Our Core Web Vitals scores are going down. Can you help?"

That is the question I get asked a couple of times a day. The first thing I need to ask myself is 'What is this Core Web Vitals score that you are talking about?' When people contact me they have just found out that they have issues with their page speed and they cannot fix them themselves. Usually that means that either their lab data (Lighthouse) or field data (CrUX and RUM) is failing.

Last reviewed by Arjen Karel on March 2026

So if someone is telling you that their Core Web Vitals are failing the first thing that you need to figure out is whether they are talking about lab data or field data. A great indicator that they are talking about lab data (Lighthouse) is that they mention this 'Core Web Vitals Score'.

Oh no, it's a Lighthouse score

When I then enquire about that magic 'Core Web Vitals Score' at this point many of the people that contact me will show me a failing Lighthouse score. Here is where things get tricky! A failing Lighthouse score does not mean that you are failing the Core Web Vitals. Just as a 'green' Lighthouse score does not mean you are passing the Core Web Vitals. It just means you are failing or passing that very specific test.

The numbers prove this. An HTTP Archive study found that 43% of pages scoring 90 or higher in Lighthouse still failed at least one Core Web Vital in the field. Even at a near perfect Lighthouse score of 99, almost 1 in 4 pages failed. The gap is probably wider today because INP replaced FID in March 2024, and Lighthouse cannot measure INP at all.

Tell them about field data

So the next thing that I do is tell them about field data. In this case CrUX data. CrUX stands for Chrome User Experience Report. CrUX is a dataset that reflects how real-world Chrome users experience popular destinations on the web.

CrUX is the official dataset of the Web Vitals program. That means in order to pass (or fail) the Core Web Vitals for 3 metrics (LCP, INP and CLS) at least 75% of your visitors need to have a good experience. Google measures this at the 75th percentile. That means your worst 25% of visits are what determines your score. One slow server response during peak traffic can drag down your entire origin.

Google Search Advocate John Mueller has been clear about this: "Chrome's Lighthouse tool also creates scores. Google doesn't use these scores for search." What Google does use is CrUX field data. For a full breakdown of how Core Web Vitals affect rankings, see Core Web Vitals and SEO.

So now you might understand that there is no one 'Core Web Vitals Score' that will make you pass or fail the Core Web Vitals.

Show them the field data

Now that your client knows about field data it is time to show them. Remember the 'failing' Lighthouse score I just showed you? This is the corresponding CrUX data. As you can see they are passing it and there is really no need to worry about the Core Web Vitals for this client.

The process is simple. Navigate your browser to pagespeed.web.dev and enter the URL. Next select Origin (which is located right next to 'This URL') to show the Core Web Vitals for the entire site and not just the front page. You can also use the CrUX History report to track how your metrics change over time. And no, CrUX data does not update every 28 days.

So what about Lighthouse?

At this point, after you made a compelling case and basically have proved to them what I just said, 99% of your clients are not ready to let go of the Lighthouse score. I get it. It has an allure. It's hard to imagine the green, orange and red numbers that anyone can interpret really do not matter at all.

Well you need to remember that Lighthouse is a test. It's a very cool test. I love much of what it does, I love how it is coded and I love how it can help you fix some Core Web Vitals issues. But there are 4 things it will not do:

1. Interact with a page. That basically makes the test unusable. Visitors will interact with your page. From that interaction you will get your conversion.

2. Act as a repeat visitor. Lighthouse (by default, you could change this setting) visits your page as if it has never visited your page before. Often for page render and page timing this will make a world of difference. So Lighthouse is not representative of a large portion of your visitors.

3. Understand anything about your page. The best example is in the Total Blocking Time audit. Even most experts agree that a large Total Blocking Time is a bad thing but that is not the entire story. As long as the 'blocking' does not happen when the page needs to be responsive (you can force this!) and the blocking does not happen during early rendering you are probably completely fine even though you get a bad Lighthouse score!

4. Measure Interaction to Next Paint. INP is one of the three Core Web Vitals, but Lighthouse gives it exactly 0% weight because it requires real user interaction. Lighthouse uses Total Blocking Time as a proxy, which gets the highest weight at 30%, but TBT and INP can move in opposite directions. In 2025, lab TBT increased by 58% while field INP actually improved. That alone should tell you how much trust to put in a single Lighthouse number.

According to the 2025 Web Almanac, only 48% of mobile origins pass all three Core Web Vitals. On desktop that number is 56%. If your client is passing, they are ahead of more than half the web. To keep it that way, set up Real User Monitoring so you can catch regressions before your clients do. Across sites tracked by CoreDash, origins with active monitoring catch CWV regressions within 48 hours on average, compared to weeks for sites relying on periodic Lighthouse checks.

If you want a step by step plan for passing the Core Web Vitals, check out how to pass Core Web Vitals.