PageSpeed Insights is the tool everyone uses for Core Web Vitals, and it tests one URL at a time. That’s fine for your homepage. It’s not fine when you need to know which of 3,000 product pages are failing, and why.
This guide covers how to read Core Web Vitals correctly, how to check them across a whole site, and how to decide what to fix first.
What are good Core Web Vitals?
Core Web Vitals are three metrics for loading, responsiveness and visual stability. Google’s Core Web Vitals documentation and web.dev set the thresholds:
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading | ≤ 2.5 s | > 4 s |
| INP (Interaction to Next Paint) | Responsiveness | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability | ≤ 0.1 | > 0.25 |
Two details matter more than the numbers:
- They’re measured at the 75th percentile of page loads, segmented by mobile and desktop. A page passes when three out of four visits are good, not on average.
- A page needs all three to be good to pass the assessment.
Field data or lab data: which one counts?
Field data is how real Chrome users experienced the page over the previous 28 days, from the Chrome UX Report (CrUX). Lab data is a single simulated Lighthouse test on one device and network.
web.dev is direct about which matters: lab measurement “is not a substitute for field measurement”. Field data reflects real devices, networks and interactions. INP in particular depends on real user input. Use field data to decide whether a page has a problem, and lab data to find out why.
One catch: field data needs traffic. When a URL doesn’t have enough, PageSpeed Insights falls back to origin-level data for the whole site, and when the origin has too little, there’s no field data at all. Always check whether a number is for the URL or the whole origin before acting on it.
How do you check Core Web Vitals for a whole site?
Search Console: the big picture
The Core Web Vitals report in Search Console groups URLs “into pages that have a similar user experience”. It’s the right starting point, but it shows a sample of example URLs rather than every page (Google notes it “isn’t a comprehensive list”), and it doesn’t tell you the cause.
Testing pages in bulk
To get per-page results you need to query PageSpeed Insights or the CrUX API for each URL. That takes a free PageSpeed Insights API key and some way to run and collect hundreds of tests.
In Crawlens, add the API key in Settings, then use Measure Core Web Vitals on the project overview. It tests your most important pages first, starting with the start page and then the indexable pages with the most internal links, on mobile, desktop or both. Each test returns field data where it exists, plus a Lighthouse lab test with its biggest opportunities.
For field data on every page, Real-user data for all pages checks the Chrome UX Report for every indexable URL, about 140 pages a minute; pages with little traffic simply have none. A 25-week trend shows how the whole site’s field metrics have moved.
What the audit flags
| Check | What it flags | Severity |
|---|---|---|
| Poor LCP for real users | Field LCP over 4 s | Warning |
| Poor INP for real users | Field INP over 500 ms | Warning |
| Poor CLS for real users | Field CLS over 0.25 | Warning |
| Core Web Vitals need improvement | At least one metric between good and poor | Notice |
| Low Lighthouse performance score | Lab score under 50 | Notice |
| Pages PageSpeed Insights could not test | Pages Google couldn’t load, often bot protection or timeouts | Notice |
Each flagged URL shows whether its data is for the URL itself or the whole origin. When both mobile and desktop were measured, the audit uses mobile, since Google indexes mobile-first.
What should you fix first?
Fix templates, not pages. Core Web Vitals problems almost always come from a template: the product page, the category page, the article layout. Group failing URLs by template and you’ll usually find two or three causes behind hundreds of pages.
Start with pages that matter. Put Core Web Vitals next to Search Console clicks or GA4 sessions. A poor LCP on a page with no traffic can wait; the same problem on your top landing pages can’t.
Then work metric by metric:
- LCP: speed up the server response, preload the hero image and serve it in a modern format at the right size, and remove render-blocking CSS and JavaScript.
- INP: break up long JavaScript tasks, defer third-party scripts, and keep event handlers light.
- CLS: set width and height on images and embeds, reserve space for ads and banners, and don’t insert content above what’s already on screen.
How do you know a fix worked?
Field data is a rolling 28-day window, so improvements show up gradually. Check the lab test straight away to confirm the change did what you expected, then measure field data again after a few weeks. Crawl comparison and the 25-week trend show whether the site as a whole is moving in the right direction.
Checklist
- Judge pages on field data (CrUX) at the 75th percentile, not lab scores
- Check whether field data is URL-level or origin-level
- Measure mobile first; it’s what Google indexes
- Group failing URLs by template
- Prioritise templates behind pages with search traffic
- Confirm fixes in the lab, then re-check field data after a few weeks
Frequently asked questions
What are good Core Web Vitals scores?
Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads.
What's the difference between field data and lab data?
Field data comes from real Chrome users over the previous 28 days (the Chrome UX Report). Lab data comes from a single simulated Lighthouse test. Field data is what reflects real experience; lab data helps you find causes.
Why does PageSpeed Insights show data for the whole site instead of my page?
When a URL doesn't have enough real-user traffic, PageSpeed Insights falls back to origin-level data, which covers all pages on the site. If the origin has too little data too, no field data is shown.
Why is my Lighthouse score good but Core Web Vitals poor?
Lab tests use one device and network, while real users have slower phones, flaky connections and interact with the page. Field data can be worse, and INP can't be measured in a simple lab load at all.
Do I need an API key to test many pages?
To run PageSpeed Insights tests in bulk you need a free PageSpeed Insights API key from Google Cloud. Each test runs on Google's servers and counts towards your daily quota.