Enter a URL at pagespeed.web.dev, read the field data to see if it passes Core Web Vitals, then use the lab data and diagnostics to find what to fix.
To use Google PageSpeed Insights, enter a URL at pagespeed.web.dev and read two sets of results: field data from real Chrome users, which tells you whether the page passes Core Web Vitals, and lab data from a Lighthouse test, which tells you why. Fix the issues in the diagnostics, starting with the ones tied to a failing metric.
PageSpeed Insights is free, needs no login and works on any public URL, including competitors’ pages. That makes it the first tool most people reach for when a site feels slow.
It’s also widely misread. Teams chase a score of 100 when the score itself isn’t what Google uses for rankings, and they ignore the field data that actually shows how visitors experience the page.
Run a test
Go to pagespeed.web.dev, paste in the full URL and select Analyze. The tool runs a mobile and a desktop test and shows mobile first, which is the one to focus on because Google indexes the mobile version of your site.
Test the pages that matter rather than just the homepage. A product page, a category page, a blog post and a key landing page usually run on different templates, and each template has its own problems.
Read the field data first
The top section, “Discover what your real users are experiencing”, is field data from the Chrome User Experience Report (CrUX). It’s collected from real Chrome users over the previous 28 days and reported at the 75th percentile, so three in four visits were at least that good.
This is the data that counts for Core Web Vitals. It shows a pass or fail for the assessment, then each metric against Google’s thresholds:
| Metric | Good | Poor |
|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | 0.1 or less | Over 0.25 |
INP replaced First Input Delay as a Core Web Vital in March 2024, so ignore any older guide that still talks about FID. Our guide to Core Web Vitals explains what each metric measures.
You can toggle between “This URL” and “Origin”. If a page doesn’t get enough traffic for its own field data, PSI may show the origin (whole site) data instead, or no field data at all. Low-traffic pages often have none.
Then read the lab data
The lower section is a Lighthouse test run by Google’s servers at that moment. For mobile it simulates a mid-range phone on a throttled connection, which is why mobile scores are usually much lower than desktop.
Lab data gives you:
- A performance score from 0 to 100: 90 and above is good, 50 to 89 needs improvement, below 50 is poor
- Lab metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index
- A screenshot filmstrip of the page loading
- Diagnostics and opportunities, each with an estimate of the time it could save
Lab tests can’t measure INP because nobody interacts with the page. Total Blocking Time is the closest stand-in: a high TBT usually means heavy JavaScript that will also hurt INP for real users.
Field and lab data often disagree
It’s common to see a poor lab score next to a field data pass, or the reverse. They measure different things. Field data reflects your real visitors, their devices and their connections. Lab data is one simulated visit under fixed conditions.
When they disagree, trust the field data for the question “is this page good enough?” and use the lab data for “what’s slowing it down?”. The lab score also moves between runs, so run a test two or three times before drawing conclusions.
How to act on the results
Work from the failing field metric back to the matching lab diagnostics:
- Note which Core Web Vital fails in the field data, if any.
- Filter the diagnostics by that metric using the “Show audits relevant to” buttons (LCP, TBT, CLS and so on).
- Expand each audit to see the exact files, images or elements involved.
- Fix the biggest items first, usually oversized images, render-blocking scripts and third-party tags.
- Retest the lab data straight away, then wait for the 28-day field data to catch up.
For LCP, look at the “Largest Contentful Paint element” audit, which names the element. For CLS, “Avoid large layout shifts” lists what moved. For TBT, “Reduce JavaScript execution time” and “Minimise main-thread work” point at the scripts. Our guide to improving Core Web Vitals and page speed covers the fixes in more detail.
The other three scores
PageSpeed Insights also runs Lighthouse audits for Accessibility, Best Practices and SEO. These are useful checklists, but the SEO score only covers basics such as a title tag, a meta description and crawlable links. A score of 100 there doesn’t mean a page is well optimised, so don’t treat it as an SEO audit.
How the PageSpeed score relates to rankings
The score doesn’t feed rankings directly. Google’s page experience signals use field data from real users, not the Lighthouse score. Speed is one signal among many, and relevance still matters far more. A faster page does help people stay and convert, which is reason enough to fix it. Our guide to page speed covers how speed fits into SEO.
If your key templates fail Core Web Vitals and you’re not sure where to start, our technical SEO agency can find and prioritise the fixes. Book a free strategy session to talk it through.
Related reading: our guides to making your site mobile friendly and JavaScript SEO.
Common questions
What is a good PageSpeed Insights score?
A performance score of 90 or above is good, 50 to 89 needs improvement and below 50 is poor. Passing Core Web Vitals in the field data matters more than the score.
Why is my mobile score lower than desktop?
The mobile test simulates a mid-range phone on a throttled connection, so pages take longer to load and run scripts. Most sites score lower on mobile for that reason.
Why does my PageSpeed score change each time I test?
Lab tests vary with server load, network conditions and third-party scripts. Run the test two or three times and look at the trend rather than a single result.
Why is there no field data for my page?
Field data comes from real Chrome users over 28 days. Pages without enough visits don’t have their own data, so PageSpeed Insights shows the origin data or nothing.
