PageSpeed Insights score vs Core Web Vitals: what to fix

Below, we explain how each number is made, show how to check the one that counts, and say what we fix first.

What is the difference between a PageSpeed score and Core Web Vitals?

The PageSpeed score is a single 0 to 100 number from a lab test. Core Web Vitals are three metrics, loading, responsiveness and visual stability, judged on real-user data. One is a simulation, the other is a measurement of what happened.

Google’s PageSpeed Insights documentation (last updated 21 October 2024, accessed 22 Oct 2026) says PSI uses Lighthouse to analyze a URL in a simulated environment. That lab data is useful for debugging but may miss real-world bottlenecks. Field data comes from the Chrome UX Report, covering the previous 28 days.

The same page says a Lighthouse performance score of 90 or above is good, 50 to 89 needs improvement, and below 50 is poor.

How is the Core Web Vitals pass mark different?

The Core Web Vitals pass mark is a separate test. PSI says an aggregation “passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good.”

If INP lacks enough data, the pass rests on LCP and CLS alone. If LCP or CLS lacks data, no assessment can run.

• Lab data (the PageSpeed score)One simulated load of one page. Good for finding the cause.
• Field data (Core Web Vitals)Real Chrome visitors over 28 days. This is what passes or fails.

The bands come from Search Console’s Core Web Vitals report (accessed 22 Oct 2026). Google’s Search guidance on Core Web Vitals gives the same Good targets.

The 75th percentile means three in four visits were at least that good. Google’s web.dev says why it chose this point. The percentile “should ensure that a majority of visits to a page or site experienced the target level of performance.”

A pass is a statement about your visitors, not about your test run.

Our glossary has short definitions of PageSpeed Insights, LCP and INP if any term here is new.

Why do the two numbers disagree?

A lab test controls variables on purpose, and real visitors do not. One fixed device, one network and one location can never match a month of different phones, connections and behavior. The gap is expected, and it is not a bug in either tool.

Google’s web.dev explanation (last updated 18 July 2022, accessed 22 Oct 2026) lists the causes. We group them by how often they bite service-business sites:

• Interaction. Lab tests cannot accurately predict when users will choose to interact. web.dev says that is why they cannot accurately measure FID, the responsiveness metric then. The lab never tapped your menu, your chat widget or your quote form.
• Layout shift after load. Lab CLS only counts shifts above the fold and during load. Field CLS also includes shifts that happen as people scroll or interact.
• The LCP element. It can differ by screen size, login state or A/B test, so the element your test measured may not be the one most visitors see.
• Cache. Lab tests usually start cold, while returning visitors may already have your files.
• Back-forward cache. Lab tests do not account for it, and restored pages can show faster field LCP.

The article gives an example of the gap: LCP at the 75th percentile was 1.8 seconds in the field while the lab showed 3.0 seconds. The lab can just as easily be the optimistic one, and that is the dangerous direction.

One more tool deserves a caution. Total Blocking Time is a lab metric meant to help diagnose INP issues, but web.dev says it does not model user behavior. A tap delay is not a long task, so a page can have poor INP despite a very good Total Blocking Time score.

Which number should you trust, and when?

Trust field data when it exists. Use lab data to debug and when field data is missing. The same web.dev page says field data is what you should use to prioritize your efforts.

This is the decision order we use on a service-business site, and it’s meant to be followed top to bottom:

1. Check whether field data exists for the page. If yes, read the Core Web Vitals result there first.
2. If field data passes all three metrics, stop. A low lab score on a passing site is not a ranking or lead problem to fix this quarter.
3. If field data fails, note which metric fails and on which device. Fix the failing metric, not the score.
4. Use lab data only to find the cause of that failing metric.
5. If there is no field data at all, use lab data as a rough guide and plan to recheck after traffic builds.

1. Look for field dataIf it exists, read the Core Web Vitals result first.
2. Passing? Stop.A low lab score on a passing site can wait.
3. Failing? Note the metric and deviceFix the failing metric, not the score.
4. Use lab data for the causeOnly to find why that metric fails.
5. No field data? Use lab as a rough guideRecheck after traffic builds.

Four hypothetical sites show how the order plays out. The numbers are invented, and the verdicts apply the bands above.

