Site speed is arguably one of the most important metrics for any website — for some sites, the difference of a single second can add up to thousands of dollars of missed (or gained) revenue. This makes accurately measuring site speed crucial. Unfortunately, site speed isn’t a particularly easy metric to measure. In this article, I’ll show you how to use one of the most popular tools available, GTMetrix, to effectively gauge a website’s speed.

Speed Test Considerations

Many tools — like the aforementioned GTMetrix — are great, but pretty useless if all you do is a one-off speed check. Many factors need to be taken into account if you want to effectively test for speed, but one of the biggest is this: Speed tests need to be done multiple times and averages taken for the results to have any real meaning.

1. Number Of Tests

To get a really good comprehensive set of data, you need to do a whole lot of speed tests, preferably at different times throughout the day. The ideal would be to schedule an hourly test and leave it running for about a week or so.

The reason for this is that your website’s performance will change throughout the day, depending on your visitor count or even the usage of your server box if you are on a shared host.

A nice side-effect of this test is that you will see your peak hours — which could potentially indicate the best time for you to post new content or target ads/popups, etc, to your visitors.

That said, there’s still plenty to be learned by doing just five or ten tests over the course of an hour or so. Although the actual load speed given in seconds may change over the course of a day (or even week), some of the things GTMetrix can reveal — such as many of the recommendations it will yield on how to go about speeding up your website — will not change with time at all.

2. Test Locations

When you use free versions of many speed testing tools (such as Pingdom), you’re usually assigned a test server randomly (i.e., the location from which your site is being tested will be random). This can often lead to extremely inconsistent results. While Test 1 may be performed from New York, for example — 100 miles away from your server — Test 2 could be performed from Sydney, 10,000 miles away from your server.

The location you choose to test your site from makes a big difference. For some projects (like local businesses), it may be fine to discard data from locations far away, but in other cases (think sites with a potentially worldwide audience) you’ll want to test globally.

To test locally, select test servers that are near the physical location of your server. If you don’t know where your server is located, ask the hosting company you use to host your website.

To test globally, pick four or five testing servers in key locations around the world. Personally, I like to choose at least one server from the US, one from Europe, one from Australia, and one from Asia.

In order to be able to choose the location from which to test your site from using GTMetrix, you’ll need to register for a free account and login.

3. Test Targets

I often see people testing ONLY their homepage. This is an absolutely beginner’s mistake that can skew things a lot more than you might think. First of all, your homepage may be the least data-intensive page on your site, making it naturally the fastest.

Your homepage may also not be as important as you’d like to think. I worked on a site that acquired 97% of its traffic organically through search engines, almost all of which went to single posts/pages — so be sure to focus on more than just your homepage!

In short: the speed of your homepage is of course important, but may be secondary to many of your other pages, so be sure to also test as a number of other pages. Test pages like single post pages, store pages and product pages, etc, to get a well-rounded set of results.

How GTMetrix Works

Basic use of GTMetrix is free. You can go to the main page and start analyzing your site right away. A registered (or even paid account) gives you more options, such as allowing you to choose testing locations, automate testing and more.

GTMetrix Speed Test

The results overview shows you the browser and location used for testing, PageSpeed and YSlow scores, page load time, number of requests and total page size. These are great for analyzing trends, but if you really want to know why your website is slow, and/or what can be done to further improve things, you’ll need to dig deeper.

PageSpeed And YSlow

PageSpeed and YSlow offer two slightly different methodologies of gauging how a website’s structure and mechanics impact its speed. The results of these contain their own recommendations for making things faster — such as caching, adding expires headers, minifying assets, enabling gzip compression and the like.

The corresponding sections in GTMetrix each link to further information on the topic — so you can read more deeply about it and learn exactly what to do to implement each specific speed increasing method listed.

YSlow Test Information

A key point to note: Don’t chase percentage scores. These can be misleading and don’t necessarily take into account absolutely everything that’s important, like the overall size in megabytes of the page (which, incidentally, is often highly influenced by poorly optimized images). Instead, emphasize the actual page load speed given in seconds — aiming to shave seconds off this (and the ‘critical rendering path’ — more on this below) should be the real goal!

The Waterfall

The waterfall is one of the most useful tools for pinpointing bottlenecks in your website’s speed. This particular view is actually very similar to what you may see in browser-based tools, such as the Firebug Net Panel. For more information, take a quick look at this excellent article on how to read waterfalls. If you’re short on time, here’s the nutshell version:

Each asset on your site needs to be looked up, transferred and displayed. Each bar in the waterfall shows all the steps involved for each asset and how long they took.

GTMetrix Waterfall View

The steps that each asset can go through are as follows, with a little explanation added:

  • DNS Lookup: Time to resolve the DNS
  • Connecting: Time taken to create a connection
  • Blocking: Time spent in the browser queue waiting for a connection
  • Sending: Time taken to send the request
  • Waiting: Time spent waiting for the response (time to first byte)
  • Receiving: Time taken to download content

Based on this information we can make some assumptions about what’s going on with our website. First of all, take a look at that blue line in the waterfall above. It represents the point at which the DOM was loaded. The red line represents the time the page was loaded.

The time to first byte (TTFB) is also considered an important indicator of your server speed. This is shown by the waiting information in the waterfall. If you’re consistently seeing a high TTFB (even after going through and improving the main recommendations for improving site speed), it may be that your host server is what’s letting you down!

