Online Speed Testers: How to Read the Metrics

Speed scores don’t matter. They are only a compilation of what’s going on with your site according to how each online tester weights certain factors.

In fact, some scores lie, even good ones.

That’s because some of the elements flagged may not even be under your control but are likely already cached by the end user, like requests from third parties such as fonts, or because you have caching/optimization that is present, but not actually working well.

In other words, the testers can be fooled, but end users can’t.

You have to go beyond the scores of online speed testers and look into the data to see what the issues are and what makes for a good User Experience (UX), especially those metrics that impact Google’s Core Web Vitals.

See an explanation of what each online speed tester checks, what each data point means, and which metrics you need to pay attention to the most to make your site as fast and friendly as it can be.

About This Guide

This guide is a primer for site owners and webmasters who want to actually understand what speed testers are telling them.

SEE: How to Run a Site Speed Test Accurately for a tutorial on how to run the online testers.

Then refer to this post for more details on the metrics.

While it can seem somewhat daunting for a lay person, the point is to get everyone to look past just the scores and into the data that makes them up so you have a real shot at making your site faster and have a better UX for your visitors.

Need more help figuring all of this out?

My site audits include super deep checks into ALL of the speed drags on your site, 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.

About the Online Testers

There are 2 kinds of tester data:

• Lab tester – simulates what a visitor may experience.
• Field tester – data is provided from real-world site visitors using the Chrome browser

There are also two ways to test that will vary the results wildly:

• Desktop
• Mobile

While Google pays the most attention to the mobile load of a site, testing on desktop reveals far more of the issues that need to be addressed when trying to speed up your site.

If you get the desktop score up to par, the mobile will follow.

The Limitations of Online Testers

There is no single online tester that will give you the whole story.

For my site audits, I first do a deep dive into the backside of your site at the hosting level.

Site security directly impacts speed. So do bloated and resource hog plugins and themes.

Those issues are way easier to see on the backside of the host.

Plus, if you already have any speed tweaks applied, like a caching and/or optimization plugin, the testers have no way to show you the real issues so you can get them fixed. Those tweaks are masking the issues to the limit of their capacity to do so.

Plus, I use other online testers that check for the header info sent to the visitor’s browser.

Your HTTPS security headers is one such test and it will have a direct impact on your online tester scores.

And if you cheated on how you did HTTPS, meaning you had it done for free by the host and/or plugin, you’re missing all of those headers, plus you’re redirecting all links, not just the permalink, every image and other link in the post/page.

So, there’s more to the test scores than just raw speed which may need to be addressed on your site.

Which Online Speed Testers I Use and Why

I use lab and field testers and test on both desktop and mobile.

WebPage Test

WPT is my workhorse lab tester for desktop.

It shows far more data and is easier to read than any other tester, bar none.

Plus, it can run three concurrent tests and gives you the median average. Most other testers are one-off testers, meaning that you have to run them multiple times and do all of the averaging yourself. No thanks!

And, WPT also runs on HTTP/2, which is a real-world way of testing requests being delivered in parallel, meaning it’s a real test of speed the way the site’s elements are actually being delivered to the viewer.

WPT also allows you to choose the testing location and speed.

That’s crazy important for a lab tester!!!! It ensures that you can change location to avoid the tester caching the site and giving you false readings.

Google PageSpeed Insights

GPSI is my workhorse field tester for mobile.

It shows real data that is fed from the feedback of real users of the Chrome browser.

It’s also based on the Lighthouse testers. But, the data in GPSI is only a sub-set of all that Lighthouse tests, and is shifted at least once a year in accordance with how Google is currently weighting each metric.

Because it’s a field tester, the data collected reflects the device the visitor is using, plus the speed of their connection.

It also shows lab data, that simulates the connection speed of Fast 3G.

Keep in mind that mobile speed on your home wifi is WAY different than mobile speed on a 4G or LTE connection.

If your visitors are mainly coming to your site on their phone at night, they are likely on their home wifi.

So, there could be a huge difference in a tester’s mobile lab scores compared to real-world experience of your site visitors.

This is also why you have to go WAY deeper into the test results, from multiple testers, including lab testers, field testers, and your analytics, to see what’s really going on with your site speed, and why you can’t rely on just one tester.

The biggest drawback to using GPSI is that the field data may not change after every tweak you make to improve your site. Or, it may change without you making any tweaks at all.

That’s because the field data is based on real users, and that’s based on your traffic at that time, and the device they are using.

Plus, we have zero idea how often that field data is updated.

Lab data is a far better way to test when you are actively making speed tweaks to your site, as you can see those changes in real-time.

About the Metrics and Lighthouse Tester

Because Lighthouse powers the best online speed testers now, the following data points can be found in most of them.

Read more on the Lighthouse tester and Google Core Web Vitals here.

Below, I’ll cover the data points found in WebPage Test and Google PageSpeed Insights.

Perceived Speed Metrics

