This post explains the difference between lab and field data, why results change between tools and runs, the thresholds Google publishes for Core Web Vitals, and which fixes tend to pay off first. It also shows how to test the same page repeatedly, and how a Page Speed Report lays out the same numbers for mobile and desktop. A final section covers stopping speed from sliding back after you fix it.
Lab data and field data answer different questions
Every page speed test returns one of two kinds of data, and often both. Lab data comes from a controlled test: a tool loads your page on a simulated device and network, and records what happened. It is repeatable, it works on pages with no traffic, and it gives you the detail needed to find causes. It is also an estimate of one imagined visitor.
Field data comes from real people. Google collects timings from Chrome users who visit your pages and publishes them, for sites with enough traffic, in the Chrome User Experience Report. This is what actually reflects your audience, with their old phones and weak connections included. It is the data Google uses when it assesses Core Web Vitals. The catch is that it covers a rolling window of recent weeks, so a fix you made yesterday will not show up in it for some time, and small or new sites often have no field data at all.
Use each for what it is good at. Field data tells you whether you have a problem and how many real visitors it touches. Lab data tells you why, and lets you test a change within minutes. When the two disagree, the field number is the one that counts, and the lab run is how you investigate.
Why scores differ between tools and between runs
Run the same page through Google PageSpeed Insights twice and you may get scores a few points apart. Run it through another website performance test and the gap can be larger. This is normal. Each run meets different network conditions, server load and third party response times, and a tag that answers slowly once and quickly the next time moves the numbers.
Tools also test differently. They choose different test locations, different simulated devices and connection speeds, and different browser settings. A tool such as Pingdom speed test reports from a chosen server location and focuses on load time and request waterfalls, while PageSpeed Insights runs a Lighthouse test using a throttled mobile profile and reports Google's own scoring. Neither is wrong. They measure under different conditions, so compare results only within the same tool and settings.
The practical rule is to decide on one tool, one page and one device profile, and use it every time. Treat the overall score as a rough summary and the individual timings as the real information. A score that moves between 80 and 86 on repeat runs is stable. A score that jumps from 55 to 90 tells you something unusual happened, such as a cached page or a failed third party script.
The Core Web Vitals and their thresholds
Core Web Vitals are three measures Google uses to describe how a page feels. Largest Contentful Paint (LCP) is the time until the biggest visible element, usually a hero image or a headline, appears. Google rates it good at 2.5 seconds or less and poor above 4 seconds. Cumulative Layout Shift (CLS) measures how much content jumps around while loading, with a good score at 0.1 or lower and a poor score above 0.25. Interaction to Next Paint (INP) measures how quickly the page responds to taps and clicks, good at 200 milliseconds or less and poor above 500.
Between the good and poor limits sits a needs improvement band. Google assesses these measures at the 75th percentile of real visits, so a page passes only when at least three out of four visits meet the good threshold. A few fast visits on a good connection do not rescue the result.
Lab tools cannot measure INP directly, because it depends on real interactions. They report Total Blocking Time (TBT) instead, which adds up the time the page was too busy running scripts to respond. TBT is a proxy, so a good TBT suggests a good INP without guaranteeing it. You will also see First Contentful Paint (FCP), which marks when anything first appears, and Speed Index, which describes how quickly the visible area fills in. They are useful for diagnosis, though the three Core Web Vitals are the ones with published thresholds.
Test mobile first, then desktop
Most speed tests offer a mobile and a desktop result, and they often differ sharply. The mobile profile simulates a mid-range phone on a slower connection with a slower processor. A page that scores in the nineties on desktop can score far lower on mobile because the same scripts take much longer to run on a weaker processor.
Start with mobile for two reasons. A large share of web visits come from phones for most sites, and the mobile test is stricter, so it exposes problems that the desktop run hides. If your visitors are mostly office workers on desktop computers, check your own analytics before deciding which result matters more, and still look at both.
Read the two results next to each other. If both are poor, the page itself is heavy or the server is slow. If only mobile is poor, the cause is usually JavaScript and image size, since phones struggle most with those. If only desktop is poor, look for something specific to large screens, such as a large background video or a big slider.
What the opportunities list means and which fixes help most
Below the timings, PageSpeed Insights lists opportunities and diagnostics, each with an estimated saving. Sort your thinking by the size of the saving, and remember the estimates overlap, so removing one item shrinks the saving shown for another. The same handful of causes account for most slow pages.
Images come first. A photo straight from a camera can weigh several megabytes and be shown in a space a few hundred pixels wide. Resize it to the displayed size, serve a modern format such as WebP or AVIF, and set explicit width and height so the browser reserves space and avoids layout shift. Do not lazy load the main image at the top of the page, because that delays LCP. Next are render-blocking scripts and stylesheets, which the browser must finish before it can show anything. Defer scripts that are not needed for the first view, and remove ones you no longer use.
Unused JavaScript is the third frequent cause, especially on sites built from themes and plugins that load code for every feature on every page. Trim or defer what the page does not use. Then check server response time. If the first byte arrives slowly, everything else waits, and the usual fixes are page caching, lighter plugins or better hosting. Finally, look at third party tags such as chat widgets, ad pixels, heatmaps and fonts loaded from other domains. Each one costs time, and the list of them tends to grow unnoticed. Remove the ones nobody uses and keep the ones that earn their cost.
Get a clear read with the Page Speed Report
Running the numbers yourself works, and the free PageSpeed Insights site is a good place to start. The Page Speed Report does the same test and writes it up. It runs Google PageSpeed Insights for your page on mobile and on desktop, shows the lab numbers (LCP, CLS, TBT, FCP and Speed Index), includes the field data when Google has it for your site, shows the page weight, and lists the biggest fixes with their estimated savings. It is automated and needs only your URL, and it does not change anything on your site.
It tests one page per run, so pick the page that matters, often the home page or the page your ads point to. The report says plainly when field data does not exist for a page. Dynamic Growth has a 7-day free trial with 1 credit, so you can look at a real report before deciding to use it again.
If you send paid traffic to a landing page, speed is only one part of its job. Our landing page conversion checklist covers the rest of what to check once the page loads quickly. For a broader view of the whole site, the Marketing Audit looks at more than speed.
Test the same page the same way, every time
A speed test is only useful for comparison if the conditions stay the same. Test the same URL, on the same device profile, with the same tool. Run it three to five times and look at the middle result, which smooths out a single odd run. Test while no deploy or large content change is going on, and avoid testing a page that is not cached against one that is.
Change one thing at a time. If you compress images and remove a plugin in the same update, you will not know which one helped. Keep a simple log with the date, the change and the LCP, CLS and TBT before and after. Within a few weeks that log shows which fixes mattered on your site, which differs from site to site.
Remember the delay in field data. After a fix, the lab numbers will improve at once, while the field numbers shift gradually as new visits replace old ones in the rolling window. Judge the work on lab data first and confirm it in field data later. This step is where the technical SEO audit checklist fits in, since speed is one item among several that belong in the same review.
Stop speed regressions before visitors notice
Sites get slower mostly by accumulation. A new plugin, a larger hero image, one more marketing tag and a page builder update can each add a little, and nobody sees the total until the numbers are poor. Make speed part of the checklist for any change: test the affected page before and after, and compare to your log.
Add a regular check as well. Weekly Monitoring re-runs the Marketing Audit every 7 days on up to 5 websites and alerts you by email and in the dashboard. It covers general health, so it is not a replacement for a speed test on a page you care about. An expired certificate makes browsers show a warning before the page loads at all, so run a Security and SSL Check too, and read our post on the SSL certificate checker for how to interpret it. The wider list of what to watch is in what to check when monitoring a website.
Your next step is small. Pick your most important page, run a mobile test today, and write down the LCP, CLS and TBT. Fix the single largest item in the opportunities list, test again under the same conditions, and record the result. Do that once a month for a quarter and you will have a clear picture of what moves your numbers.
Frequently asked questions
What is a good result in a website speed test?
For Core Web Vitals, Google rates LCP good at 2.5 seconds or less, CLS good at 0.1 or less, and INP good at 200 milliseconds or less. A page passes when at least three out of four real visits meet those limits. The overall score matters less than these timings.
Why is my PageSpeed Insights score different every time?
Each run meets different network conditions, server load and third party response times, so small swings are normal. Run the same page three to five times on the same device profile and use the middle result. Compare like with like instead of chasing a single high score.
What is the difference between lab data and field data?
Lab data comes from a controlled test run by a tool, so it is repeatable and good for finding causes. Field data comes from real Chrome visitors over recent weeks and reflects what your audience experiences. Many small or new sites have no field data.
Should I test mobile or desktop first?
Start with mobile. The mobile test simulates a slower phone and connection, so it is stricter and shows problems that desktop hides. Then check desktop and read both results side by side. Check your own analytics to see which device most of your visitors use.
What usually makes a website slow?
The common causes are oversized images, scripts that block rendering, unused JavaScript from themes and plugins, a slow server response and too many third party tags. The opportunities list in a speed test ranks these by estimated saving, so start with the largest and retest.