SEO guide · 10 Nov 2026 · 5 min read
PageSpeed Insights: how to read the report without getting lost
The report is long, and the big score at the top is the least useful part. Here is what each section means and how to turn it into a short to-do list.
The short answer
PageSpeed Insights tests a page and shows two kinds of results: field data from real Chrome users, where enough exists, and lab data from a controlled test run. Read the field data and the Core Web Vitals first, then use the lab diagnostics to find specific causes. Do not treat the overall score as the goal.
What the tool does
PageSpeed Insights is a free tool from Google. You paste in a page address and it reports how the page performs on mobile and on desktop, with a separate tab for each. It combines two sources of information, and understanding the difference is the key to reading it properly.
It tests one page at a time, not your whole site. A home page may behave very differently from a product page full of large images, so test the pages that matter most to your business: the home page, your top service or category page and a typical article.
If you are unsure which pages to test, start with the ones that bring visitors or enquiries: the pages you advertise, the pages that appear in search for your main services and the pages where people fill in a form or pay. Fixing a slow template used by many pages helps more than polishing one rarely visited page.
Field data and lab data
At the top, when Google has enough information, you will see field data. This comes from real visitors using Chrome, collected in the Chrome User Experience Report. It shows what actual people experience, across their varied phones and connections. If a page or site is too new or has too few visits, the field section may be missing or may show data for the whole origin instead of the single page.
Further down is lab data, produced by running Lighthouse on a simulated device and connection. It is repeatable, so it is good for testing a fix, but it is a single synthetic visit. Two runs can give slightly different numbers. When field and lab data disagree, trust the field data for how real visitors fare, and use the lab data to find causes.
The Core Web Vitals
The headline measures are the Core Web Vitals. Each describes a part of the experience.
| Metric | What it describes |
|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content, often a hero image or heading, appears |
| Interaction to Next Paint (INP) | How quickly the page responds when someone taps, clicks or types |
| Cumulative Layout Shift (CLS) | How much the page jumps around as it loads |
The report labels each as good, needing improvement or poor. Google sets those thresholds and may revise them, so check the current documentation rather than relying on numbers from an old article. Our guide to Core Web Vitals explains each measure in more depth. INP is measured from real interactions, so it appears in field data; lab runs use other responsiveness measures, such as Total Blocking Time.
The performance score
The large circle at the top of the lab section is a score out of a hundred, shown in colour bands. It is a weighted summary of several lab measurements. It is handy as a rough signal, but it is not what the Core Web Vitals assessment uses, and chasing a perfect score can lead to wasted effort.
A page can have a modest lab score and still pass the field assessment, or the reverse. Use the score to compare before and after a change on the same page, with the same settings, and not to compare your site with someone else's.
Opportunities and diagnostics
Below the score the report lists suggestions. They are the practical part. Common items include:
- Properly size and compress images. Often the biggest win. See product images and scripts and lazy loading.
- Reduce unused JavaScript. Scripts from chat widgets, trackers and plugins add weight.
- Eliminate render-blocking resources. Files that stop the page from showing until they load.
- Set width and height on images and embeds. Prevents layout shifts.
- Serve fonts efficiently. See web fonts.
Expand each item to see which files are responsible. The report also lists passed audits, which you can ignore unless you want reassurance.
Treat the suggestions as leads, not orders. Some will be easy and safe, such as compressing an image. Others, such as removing a script, may break a feature you need, like a booking tool or analytics tag. Ask what each script does for the business before cutting it, and test the page after every change.
Turning the report into a short to-do list
- Run the test on your three or four most important pages, on mobile first.
- Note whether the field data passes. If it does, speed is probably not your biggest problem.
- For any failing metric, pick the one or two suggestions linked to it.
- Hand the list to whoever maintains the site, with the file names the report shows.
- Re-test the same page and compare. Allow time for field data to update, since it reflects a rolling period of real visits.
Slow pages are often caused by a few oversized images or heavy third-party scripts, which are fixable without a rebuild. If the cause lies in the platform or theme, a developer can advise. Speed work supports a better visitor experience and is one of many things search engines consider, so do not expect a single fix to change rankings. See also Bing Webmaster Tools for another source of site data.
Limits to keep in mind
PageSpeed Insights is a snapshot. Results shift with server load, time of day and the simulated device. Test a few times before drawing conclusions, and do not treat small differences as meaningful. The tool cannot see pages behind a login, and it may struggle with pages that load content only after complex interaction. Pair it with your own experience: open the site on an ordinary phone on mobile data and note how it feels. If it feels slow or jumpy, believe your own eyes and then use the report to find out why.
A worked example
Take an example business with a home page that passes in the lab but shows poor responsiveness in the field. The field data is telling you real visitors on ordinary phones struggle, which the lab simulation misses. A sensible next step is to check which third-party scripts load on the page, such as chat widgets or tag managers, and test the page with the least necessary ones removed. This is an illustration of how to reason from the report, not a real result.
Another example: a product page with a slow main image. The report points to a large file served at a bigger size than the space it fills. Resizing the image and serving a modern format, if your platform supports it, addresses the cause directly. In both cases the pattern is the same: find the metric that fails, find the item linked to it, change one thing, and re-test.
Related guides
- SEO services
- Bing Webmaster Tools for Small Sites
- URL Structure Best Practices for SEO
- Types of web hosting explained
- Web design vs ui design vs ux design
- How to choose a web development company in pune
Questions and answers
What is a good PageSpeed Insights score?
The tool shows colour bands, but the exact thresholds are set by Google and can change. Check the current documentation, and focus on the Core Web Vitals field assessment rather than the single number.
Why is there no field data for my page?
Field data needs enough real Chrome visits. New or low-traffic pages may have none, in which case the report may fall back to site-wide data or show only lab results.
Why do my scores change between runs?
Lab tests are simulated and affected by network and server conditions, so small variations are normal. Run the test more than once.
Does the score affect my rankings?
Page experience is one consideration among many. The tool score itself is not a ranking number, so use it to find real problems.
Should I test mobile or desktop?
Test mobile first for most sites, because many visitors use phones, then check desktop.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.