These are THE most important data points you need to pay attention to!

High numbers here are what make visitors leave your site due to slow load time.

And they are FAR more important than full load time, especially if you run ads on your site.

First Byte

The target for this metric is 0.5 seconds or less.

Also referred to as TTFB (Time to First Byte) and generally indicates how long it takes for the host to begin delivering the requested files.

But, the host is not always to blame for a slow first byte time – far from it!

Outside influences from request elements being loaded via 3^rd party sites can directly impact this score.

Those elements include things like Google fonts, Google analytics, ads, and more.

While host responsive time does impact page load, it’s a super bad idea to switch hosts just to get a better First Byte speed. I can make a site run faster at any host by fixing all of the other speed and security drags that impact First Byte even more than the host response time!

See the Requests and Weight section below for more on how ads can radically impact First Byte time.

Start Render

The target for this metric is 1.2 seconds or less

This is how long it takes for the first visible content to begin loading.

The first visible content could be anything on the post/page, like:

• a background image
• navigation menu
• header logo
• share buttons

It may or may not be the first image on a page/post.

It will be the first visible element in the content request order. That order can be seen in the waterfall of the tester.

First Contentful Paint – (FCP)

WPT First Contentful Paint

GPSI First Contentful Paint – Field Data

GPSI First Contentful Paint – Lab Data

The target for this metric is 1.5 seconds or less.

This metric measures the difference between when the first content begins to load to when it completes the render.

What element completes its load first is determined by multiple factors, including:

• The un-optimized request order of your theme and plugins
• The optimized request order of your theme and plugins

In other words, optimization/caching plugins, or similar measures, may reorder the requests by combing and/or deferring them.

They may also push one element through faster than the others.

In other words, an un-optimized image that is first in the load order may not complete before a share button icon lower in the order completes.

So, the natural order called out by your theme and plugins may or may not be altered, depending on what optimization you have applied to help speed things up, and what those tweaks can and can’t optimize without breaking things.

The order is also affected by the sheer number of requests near the top of the order too. Only so many items can be delivered at a time. And caching/optimization tweaks can only overcome so much.

You need to reduce the number of non-visible elements as much as possible first, and then apply speed tweaks to the rest, if you hope to achieve a good score on this, and ultimately, a fast site.

READ: Caching vs Optimization for Site Speed for more details on the differences in these two.

All 3 Scores Factor In to Perceived Speed

Combined with First Byte and Start Render, FCP is generally considered the most important part of perceived speed by the visitor, as it denotes when the visitor can begin to see anything at all on the page/post.

If they see nothing but a spinning wheel for too long – bye bye!

If they see nothing they consider significant for too long – bye bye!

So, it’s not just about the number. It’s also about what loads and ensuring it is what the visitor came to see.

How Much is Loading Matters

How many site elements are trying to load, plus how big they are also factor into raw speed.

Requests

The next most important metrics to pay attention to are:

• The total number of requests needed to load every element of the page/post
• How much those requests weigh – we’ll get to this in the next section for Bytes In

The average number of requests is 140.

That’s just for page/post elements.

If you run ads on your site, the number of requests could be 800+.

That’s a good indication that you are running too many ads and creating not only a slower loading site, but a horrible User Experience (UX) as well.

Less ads = more money

Every single one of my site audit clients who has followed this strategy is gaining:

• Site speed
• More traffic
• More traffic from repeat visitors

And all of them are making more money – like double, triple, and even quadruple income.

They are also not working as hard for that traffic, as they have so many more optins and social followers, and hence, lots more repeat visitors.

It’s more about ad placement than quantity.

There is no speed trick that overcome a site bloated with ads – none!

Some ad networks are better than others with deferring ad requests until after most of the page loads.

But even with that, having too many ads directly impacts First Byte time.

And when everything is slow right at the start, there is no chance to make up for it.

Lazy load is a great way to lower the number of requests as it will defer actually loading images that appear below the fold until a visitor scrolls to that point.

(Below the fold means where the page ends on the screen. It’s way shorter on mobile than on desktop.)

To see all of the requests loaded, see the Waterfall in WPT, and then scroll to the bottom of that page to see them listed out.

(See the tutorial on How to Run a Speed Test for details.)

Bytes In

This metric is the total weight of the page.

The target for this metric is 500 KB or less.

It is directly impacted by the number of requests and how much each of them weighs.

For example, a box of socks and a dresser are both one element. But the weight of each is radically different!!!

So, it’s not just about reducing the total number of requests. It’s also about ensuring that the ones that load first don’t weigh too much.

Un-optimized images are the biggest weight offender.

And don’t think for a minute that an image squisher plugins do a good job of fixing this – they don’t.

You want to optimize your images prior to upload.

READ: Why Squoosh is My Image Optimization Tool of Choice for more.

FYI if you want to start using Squoosh, turn off your image optimizing plugin first. You don’t want your perfectly optimized images reduced any further!!!

