How I Actually Test Website Load Time (And Which Numbers I Ignore)

In April 2020 I ran my own site through five speed tests and wrote this post about it. GTmetrix gave wunderlandmedia.com an A (99%) PageSpeed score, a 97% YSlow score and a fully loaded time of 0.7 seconds. I was pretty pleased with myself.

Six years later, I opened that post again. One of the five tools doesn't even resolve anymore. YSlow is gone. The metric everyone obsessed over back then, First Input Delay, was retired by Google in March 2024. And the intro read like a content mill wrote it, which I'm not proud of.

So I rewrote it. This is how I test website load time now, which numbers I actually trust, and which ones I've stopped looking at.

Load Time Is the Wrong Number to Chase

That 0.7 seconds from 2020 told me when the last file finished downloading on a GTmetrix test server in London. It told me nothing about what a visitor on a mid-range phone with a patchy connection experienced. Those are two very different things, and for years I treated them as one.

Google doesn't rank you on "load time" either. It looks at Core Web Vitals, measured on real Chrome users:

• Largest Contentful Paint (LCP): when the biggest visible element (usually a hero image or headline) has rendered. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps, clicks or types. Good is 200 milliseconds or less. INP replaced First Input Delay in March 2024.
• Cumulative Layout Shift (CLS): how much the page jumps around while loading. Good is 0.1 or less.

Google takes the 75th percentile of real visits. So if three quarters of your visitors get a good experience and the slowest quarter doesn't, you're right on the edge.

The old version of this post also quoted the famous Amazon figure, that every 100 milliseconds of delay costs 1% of sales. It said "microseconds", which is off by a factor of a thousand, and the number comes from around 2006 anyway. I won't pretend a 20-year-old internal stat from a retailer predicts your bakery's contact form. Speed matters because a slow page makes people wait, and waiting people leave. You don't need a dramatic statistic for that.

Field Data Beats Lab Data, Every Time

Open PageSpeed Insights and you get two very different blocks of numbers on one page. Most people scroll straight past the top one to the big colorful score. That's backwards.

The top block is field data from the Chrome UX Report (CrUX): what real Chrome users experienced on your page over the last 28 days. The bottom block is lab data: one Lighthouse run on a simulated, throttled phone in a Google data center.

Lab data is useful for debugging because it's repeatable and tells you what to fix. But it can't measure INP at all, because nobody clicks anything during a lab run. Lighthouse shows Total Blocking Time as a stand-in, which is a hint, not the real thing.

When the two disagree, field data wins. Your visitors don't care what a simulated phone in a data center thinks.

The catch: small sites often don't have field data. If CrUX doesn't have enough visits for your page, PageSpeed Insights tells you so and you only get the lab run. That's normal for a local business with a few hundred visits a month. In that case I fall back to the origin-level data (the whole domain) if it exists, and otherwise treat the lab numbers as a rough guide, nothing more.

Step 1: PageSpeed Insights, Top Half First

Every test starts here for me, because PageSpeed Insights shows field and lab data side by side and it's the closest thing to Google's own view of your page.

I check the mobile tab first. Google indexes the mobile version of your site, and mobile is where sites fail. I read the field data for the page, then the origin, and only then scroll down to the Lighthouse part.

Since Lighthouse 13 shipped in October 2025, the bottom half looks different from what older tutorials show. Google merged the old audits like "render-blocking resources" or "properly size images" into performance insights, the same ones you see in Chrome DevTools. If a guide tells you to look for an audit name and you can't find it, that's why.

Run the test more than once, because the Lighthouse score moves a few points between runs even when nothing changed. And test your important templates as well as the homepage: one blog post, one service page, one contact page. The homepage is usually the page somebody already optimized.

Step 2: Search Console Shows You Which Pages Fail

PageSpeed Insights tests one URL. Google Search Console shows you the whole site. Its Core Web Vitals report (under Experience) groups your URLs into Good, Needs improvement and Poor, separately for mobile and desktop, using the same CrUX field data.

The useful part is the grouping. Search Console bundles similar pages together, so instead of "page 47 is slow" you see "these 80 blog posts all have an LCP problem". That almost always points to a template issue: an oversized featured image, a font loading late, a cookie banner pushing everything down. Fix the template and the whole group moves.

If your site doesn't have enough traffic per URL group, Search Console falls back to an origin group for the whole domain. Same limitation as above, just one level up.

This is part of every technical SEO check I do. It's Google's own data, and it's easy to miss.

Step 3: CrUX Vis for the History

