You run a speed test, get a score, and still don’t know if your site is actually fast. That’s normal. Different tools measure different things, report different numbers, and disagree with each other on purpose. Here’s how to test your site properly in 2026 and which number to actually act on.
Why do different speed tests give different scores?
Every speed tool falls into one of two buckets, and mixing them up is the most common reason two reports contradict each other.
Lab data comes from a single simulated test run under controlled conditions: a fixed device, a fixed connection speed, one visit. Tools like GTmetrix and the lab section of PageSpeed Insights use lab data. It’s repeatable and great for debugging a specific page, but it’s not what your real visitors experience.
Field data comes from actual people loading your actual pages on their actual phones, over their actual wifi or cell signal, collected by Google over a rolling 28-day window. This is the Chrome User Experience Report (CrUX), and it’s what shows up in Search Console’s Core Web Vitals report and in the field section of PageSpeed Insights.
Google uses field data, not lab data, to judge your Core Web Vitals for ranking. A page can score 95 in a lab test and still fail its real-world Core Web Vitals if your actual visitors are mostly on older phones or slower connections than the lab simulates. If the two disagree, trust the field data.
Which tool should you start with?
Google PageSpeed Insights is the right first stop for most small business sites. Go to the tool, enter your URL, and you get both lab and field data on one report, ranked by impact. It tells you your Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), the three Core Web Vitals, plus a list of specific opportunities like “reduce unused JavaScript” or “serve images in next-gen formats.” Test your homepage and your two or three highest-traffic pages, since scores vary page to page.
Search Console’s Core Web Vitals report is the tool for the site-wide view. It groups your pages by similar URL patterns (all your blog posts together, all your product pages together) and shows how many pass, need improvement, or fail, based on 28 days of real visitor data. This is where you catch a problem affecting dozens of pages at once, like a slow template used sitewide, instead of testing one URL at a time.
GTmetrix is worth adding when you need to see why a page is slow, not just that it is. It shows a waterfall chart of every file the page loads, in order, so you can see exactly which script or image is holding things up. It’s lab data only, so use it for diagnosis, then confirm the fix worked with real field data afterward.
WebPageTest is the deepest option, letting you test from specific cities, on specific devices, over throttled connections that mimic 4G. Most small business sites don’t need this level of detail, but it’s useful if you serve customers across very different regions or want to see the mobile experience on an older Android device specifically.
What do “Good,” “Needs improvement,” and “Poor” actually mean?
Core Web Vitals scores your site against three thresholds, judged at the 75th percentile of visits, meaning three out of every four page loads need to clear the bar for it to count as “Good.”
- LCP (loading): 2.5 seconds or less is good. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.
- INP (interactivity): 200 milliseconds or less is good. Between 200 and 500 milliseconds needs improvement. Over 500 milliseconds is poor. INP replaced First Input Delay in 2024 and is the metric most sites fail, since it grades how the page responds to every tap and click, not just the first one.
- CLS (visual stability): 0.1 or less is good. Between 0.1 and 0.25 needs improvement. Over 0.25 is poor. This tracks how much content jumps around as the page finishes loading, like a button shifting right as an ad loads in beside it.
A page needs to pass all three to count as “Good” overall. Passing two out of three still shows up as a problem in Search Console.
How often should you actually check?
Once a month is enough for most small business sites, plus a check any time you launch a redesign, switch hosting, or add a new plugin or app to your store. Search Console’s field data updates on a rolling basis, so changes you make today won’t show results in that report for a few weeks. Use PageSpeed Insights or GTmetrix right after a change to confirm the fix worked in lab conditions, then check back in Search Console a month later to see if it moved the real-world numbers.
If you’re on WordPress and keep seeing the same problems show up test after test, the cause is usually hosting, plugins, or the page builder itself. We’ve covered the specific causes and fixes for a slow WordPress site in more detail.
What should you do with the results?
Don’t chase a perfect 100. Chase passing Core Web Vitals in the field data, since that’s the number tied to ranking and to AI search citations. A site sitting at 85 to 95 with all three metrics green in Search Console is doing its job. If your reports keep flagging the same large images, unused JavaScript, or a slow server response, those are the three issues worth fixing first, and they cover most of what separates a fast site from a slow one. For the full picture of why this matters beyond the score itself, see our breakdown of why fast websites win in 2026.
If your numbers aren’t moving no matter what you try, the site itself may be the bottleneck rather than any one setting. Our web design and development team builds sites around Core Web Vitals from the start, for businesses across Guelph, Kitchener-Waterloo, and the wider GTA. Get in touch if you want a second set of eyes on your report.
Join the conversation
Be the first to comment.