How to Run a Site Speed Test Accurately

Discover how to test the page load speed of your site and where to find data in the testers to pin point what the problems are.

About the Metrics

This tutorial is a primer on how to run the testers shown accurately and where to find the helpful data they give you.

READ: Online Speed Testers: How to Read the Metrics for more details on how to interpret your test results.

What to Test

I usually test a typical blog post instead of the home page, as posts generally load more of the plugins, widgets, and ads, if they are in use.

That will allow you to see more of the speed issues on the site.

About the Testers

The two online speed testers I rely on the most are:

• WebPage Test – set for desktop lab testing
• Google PageSpeed Insights – for mobile field and lab testing

Both testers also include Google’s Core Web Vitals metrics.

A Lab Tester gives you a simulated user experience.

A Field Tester gives you actual user experience from folks visiting your site using the Chrome browser. If you don’t have enough traffic for accurate field results, you’ll get lab results returned.

You may wonder why I bother to run a desktop test when Google tests for mobile-first indexing.

That’s because the desktop version loads more site elements and I can see, and fix, more issues.

Some of those issues actually impact the mobile score too, you just can’t see them on mobile testers.

The Limitation of Online Testers

WebPage Test (WPT) and Google PageSpeed Insights (GPSI) are not the only testers I use.

A few other important ones are:

• WebsitePulse – for a header info the visitor’s browser reads
• Security Headers – for the HTTPS security headers Chrome now requires

Plus, if you already have caching/optimization tweaks on the site when you run the tests, you are not going to see all of the issues that need fixing.

What you will see is the limitation of what those speed tweaks can overcome.

It’s far better to turn those tweaks off, run the tests, fix all of the speed drags you can, and then add the tweaks to take it the rest of the way.

Need More Speed Help?

Speed testers can’t show you all of the speed drags on your site.

Security and performance go hand in hand these days.

Plus, plugins can be hogs for hosting resources as they run and/or clog up your database, all of which will also make your site run slower.

My site audits include super deep checks into ALL of the speed drags on your site at the host root level, not just what the online testers tell us. And we go over that report in non-geek speak so you can fully understand all of it too.

My Webmaster Training course teaches pro designers and SEOs the technical aspects of speeding up a site, including access to deep case studies, real-world audits, and so much more.

---

Subscribe to BlogAid on YouTube

Find this tutorial helpful?

Subscribe to BlogAid on YouTube for more of them!

---

Video

Written tutorial highlights are below the video too.

Tutorial Highlights

Here’s a quick look at the post we will be using in this tutorial.

It’s on my Heartwood Art woodworking site.

And I removed a couple of the optimization tweaks I use so we can see some of the new Core Web Vitals data that gets flagged.

WebPage Test Tutorial

Go to WebPage Test

Input the URL of one of your typical blog posts.

Set the Test Location by clicking the drop-down.

Scroll past the mobile testers to the continent where most of your traffic comes from.

For the U.S. I find that the Lincoln Nebraska location is the most accurate.

If that is unavailable or has a long queue, then try Dallas, Denver, or Chicago.

Whatever you choose, be sure it has the Chrome browser listed.

Set the browser to Chrome.

Click the down arrow for Advanced Settings.

Set the Connection speed to Cable, as this will emulate a typical home wifi connection.

Set the Number of tests to Run to 3.

This is where WPT excels over other one-off testers, as it can run multiple concurrent tests and give you a median average.

With all other lab testers, you have to run 3 individual tests and do all of the averaging yourself. No thanks!

Set the Repeat View to First View and Repeat View so you can see how well your caching is working on the second view.

Turn off the Capture Video.

Click the Start Test button and go make a cup of coffee. It will take time for the tester to run.

When the test completes, you’ll see the composite scores in the top left.

Don’t pay too much attention to those, as they can lie, even the good ones.

Check the metrics for the real story.

I’ll cover a few of the super important ones here.

Be sure to see my guide for Online Speed Testers: How to Read the Metrics for more details on each one, especially the new ones for Google’s Core Web Vitals.

The first metric to pay attention to is the First Byte. This is how long it takes for your site elements to start delivering to the visitor’s browser.

You want to shoot for .5s or less.

