
PageSpeed Insights (PSI) is Google's free tool that reports how a URL performs, combining a simulated Lighthouse test with real-user data from the Chrome UX Report where available. You use it to diagnose performance problems and to see whether real visitors pass Core Web Vitals — two related but very different questions that PSI answers on the same page.
Lab vs field: the distinction that decides everything
Every PSI report is really two reports stapled together, and misreading which is which causes most of the confusion around the tool.
The field data at the top comes from CrUX — the Chrome User Experience Report — which aggregates what real Chrome users experienced on your page over the trailing 28 days. This is the data connected to Google's page experience signals. It updates slowly, requires enough traffic to exist at all (low-traffic pages show origin-wide data or nothing), and reflects your actual audience: their devices, their networks, their geography.
The lab data below it is a one-off Lighthouse run from a Google server, simulating a mid-tier device on a throttled connection. That's the section with the famous 0–100 performance score. The score is a diagnostic snapshot under standardized conditions — useful for finding what to fix, but it is not what Google ranks you on, and it is not what your users experience.
This produces the two classic head-scratchers. "My score is 55 but I pass Core Web Vitals" — your real users, on real hardware, have a fine experience even though a throttled simulation struggles; you're fine. "My score is 95 but I fail CWV" — the simulation is kind, but your actual audience on mid-range Androids over cell networks is suffering; you have work to do, and the field data is the one that counts. The full breakdown of this split lives in Core Web Vitals: Field Data vs Lab Data.
And about that score: run PSI three times in ten minutes and you can get 62, 71, and 58 without touching the site. Server load, network variance, third-party scripts firing differently, and A/B tests all move it. Single-digit changes are noise. Anyone reporting "the score went from 68 to 72" as an achievement is reporting weather.
Lab vs field metrics: what each is for
| Metric | Lab (Lighthouse) | Field (CrUX) | When each matters |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Measured in the simulated run | 75th percentile of real visits | Field decides pass/fail for page experience; lab tells you which element is the LCP and why it's slow |
| INP (Interaction to Next Paint) | Not measurable — a robot doesn't interact | Field only | Only real users generate INP; lab proxies like Total Blocking Time hint at it but routinely miss real-world jank |
| CLS (Cumulative Layout Shift) | Shifts during simulated load only | Shifts across the whole real visit, scrolling included | Lab catches load-time shifts; field catches the ad that injects itself mid-scroll — they disagree often |
| TTFB (Time to First Byte) | One server, one request | Distribution across your real geography | Field TTFB exposes hosting/CDN gaps for distant users that a single lab request never sees |
| Performance score (0–100) | Lab only, weighted composite | Does not exist in field data | Triage and dev communication only — never a KPI, never "what Google sees" |
How to actually use PSI
- Read the field data first. If CrUX shows all-green Core Web Vitals at the 75th percentile, the page experience box is ticked — anything further is engineering polish, not SEO urgency.
- Check whether you're seeing URL-level or origin-level data. PSI falls back to origin-wide numbers when the specific URL lacks traffic; the label is easy to miss and the difference is enormous.
- Use lab diagnostics to find causes: the Opportunities and Diagnostics sections name the render-blocking scripts, oversized images, and layout-shift culprits behind bad field numbers.
- Fix, wait, verify in field data. CrUX is a 28-day rolling window, so a real fix takes weeks to fully reflect. Verify the deploy immediately with lab runs; verify the outcome with field data a month later.
- Test at scale via the API or crawler integrations rather than pasting URLs one at a time — template-level patterns matter more than any single page. Interpretation help: Google PageSpeed Insights Interpretation.
Common mistakes (and fixes)
- Chasing 100/100. The lab score has diminishing returns past "good," and Google rewards passing field CWV, not a perfect simulation. Fix: green field metrics are the goal; the score is a diagnostic.
- Panicking over run-to-run score swings. Fix: run 3–5 tests and look at the median, or better, watch field trends instead.
- Optimizing for the lab device. Teams fix the throttled-Moto-G simulation while their real audience is on iPhones and desktop — or vice versa. Fix: let field data (and your analytics device mix) set priorities.
- Reading origin-level data as page-level. Fix: check the data-source label before diagnosing a specific URL.
- Expecting rankings to jump after passing CWV. Page experience is a modest signal among hundreds. Fix: treat performance as user-experience and conversion work that also removes an SEO handicap — the wider context is in Core Web Vitals in 2026.
FAQ
Is the PSI score a ranking factor?
No. Google's page experience signals draw on field Core Web Vitals data, not the Lighthouse score. A page can score 45 in the lab and carry perfectly green field vitals — that page has no performance problem in Google's eyes.
Why does my page show no field data?
Not enough Chrome-user traffic on that URL in the 28-day window. PSI falls back to origin-level data, or shows lab-only results. It's a visibility threshold, not a penalty — but it means Google is judging your page experience at the origin level too.
Why do PSI and my own device disagree?
Your machine on office wifi is one data point near the fast end of the distribution. Lab data simulates a slower device; field data is the 75th percentile of everyone. All three are "real" — they're just different points on the same curve.
PSI, Lighthouse, or CrUX — what's the difference?
Lighthouse is the lab engine (also in Chrome DevTools). CrUX is the field dataset. PSI is the front-end that runs Lighthouse and displays CrUX side by side. Same data family, three doors in.
How long until fixes show in the field data?
Up to 28 days for the rolling window to fully turn over, longer for sparse-traffic pages. Confirm the fix in lab immediately; judge success in field after a month.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







