You ran your site through PageSpeed Insights and got an orange number for mobile and a green one for desktop. You run the test again and the numbers have changed. To measure website speed with PageSpeed Insights in a way that means something, you need to know which numbers come from real visitors and which come from a single simulated test.
This guide explains why the mobile result is the one that matters, how to read the two parts of the report and what LCP, INP and CLS mean. Then it shows how to test fairly and how to prioritise the recommendations. By the end you will have a recorded baseline to compare every later change against.
What PageSpeed Insights shows
PageSpeed Insights is a free Google tool at pagespeed.web.dev. You enter the address of a page and get a report in two sections, with separate results for mobile and desktop.
The first section, Discover what your real users are experiencing, holds data from real visitors over the last 28 days. It comes from the Chrome User Experience Report (CrUX), Google's dataset on how Chrome users load websites. Only users who have agreed to share this data are included. Chrome on iPhone does not take part, so visitors on iPhones are missing from it.
If the page does not have enough visits, PageSpeed Insights shows data for the whole site (Origin) instead, and if the site does not have enough either, the section stays empty. Google does not say how many visits are needed. The address also has to be public, meaning search engines can reach it.
The second section, Diagnose performance issues, is a lab test run with Lighthouse, Google's tool for auditing web pages. It loads the page once in a simulated environment and calculates the 0 to 100 score and the recommendations from that single load. The first section shows how the site behaved for your real visitors, and the second helps you find out why.
Why the mobile result matters more
Google indexes sites by their mobile version. The Google Search documentation says it uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. So open the Mobile tab first.
The mobile test is also the stricter one. Lighthouse simulates a mid-range phone on a slow mobile connection it calls Slow 4G, with 150 milliseconds of latency and 1.6 Mbps download, and deliberately slows down the processor. The desktop test simulates a wired connection. That is why the same site usually scores lower on mobile, and it is not a fault in the test.
The Core Web Vitals thresholds are the same for phones and computers, but the real-visitor data is shown separately for each. Check in Google Analytics where your orders or inquiries come from. If most come from phones, the mobile numbers are the ones that affect your sales.
Core Web Vitals and their thresholds
Core Web Vitals are the three metrics Google uses to describe what visitors actually experience. Each is assessed at the 75th percentile of visits, which means a page is in the good range when at least three out of every four visits are. That way most visits get a good experience, and a few extreme cases do not distort the result.
| Metric | What it measures | Good | Poor | In the lab test |
|---|---|---|---|---|
| LCP | When the largest element on the screen appears, usually an image or a block of text | up to 2.5 s | over 4 s | Yes |
| INP | How quickly the page responds to a click, a tap or a key press | up to 200 ms | over 500 ms | No, TBT stands in for it |
| CLS | How much the content shifts around | up to 0.1 | over 0.25 | Only during loading |
Between the two thresholds lies the needs-improvement range. A page passes the Core Web Vitals Assessment when all three metrics are in the good range, and if there is not enough data for INP, LCP and CLS are enough. INP takes close to the slowest interaction of the visit, so one slow filter or add-to-cart button is enough to drag it down.
PageSpeed Insights also shows FCP, when the first content appears (good up to 1.8 seconds), and TTFB, the time to the first byte from the server (good up to 0.8 seconds). TTFB is not a Core Web Vital, but it comes before FCP and LCP. Until the server answers, the browser has nothing to show.
Why the lab test and real visitors disagree
The lab test can show a poor LCP while real visitors are in the green, or the other way round. Usually both are right.
The lab test is one load on one device, with a fixed connection, from one location that the report names (North America, Europe or Asia). The browser starts with an empty cache and does not scroll or click. Real visitors often have some of the files cached already, they scroll, and they see content based on their account or cart. So their LCP can be faster, and their CLS includes the shifts that happen after loading.
The web.dev documentation advises using real-visitor data to set priorities. The lab test is useful when you are looking for the cause of a problem or checking a change before it goes live.
There is also a difference in timing. Real-visitor data always covers the last 28 days. PageSpeed Insights updates it daily, but a change made today will only show fully after about four weeks. The lab test shows it straight away.
Why the score changes on every run
Run the same test twice and the score will almost certainly differ, even if you have not touched the site. The Lighthouse documentation lists many reasons. The page itself can vary because of ads, A/B tests or third-party scripts, the network is different each time, and the server can be busier at one moment than at another. If you run Lighthouse from your own computer, browser extensions and antivirus software play a part too.
So a single run tells you little. According to the same documentation, the median of five runs is twice as stable as a single run. The median is the middle value when you sort the five numbers, so the third one, and one random bad run does not move it.
How to test website speed fairly
A fair test is one you can repeat a month later in exactly the same way.
- Pick the pages your business depends on. For a store, that is the home page, one category, one product and the cart. For a company site, the home page, a service page and the contact page.
- Measure typical pages, for example a product with several images and a full description rather than the simplest one.
- Run the test five times on each page and record the median.
- Measure at the same time of day, and not right after clearing the cache, because the first loads after that are slower.
- Enter the address exactly as the site opens, with https and with or without www. Otherwise you also measure the redirect.
- PageSpeed Insights cannot open a test environment behind a password. Use Lighthouse in Chrome DevTools there.
How to read the recommendations without chasing every warning
Since October 2025, PageSpeed Insights has used Lighthouse 13, which groups the recommendations into two sections, Insights and Diagnostics. Older guides mention an Opportunities section, but most of its checks are now part of Insights.
It helps to know what the score is made of. According to the Lighthouse documentation, only the metrics count towards it, not the recommendations. The score is a weighted average of five lab metrics.
| Metric | Weight in the score |
|---|---|
| Total Blocking Time (TBT), how long the page is blocked from responding to the visitor | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index, how quickly the visible part of the screen fills in | 10% |
TBT is a lab proxy for INP, but not a substitute for it. On mobile, Lighthouse treats a TBT of up to 200 milliseconds as good. So start with the recommendations that affect TBT and LCP. In Lighthouse 13 these include Improve image delivery (images in the wrong size or format), LCP request discovery (the main image is found late or lazy loaded), Render-blocking requests (styles and scripts that hold up rendering), Third parties (external scripts) and Document request latency (a slow server response or a redirect).
Not every warning is worth the work. If a recommendation says how much you will save, that is an estimate, not a promise of points. If it concerns a script that earns you money, such as a courier office picker, weigh whether removing it is worth it. And do not add a plugin for every warning, since every plugin adds code too. If the page already passes Core Web Vitals and the lab score is 85, there is no need to chase 100.
What 90+ means and what it does not
A score of 90 to 100 is good and shows green, 50 to 89 needs improvement and shows orange, and below 50 is poor and shows red. The Lighthouse documentation advises sites to aim for the green range and says a perfect 100 is extremely challenging to achieve and not expected.
Ninety is a high bar. Lighthouse scores each metric against real sites in the HTTP Archive. A value that only the fastest 8% of those sites reach earns 90 points, and a value at the level of the fastest 25% earns 50.
Here is what 90+ does not mean.
- It does not guarantee a good experience for real visitors. The PageSpeed Insights documentation says this explicitly about the lab score.
- It does not guarantee rankings. Google Search says that good results in reports such as the Core Web Vitals report in Search Console, or in third-party tools, do not guarantee that your pages will rank at the top.
- It is not an SEO rating. The SEO score in the same report is a basic technical check, and when Google added it to Lighthouse it wrote that the list is not exhaustive and makes no guarantees for search.
A score holds for the day it was measured. An ad pixel, a chat widget or a slider added later pulls it down. That is why, when we hand over a site, we measure it in PageSpeed Insights on mobile on the day of the handover and give the client the report. If anyone promises you 90+, ask for the same, a dated mobile report.
How to record a baseline before a change
Before you change your theme, host or cache plugin, or before you order a new site, write down where the site stands today. Without a baseline you cannot tell whether a change helped. For each page you picked, record the following.
- The date, time and exact address.
- From the real-visitor data, LCP, INP and CLS, whether they are for the page or the whole site, and whether the Core Web Vitals Assessment passed.
- From the lab test, the median of five runs for the score, LCP, TBT and CLS.
- The Lighthouse version that the report shows in the test environment details.
The version matters because Google updates Lighthouse, and the numbers can change without anyone touching the site. The PageSpeed Insights release notes, for example, describe a change in December 2024 to the CPU simulation that affects mobile TBT. Save the link to the report from the Copy Link button as well, plus a screenshot or a PDF.
For the longer view, use the Core Web Vitals report in Search Console, which groups pages by real-visitor data, and CrUX Vis at cruxvis.withgoogle.com. It shows weekly data for the last 40 weeks, if the site is in CrUX.
And change one thing at a time. If you change the cache, the images and the theme all at once, you will not know which helped and which hurt.
Checklist
- You measure on mobile first.
- You know whether the page has its own real-visitor data and whether it passes Core Web Vitals.
- Each key page is measured five times, at the same time of day, and the median is recorded.
- The checkout is measured with Lighthouse in Chrome, with a product in the cart.
- You start with the recommendations for LCP and TBT.
- The baseline is recorded with the Lighthouse version and a link to the report.
- You change one thing at a time and measure again the same way.
Do you have to measure it yourself?
If your mobile numbers are green and your pages pass Core Web Vitals, measure again only after a bigger change. If they are not, see the guide to speeding up WordPress, for stores 7 causes of a slow WooCommerce store and how to fix them, and for Elementor sites Why Elementor slows down your site.
If you would rather not measure and interpret the numbers yourself, with speed optimisation we measure before and after, so you see the difference in numbers. If you are planning a new site or store, with website and online store development we hand the site over with a PageSpeed Insights report, measured on mobile on the day of the handover.
Frequently asked questions
Why is my PageSpeed Insights score different on mobile and desktop?
The mobile test is stricter. Lighthouse simulates a mid-range phone on a slow Slow 4G connection, with 150 milliseconds of latency and 1.6 Mbps download, and deliberately slows down the processor, while the desktop test simulates a wired connection. So the same site usually scores lower on mobile, and that is not a fault in the test.
Why does the mobile result matter more?
Google indexes sites by their mobile version. The Google Search documentation says it uses the mobile version of the content, crawled with the smartphone agent, for indexing and ranking. If most of your orders or inquiries come from phones, the mobile numbers are the ones that affect your sales.
What is the difference between real-visitor data and the lab test?
Real-visitor data covers the last 28 days from the Chrome User Experience Report and decides whether a page passes Core Web Vitals. The lab test is a single Lighthouse load in a simulated environment, from which the 0 to 100 score and the recommendations are calculated. web.dev advises setting priorities by real-visitor data, while the lab test helps you find the cause of a problem.
Why does my PageSpeed Insights score change on every run?
The page can vary because of ads, A/B tests or third-party scripts, the network differs each time and the server may be busier at one moment than another. According to the Lighthouse documentation, the median of five runs is twice as stable as a single run. Run the test five times and record the median, the third of the five numbers when sorted.
What are the LCP, INP and CLS thresholds?
LCP is good up to 2.5 seconds and poor over 4 seconds, INP is good up to 200 milliseconds and poor over 500, and CLS is good up to 0.1 and poor over 0.25. Each is assessed at the 75th percentile of visits, meaning at least three out of every four visits should be in the good range. A page passes Core Web Vitals when all three are good.
Why is there no real-visitor data for my site?
If the page does not have enough visits, PageSpeed Insights shows data for the whole site instead, and if the site does not have enough either, the section stays empty. Google does not say how many visits are needed. The address also has to be public, meaning search engines can reach it.
Can I measure the WooCommerce checkout with PageSpeed Insights?
No. The test starts with an empty cart, and by default WooCommerce redirects the checkout to the cart when the cart is empty, so you end up measuring an empty cart. Put a product in the cart, run Lighthouse in Chrome DevTools and untick Clear storage so the cart is not wiped.
Does a 90+ PageSpeed Insights score guarantee better Google rankings?
No. Google Search says that good results in reports such as Core Web Vitals in Search Console, or in other tools, do not guarantee your pages will rank at the top. The PageSpeed Insights documentation says explicitly that the lab score does not guarantee a good experience for real visitors either. A score holds for the day it was measured, and an ad pixel, chat widget or slider added later pulls it down.
Sources
- Google, About PageSpeed Insights, PageSpeed Insights release notes
- web.dev, Web Vitals, LCP, INP, CLS, TTFB, Defining the Core Web Vitals metrics thresholds, Why lab and field data can be different
- Chrome for Developers, CrUX methodology, CrUX Vis
- Chrome for Developers, Lighthouse performance scoring, Total Blocking Time, Lighthouse 13.0, Lighthouse is moving to performance insight audits, Performance insights, Lighthouse in Chrome DevTools
- Lighthouse, Variability, Throttling
- Google Search Central, Mobile-first indexing best practices, Understanding Core Web Vitals and Google search results, Understanding page experience in Google Search results, Launching SEO Audit category in Lighthouse Chrome extension
- Search Console Help, Core Web Vitals report
- WooCommerce, wc-template-functions.php