The next metric to check is Start Render.

This is when a visitor can start seeing something.

You want this to be under 1.5s.

The First Contentful Paint is how long the first thing a visitor can see fully loads.

You want this as close to 1s as possible.

Total Blocking Time is derived from First Contentful Paint and Time to Interactive, which you can only see in the waterfall of this tester. We’ll get to that in a moment.

You want to keep this one as low as it can go. As you can see, this particular post is taking a little too long to become interactive, in the opinion of this lab tester.

The next two major data points are the number of Requests and Bytes In, which is how much those requests weigh.

The average number of requests is 140.

If you run ads on your site, the requests could well exceed 800.

For the weight, you want to keep this as at 500 KB or lower.

To see the site elements that are making up all of these data points, there are a couple of places you can go in this tester.

The median run shown here is Test #3

Click that link to see the waterfall of that test result.

Then click the actual waterfall thumbnail.

Scroll down to see the actual requests loading.

Pay attention to the colors.

• Gold for JS – JavaScript
• Green for CSS – Cascading Style Sheets
• Violet for Images

You want as little green and gold at the top as you can get.

This is why you need to fix your theme and plugin issues before applying optimization tweaks, and why you want to run this tester without those tweaks so you can see the actual requests.

The site I used for this tutorial has been fully optimized, and is why you see so few requests.

There are actually about 90 requests.

This is what proper fixes and optimization can do for you.

The green line is when the visitor can see something render and the lavender is when they can interact with the page.

The fun thing about seeing this test live is that you can click on any of the requests to see what it is.

If I click on this first image, you can see the path to it and the file name.

If I click on Object, I can see the actual image.

The Object will only display for images, not the other request types.

There’s lots to reading a waterfall, and well beyond this tutorial.

Scroll to just below the waterfall.

And click the View all Images link.

This will show you all of the images that are loading, and their order, plus their request number.

It will also let you know if you could have possibly optimized the file size more.

I can’t on any of these hero images with the red background, as it pixilates around the white fonts if I compress it anymore.

Scroll down and have a look at just how many images are loading.

Most site owners only think about the images in their post, but the logo and everything in the sidebar or footer, plus gravatars, or popular posts and such could all be loading too.

There are actually about 20 images in this post, but lazy load has kept all of the ones below the fold from loading.

Use your browser’s back button to return to the waterfall.

Next, scroll all the way to near the bottom of the page.

Here you’ll see the Request Headers section.

It’s a lot easier to read through the actual requests here than in the waterfall.

They are in the same order as the waterfall.

This is a great place to see just how many requests are made by your theme and plugins too, as well as how many fonts your theme and plugins are pulling in from third party sites like Google. You can’t cache those and they may be bringing down your cache score. That’s part of how those composite scores lie to you. And if you use common Google fonts, they are likely already cached in the visitor’s browser.

Scroll back to the top.

And click the Performance Review tab.

This shows you what makes up that Cache Static composite score.

The caching in the first 2 columns comes from your host.

The next two columns show how well you are doing with your image compression.

The next column for Cache Static only detects if browser caching is enabled. It does not check to see how well it is working. So this is another way even a good score could lie to you.

You’ll also see some red Xs for elements that can’t be cached, like Google Analytics.

The last column detects whether a CDN, or Content Delivery Network is in use.

If you are using a CDN like Cloudflare, all of this should be green.

You’ll also see green for third party requests, like Google Fonts.

Scroll back to the top.

And click the Content Breakdown tab.

Here you can see a tally of all your requests and just how cumulative heavy they are for weight.

It’s likely that your highest request tally will be for images, JS, and perhaps CSS.

On the right you can see their original weight and then their compressed, or optimized weight.

It’s likely that images will be the bulk of the weight, and likely JS will be next.

Keep in mind that if you run ads, all of those factor into your total number of images and JS too.

So, you may want to ask your ad agency for their trick to run this test without ads.

It won’t be 100% accurate, and will still have some ad code and requests. But, it will be enough for you to get an idea of how your base site is doing.

Okay, that’s the overview of WebPage Test.

Let’s move on to Google PageSpeed Insights.

Go to Google PageSpeed Insights.