Video And History

The last two sections are for premium accounts only. The video shows an actual recording of the site loading — which can show you what all this different data actually amount to. While it’s a nice feature, I don’t find myself using it a whole lot as it is, truth be told, a bit gimmicky, in my opinion.

The history tab, however, really is one of the best features because it allows you to view the results of multiple tests on one page in an easy-to-understand, handy graph.

GTMetrix Historical Monitoring Results

Configuring A Test Suite

I personally have a pro account with GTMetrix, which I use mostly for testing both my own sites and specific technologies of interest.

One downside of GTMetrix (although I have yet to come across any tool that can do this anyhow) is that it cannot set up variable tests. What I mean by this is that you can’t tell GTMetrix to choose a random page from a given set and test it from a random location. This would give us a graph that could drill down even further, based on page and location (something for the future perhaps?).

An alternative would be to specify both some pages and locations and test all variations every hour. This is, admittedly, pretty resource intensive — but would give us a great dataset to work with. As it stands, you can do this manually and use the GTMetrix compare feature to analyze your results.

To begin with, I create all the different tests I need. If I wanted to test 2 pages from 3 locations, I would set up tests for all permutations — which would result in 6 tests. I would then monitor each hourly test for at least a couple of days, ideally a week.

Once a satisfactory amount of time has passed, I go into my dashboard, select all tests and compare them. This results in side-by-side data and aggregate graphs.

Comparing GTMetrix Results

Speed Tips For WordPress Users

Oh, and if you’re using WordPress (the subject this site is, of course, primarily all about) and happen to be looking for some quick fixes to speed things up: here’s a few very effective tips that almost all WordPress-powered websites could benefit from:

  • 1. Ensure whatever web host you’re using uses server’s that are optimized specifically for WordPress — and if you’re still using generic, non-WordPress-optimized shared hosting, switch to something much, much faster, like a web hosting plan from WP Engine, Flywheel or Kinsta.
  • 2. If you aren’t already, start using a page caching plugin, such as W3 Total Cache, WP Super Cache or WP Rocket.
  • 3. Take some time to go through your site’s images and ensure they’re all as optimized as they can be (either re-optimize them in a program like Photoshop or consider using a specialist service/plugin like WP Smush).
  • 4. Ensure your website is loading as much of its JavaScript as possible at the bottom of its pages (rather than at the top where it will be delaying the loading of all other page elements).
  • 5. As painful as it may be: remove any unnecessary social media profiles from loading on your page (such as Facebook, Twitter and Google+ profiles — all of which can quite literally add seconds to your page load times).
  • 6. Enable gzip compression, minify all scripts and leverage browser caching wherever possible.
  • and 7. Perhaps most important of all: Remove every unnecessary plugin that may be loading all manner of CSS and JavaScript files within your pages — although there is technically no limit to the number of plugins you can install on a WordPress-powered website, a very general rule of thumb is: the more plugins, the slower the site!

– Any other super-effective quick fixes? Feel free to leave them in the comments below! 😉

GTMetrix As A Monitoring Tool

So far we’ve been largely focusing on GTMetrix as a way to figure out what should be improved on a site to make it faster. Using the alerts feature, however, you can also detect (and report) any instances your site slows down below a predefined speed.

Setting Up Alerts

You can set a number of conditions from page loading times and YSlow score to HTML size — which makes for a pretty well-rounded system. If any of your preset conditions are met, you’ll receive an email right away, allowing you to act on the information to rectify any issues.

By monitoring your website, you may not be able to prevent slowness completely, but you will, at least, then have the opportunity to quickly react to any problems in order to minimize the damage done by, say, an unexpected traffic surge.

Where GTMetrix Falls Short

On the whole, I rather like GTMetrix, and choose to use it above all other speed-testing tools for measuring and keeping track of my own sites. This doesn’t, however, mean that everything about it is perfect. One of my biggest issues with GTMetrix is that it doesn’t offer variable testing, which would be a huge time saver — something I would gladly pay a little extra for since this would trim quite a bit of time off of my testing procedures.

Another area of focus could be stressing how important it is to use a high-quality host. By detecting and displaying the various hosts users are using, speeds could be compared and better hosts suggested for certain users. The TTFB could also be monitored, and suggestions for faster hosts displayed when this value is particularly high.

A few notes about the critical rendering paths could — and in my opinion should — also be added. While this one is perceptual, many factors can be detected, such as many JS/CSS files being needlessly loaded early on in the page (an absolutely key consideration by the way). Optimizing the critical rendering path will lead to your website actually appearing on the user’s screen a lot faster — even if the ‘overall’ page load speed is still quite high!


If you want a fast website, you’ll need a comprehensive tool to test it under a number of circumstances. GTMetrix lets you do exactly this: by monitoring a URL hourly, and from different locations, it will give you a complete picture of how your website performs.

Used properly in the battle against slow site speeds, GTMetrix will equip you with more than enough information to fight back. Just remember to test more than only your homepage, to test each page more than once, and from multiple locations, and to keep the focus on actually reducing those load times rather than on maximizing the PageSpeed and YSlow percentage scores!

Know of any other/better ways of measuring a website’s speed? Thoughts?


Leave a Reply