Site A is the one clients resist. A lab score of 62 with passing field data is in better shape than site B’s 96 with a failing INP. That is because A passes the check Google documents.

Be careful in the other direction too. Google’s page experience documentation (accessed 22 Oct 2026) says good Core Web Vitals do not guarantee a top ranking. It adds that Google shows the most relevant content even when page experience is poor.

We read that as: fix failures, then stop.

How do you check real-user Core Web Vitals?

Open the Core Web Vitals report in Search Console for your property, then check the specific page in PageSpeed Insights. Each source reads the same Chrome UX Report data, but they group it differently, so use more than one.

These are the places we look, and what each is good for:

Those details come from Chrome’s list of CrUX tools (accessed 22 Oct 2026). Search Console, it notes, shows about three months of history, while PageSpeed Insights does not provide historical data.

How does Search Console group URLs?

In Search Console, URLs are grouped into pages that share a similar user experience. A group’s status is its weakest metric. Google’s example is a URL with Poor CLS and Needs improvement LCP, which is labeled Poor.

Status is also set per device type, so a group can be Good on mobile and Needs improvement on desktop.

When a page group is too small, Search Console builds a higher-level origin group instead, and we found no stated minimum sample size. Our Search Console guide covers property setup if you have not connected one yet.

How do you run a reproducible check with the CrUX API?

Send one request to the CrUX API for your page or your origin, then read the 75th percentile for each metric. It takes one command and returns the same field data PageSpeed Insights shows, without opening a browser.

The CrUX API guide (accessed 22 Oct 2026) documents the request. You need your own API key:

API_KEY="YOUR_KEY"
curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"url": "https://www.example.com/services/water-heater-repair/", "formFactor": "PHONE"}'

Swap url for origin to get data across every page on the site. Each request takes one origin or one URL. Per the guide, leaving out formFactor returns all form factors combined, so run it once for PHONE and once for DESKTOP.

The response holds a record with metrics. The guide names the three keys largest_contentful_paint, interaction_to_next_paint and cumulative_layout_shift.

Each has a histogram of visit shares and percentiles.p75. To print only the p75 values, pipe the response to jq:

... | jq '.record.metrics | {lcp_ms: .largest_contentful_paint.percentiles.p75, inp_ms: .interaction_to_next_paint.percentiles.p75, cls: .cumulative_layout_shift.percentiles.p75}'

Compare each value with the table above. LCP and INP come back in milliseconds, so 2,500 and 200 are the Good cut-offs. CLS is a unitless score where 0.1 or under is Good.

We have not included output from a live property. Our network blocked the Google API host, so we could only syntax-check the filter against a hand-written mock response shaped like Chrome’s sample. Check your own response against Chrome’s guide.

If the API returns a 404 with “chrome ux report data not found,” that is information, not an error to fix. Chrome’s guide lists three causes:

• The URL or origin lacks enough samples.
• It is not publicly navigable (an incorrect protocol or an unneeded www.).
• It is not publicly indexable.

Low-traffic pages often have no URL-level data. PageSpeed Insights then falls back to origin-level data, which covers all pages on the site. If the origin lacks data as well, PSI shows no real-user data, which is normal for a new site.

What should you fix first on a service-business site?

Fix the failing field metric on the pages that earn leads, in this order:

• LCP on service pages.
• INP on pages with forms and menus.
• CLS on any page where content jumps.

Start with the template, because one fix repeats across every page that uses it.

The list below is our own view from auditing sites. It isn’t a ranking from Google.

1. LCP: find the largest element. On a service page it is usually the hero image or a headline block.
   • In the lab report, open the LCP element and its breakdown.
   • Common fixes are resizing the image, serving a modern format, and not lazy-loading the hero.
2. INP: find what runs on tap. Chat widgets, tag managers, review carousels and booking embeds are frequent causes. We test by removing one third-party script at a time and rechecking in the lab, then wait for field data to confirm.
3. CLS: find what loads late. Cookie banners, embedded maps, ad slots and images without set dimensions shift the page. Reserve space for each.

For depth on each metric, see our guides to Core Web Vitals and INP. Some sites sit on a theme or builder that makes these fixes hard. Our Core Web Vitals service for website design and development covers it.