Input the URL of the post you want to test.

Click the Analyze Button.

Google PageSpeed Insights runs on the Lighthouse tester, which is an open-source independent tester that powers many online speed testers now.

Every one of those testers pulls out metrics from the huge array of elements that Lighthouse tests, and it weights them in accordance with what it considers to be the most important factors you should pay attention to.

The score is just a composite of the metrics GPSI is using, and the importance it gives to each one at this time.

Google regularly shifts what it considers important. So, you could run this same test 3-4 months from now and get a different score without having changed anything.

Another reason why your score could vary radically is that this data is half and half Field Data and Lab Data.

The Field Data is based on the CRUX report, which is a compilation of feedback from visitors who have actually gone to your site using the Chrome browser. It’s tracking their device, connection speed, screen size and more.

So, part of this score is based on the traffic you have at the time you run the test.

You may also not see the needle move much on your score here as you improve your site because it will be a while before that CRUX test data is updated.

Another issue is that the Lab Data is simulated and we have zero idea of where the tester is located, and we can’t change that location or test speed. It defaults to Fast 3G and a Moto phone size, last I read.

That also means that the more you run the same URL in this tester, the more likely it will eventually cache your page.

So, the next time you run it, the Lab data could improve even though you’ve made no tweaks to the site.

All of these reasons make it an unreliable tester for improving your speed.

You should see immediate results in WebPage Test as you tweak.

But let’s see what this tester does show us.

First, it’s a mobile load, and you may or may not have a separate cache for mobile. So be sure to turn that off before you run the test so you can see the base issues.

Mobile also loads far less than desktop. You may or may not even be able to see the first hero image of your post. That’s another reason why these metrics vary so wildly from WPT.

Okay, let’s go over the Field Data.

Now, if you don’t have enough traffic gathered by Chrome to give you actual field metrics, it will give you lab data here too.

The first thing is the First Contentful Paint, which is when the very first element has loaded.

Scroll down and you can see that in the video strip of images that were taken during the load.

You want the majority of your post to display within the first 3 rectangles.

Now, the field data tells you percentages of this post that determine how much of it is okay and how much of it needs work. It would be nice if they would give you some details so you could fix it, huh?

You’ll also see First Contentful Paint listed in the Lab Data section, which simulates what visitors will encounter, and you can see that it is completely different from what the field data shows. Again, they don’t really tell you what the exact problem is if you have a bad score to fix that one thing.

Next we have the First Input Delay.

Once enough of your page has loaded for a visitor to interact with it, like clicking something or scrolling, the First Input Delay measures the difference in the time the visitor started that interaction to the time the request started processing.

In other words, if the visitor attempted to scroll, and the page did not move, that would be a long First Input Delay, and that would be bad.

Next we have the Largest Contentful Paint. And you’ll see that in the Lab Data too.

This is specifically when the largest content on the page becomes visible. This will vary by whether your post’s hero image can be seen or not, which is a good reason why to start your post with content followed by the images, as it pushes that down.

Next we have Cumulative Layout Shift and this you have to view in the little thumbnails for how the content might jump around as things load.

Scroll down to the Opportunities section and this is where you can get a few more details on site elements that need to be addressed.

What you see will be entirely dependent on what’s wrong with your site and the different speed tweaks you may have implemented.

You can click on each call out to get more details on the things being flagged.

Scroll down to the Diagnostics area.

And it works the same as the Opportunities area with listing out the issues on your site.

And you can click each of them to find the causes.

Some of them will be rather criptic.

And if you run ads on your site, some of the numbers will be huge.

The last section lists the audits the post passed.

There are 21 in all, that I know of.

Click on it to see details.

But it’s pretty much useless info.

What would be helpful would be a list of what audits didn’t pass and why.

You kind of have to pick out and kluge together that info from the metrics above.

And now you know why WebPage Test is my workhorse.

When you get everything working there, all of the GPSI scores will improve radically too.

Wrap Up

I hope you’ve enjoyed this overview of how to run two of the most popular online speed testers.

Be sure to visit BlogAid.net for more speed help with your site, including a full site audit and report that we go over live to help you sort through this data and understand it so you can make good decisions about your site changes.