Field data is a rolling 28-day window, and that trips people up after a fix. You compress your images on Monday, run PageSpeed Insights on Tuesday, and the field numbers barely move. Nothing is broken. The old, slow visits are still in the window.

To see whether a fix actually worked, I look at the trend. CrUX Vis is Google's tool for that. You paste in a URL or origin and get the history of LCP, INP, CLS and a few other metrics over time. It replaced the old CrUX Dashboard in Looker Studio, which Google retired at the end of November 2025. If you had that dashboard bookmarked, it's gone.

I give a change about four weeks before I judge it. Anything earlier is mostly noise.

Step 4: GTmetrix and WebPageTest When I Need to See Why

Field data tells me that a page is slow. To find out why, I need a waterfall: the list of every file the page loads, in order, with how long each one took.

GTmetrix is the friendlier option. This is the report from 2020 that I was so happy about:

Half of that screenshot doesn't exist anymore. GTmetrix dropped the PageSpeed and YSlow scores and runs on Lighthouse now, so you get a GTmetrix Grade plus Web Vitals. With a free account you can pick the test location (the default is Vancouver) and the connection speed. Pick a location close to your actual visitors. A German site tested from Canada will look slower than it is.

WebPageTest, now run by Catchpoint, is what I open when GTmetrix isn't enough. It needs a free account these days and the interface is busier, but the filmstrip view is the most useful thing in this whole post. It shows screenshots of what the visitor sees at each moment of the load. If a site "feels slow", the filmstrip shows you where: a blank white screen for a second, then a hero image that pops in late.

Step 5: Chrome DevTools for INP

INP is the metric lab tools struggle with, because it depends on someone interacting with the page. So I test it by hand.

Open Chrome DevTools, go to the Performance panel, and you land on Live metrics: your local LCP, CLS and INP, updating as you use the page. Click the menu, open the accordion, type into the search field, add something to the cart. Every interaction updates the INP number. You can also switch on CrUX field data in the same panel and compare your local values to what real users get.

Your laptop is probably much faster than your visitors' phones, so turn on CPU throttling in that panel before you trust a good INP number. A heavy JavaScript handler that takes 50 milliseconds on a MacBook can take several times that on a budget Android phone.

What Happened to the Other Tools From 2020

The original post recommended Sucuri's load time tester. This is the result it gave me back then:

That domain, performance.sucuri.net, doesn't resolve anymore when I try it today. Tools die, which is one more reason to build your routine on Google's own data and not on whichever free tester ranks for "speed test" this year.

The screenshot still teaches something, though. Time to first byte was under 0.2 seconds from Frankfurt and over 1.3 seconds from São Paulo. Same site, same minute. Where you test from changes the result more than most optimizations do.

Pingdom's free speed test is still online. This was its result in 2020, tested from Frankfurt:

Performance grade 88, 607 milliseconds, 796.4 KB, 19 requests. The GTmetrix run 19 days earlier said 392 KB and 11 requests. I don't know if I added things to the homepage in between or if the two tools counted differently, because I didn't write it down. If you compare numbers, compare them from the same tool, same location, same settings, and keep a note of what changed. Uptrends' free test is also still online. Neither of the two made it into my routine.

The Numbers I Ignore

After all of this, a few numbers no longer get my attention:

• Fully loaded time. It waits for every tracking pixel and chat widget to finish. Visitors don't.
• Grades and letter scores from third-party tools. An A in GTmetrix and a B in Pingdom on the same day tell you about their scoring formulas, not about your visitors.
• A Lighthouse run on desktop from your office. Gigabit fiber and a fast laptop will flatter almost any site. I made this point in my Astro vs WordPress performance comparison too: measure field data, not a lab run on your own connection.
• Chasing 100/100. Going from 92 to 100 in Lighthouse is often hours of work for a change no visitor will notice. If your field data passes Core Web Vitals, spend that time on content.

What I Do After the Test

Testing is only half the job. On the small business sites I see, it's usually oversized images and plugins or scripts nobody uses, made worse by cheap hosting. I wrote about those in the boring fixes that beat a redesign. If you're on WordPress, a good caching plugin covers a lot of it; my FlyingPress review goes into what that looks like.

My routine fits on a sticky note: PageSpeed Insights field data first, Search Console for the whole site, CrUX Vis for the trend, GTmetrix or WebPageTest for the waterfall, DevTools for INP. Then fix one thing, wait four weeks, look again.

I can't promise you a perfect score, and I don't think you need one. What I can do is test your site properly, tell you which fix will move your real-user numbers and which ones are cosmetic, and build or rebuild it with speed in mind from the start. Let's talk if your site feels slower than it should.