Why not chase the last five points of a Lighthouse score?

We don’t chase the last five points of a Lighthouse score. In Lighthouse 10, CLS alone makes up 25% of the performance score, per Chrome’s release notes (accessed 22 Oct 2026). Weights can change between versions.

A lab score is a weighted mix of lab metrics. It isn’t a pass or fail on the vitals.

A site can pass with a lab score in the low 60s and fail with one in the mid-90s, as sites A and B showed. Don’t trade lead-generating features for a number no visitor sees.

How long until the numbers move?

Expect 28 days or more for field data to reflect a fix. The dataset is a rolling window, and old visits age out one day at a time. Lab data changes within minutes of a deploy, which is why it suits testing and misleads in reports.

Search Console builds this into its fix process. According to Search Console Help, Start Tracking opens a 28-day monitoring session, and it does not trigger re-indexing or any other active behavior from Google.

Take a hypothetical fix shipped at the end of 1 November 2026. On 15 November, with steady daily traffic, 14 of the 28 days in the window are post-fix, which is 50%. The window is fully post-fix from 29 November 2026 (1 November plus 28 days).

1. 1 November 2026The hypothetical fix ships at the end of the day.
2. 15 November 202614 of the 28 days in the window are post-fix, or 50%.
3. 29 November 2026The window is fully post-fix.

Do not roll back a good fix because the number has not moved in a week. Ship it, note the date, and read the field data after four weeks.

For before-and-after reporting, record the field p75 values and the date you read them. Without the date, you cannot tell whether a change was the fix or the window.

What does this mean for your site?

• Start with the field data. Open the Core Web Vitals report in Search Console and see which page groups fail.
• If everything passes, stop chasing the lab score. Put your time into content and links.
• If a group fails, name the metric and the device. Then fix the template that group shares.
• After the fix, wait 28 days or more. Record the date you read the numbers, so you know what you are comparing.

What does the data not show?

Core Web Vitals field data is real, but it is a sample of Chrome visitors and a rolling average. It does not show every visitor, and it does not tell you what a faster page is worth in leads.

• Chrome visitors only. The Chrome UX Report reflects real Chrome users, so other browsers are not in it.
• Eligibility limits. Pages without enough samples, or that are not public, do not appear.
• No lead link. We have no sourced data that connects a passing result to more calls on a service-business site. We do not claim one.
• Group averaging. Search Console reports groups of similar pages, so one slow page can hide inside a passing group, or a fast page can be dragged down.
• Age of sources. Google’s web.dev lab and field article was last updated in July 2022, so check its details against current PSI behavior.

Where does this fit in a technical SEO audit?

Core Web Vitals are one check among many. Crawl access, indexing, canonicals and redirects usually come first, because a fast page that Google cannot index earns nothing. Our technical SEO guide puts speed in context.

For a quick read on your own site, try our website SEO checker. For the wider checklist, see what a good SEO audit includes and our SEO audit checklist.

If design choices are behind the slowdowns, how website design affects SEO covers the trade-offs. Website design mistakes that hurt SEO lists the usual ones. If you would rather have specialists find the cause and fix it, that is the work behind our technical SEO service.

Frequently asked questions

Check your own pages with the website SEO checker, then Get Your Organic Growth Plan.

Sources

• About PageSpeed Insights, Google for Developers, last updated 21 Oct 2024, accessed 22 Oct 2026
• Why lab and field data can be different, web.dev, last updated 18 Jul 2022, accessed 22 Oct 2026
• Core Web Vitals and Google Search results, Google Search Central, accessed 22 Oct 2026
• Understanding page experience in Google Search results, Google Search Central, accessed 22 Oct 2026
• Core Web Vitals report, Search Console Help, accessed 22 Oct 2026
• CrUX tools, Chrome for Developers, accessed 22 Oct 2026
• How to use the CrUX API, Chrome for Developers, last updated 25 Jun 2020, accessed 22 Oct 2026
• What’s new in Lighthouse 10, Chrome for Developers, accessed 22 Oct 2026
• How the Core Web Vitals metrics thresholds were defined, web.dev, last updated 7 May 2025, accessed 23 October 2026