If you lower Requests and Bytes In, most of the other speed metrics will also become radically better.

With these 2 changes, you are effectively decreasing the total page size – smaller page, faster load.

The goal is to decrease the non-visible requests/elements “above the fold” or where the page ends prior to scrolling.

READ: How Render Blocking Above the Fold Slows page Load and Costs You Visitors for more.

Other Important Core Web Vitals Metrics

There are 2 other metrics that are important to keep visitors on your site and happy, and to ensure they don’t leave quickly.

Total Blocking Time – (TBT)

WPT Total Blocking Time

GPSI Total Blocking Time

Raw load speed is one thing.

Being able to interact with a page quickly is another.

Even when a visitor can see the page/post contents quickly, they may be very put off by not being able to click or scroll to see more of the content.

In other words, maybe the following elements are all a visitor can see on mobile:

• Logo
• Navigation
• Share buttons
• Post title
• Partial hero image (first large image in the post)

Well, none of that is your core content, which is what they came to read.

And even if all of that loaded quickly, maybe the rest of the page load is taking forever and keeping them from scrolling to see more.

That’s what Total Blocking Time measures.

It’s literally looking at what’s called the “load responsiveness” which is a fancy way of saying “I can’t interact with this page!”

One trick to speed up TBT is to use lazy load.

It literally stops most requests below the fold from loading until after the visitor scrolls to just above that point.

That way, those off-screen requests don’t have to load and cause a delay in the visitor interacting with what they can already see.

Time to Interactive – (TTI)

You can only see this in the waterfall on WPT.­­ It’s under the Details tab.

Literally, this is the delay between when you can see the page/post and when you can interact with it.

The TBT metric above is derived from the time between First Contentful Paint (FCP) and Time to Interactive (TTI).

When you fix the “render blocking above the fold” issues mentioned previous, Total Blocking Time and Time to Interactive issues will fix themselves.

First Input Delay – (FID)

Once a visitor can interact with the page, like finding something to click, or an attempt to scroll, the clock starts ticking on how long it takes the site to respond to that action.

This is what the First Input Delay measures.

It tracks the time between when an interaction happens to when the browser can actually begin to carry out that event.

That timeframe is also referred to as Input Latency and happens when the visitor’s browsers is busy processing other requests and must either complete those requests, or get to a good stopping point, before it can begin to process the new request.

Note that FID does not measure the time it takes to complete the interaction, just the delay between the requested action and the start of it being fulfilled.

Largest Contentful Paint – (LCP)

WPT Largest Contentful Paint

GPSI Largest Contentful Paint – Field Data

GPSI Largest Contentful Paint – Lab Data

Previously, we covered FCP, or First Contentful Paint, which is the metric that tracks when the first visible content completes its load, regardless of what it is.

LCP measures when the largest element on the screen becomes visible.

Likely this will be your logo image or the hero image of the post.

This could also be something like your GDPR cookie policy. Some of those things take up half the screen on mobile!

Cumulative Layout Shift – (CLS)

WPT Cumulative Layout Shift

GPSI Cumulative Layout Shift – Field Data

GPSI Cumulative Layout Shift – Lab Data

This metric is all about visual stability on mobile.

Ever have a post load on your phone and you go to click on something and the content jumped just as you clicked, making you click on the wrong thing?

Yep, that’s CLS.

And it’s a bad User Experience (UX).

And Google wants us to make it stop.

At this time, it’s super, duper hard to pin-point the source of a bad CLS score.

Pro site devs all over are complaining about the goofiness and inaccuracy of this particular test, especially across different testers.

Some GDPR cookie pop ups make it go crazy and others don’t.

Some optin pop ups don’t even register, especially those that have a long enough delay to fool the testers, but are certainly still a bad UX.

Other times, it’s just the theme rearranging itself while it tries to figure out the best display grid to use for the particular device the visitor is using. (Some phones have a super goofy height/width ratio that gives responsive themes a hard time.)

So, we are all still scratching our heads on the best way to test and identify what’s being flagged, and what should be flagged, by the testers on this one.

And I think this is going to be far more important on e-commerce sites where a jumping screen makes folks select the wrong product, or too many, or go to check out sooner than they meant to.

What I’m most interested in with this metric is to see how it does with sites running ads from different networks. Some are better than others with lazy load, and with how they handle ads that appear above the fold.

Speed Index

WPT Speed Index

GPSI Speed Index

This is not a metric that is easy to relay on for accuracy, especially between different testers, as the results are specific to the viewport size being used in the test.

So, if you are testing for desktop, it will be wildly different than when testing for mobile.

And it could even be radically different when testing on multiple mobile devices, as screen size varies so much these days.

On testers like GPSI, you have zero choice in which phone screen size it uses.

Tablet is not considered mobile, and there really aren’t many reliable tests for it, so that screen size is practically ignored.

Whereas on WPT, you can select from a variety of screen sizes to help you better calculate this metric based on the devices your visitors are actually using.