Today we want to dive into how to better use and understand the data from the popular website speed test tool Pingdom. You can use it to do what we call a waterfall analysis of your WordPress website. This can help you quickly diagnose performance issues, and also not misdiagnose a problem.
A lot of times we see WordPress users interpreting the data wrong in the Pingdom speed test tool, and this leads to sometimes configuring a website to a state even worse than before. Remember that all tools like this are to be used as guides, they are never 100% accurate. The important thing is to be consistent and use the same tool throughout all your tests.
Pingdom is a company based out of Sweden (now owned by SolarWinds) that offers a variety of different services, such as uptime monitoring, page speed monitoring, transaction monitoring, server monitoring, and visitor insights (RUM). Probably one of the things they are most well known for is their free website speed test tool. It is one of the most popular performance testing tools in the WordPress community.
Still looking for that perfect WordPress host?
Why is it so popular? Well, for one, it’s probably the easiest speed testing tool to use! Not everyone is a web performance expert, and so for the typical WordPress user, some of the other alternative tools out there can be quite overwhelming. Sometimes less is more as they say. After all, you just care about two things: how fast is your website and how can you make it faster.
Pingdom currently allows you to test the speed of any website from 7 different locations (5 continents) strategically placed around the globe:
- Asia – Japan – Tokyo
- Europe – Germany – Frankfurt
- Europe – United Kingdom – London
- North America – USA – Washington D.C.
- North America – USA – San Fransisco
- Pacific – Australia – Sydney
- South America – Brazil – São Paulo
Note: We’ve noticed that occasionally not all the test locations will be available. This is most likely because it has gone down for maintenance or it got overloaded with too many people trying to run tests on it. If a test site location that you’ve been using is no longer there, check back in an hour or two. Most likely it will reappear.
The testing location you choose is actually very important as it relates to the physical location of where your website is actually hosted. This is where a little thing called network latency comes into play. But we’ll get into this in more detail below.
Waterfall Analysis with the Pingdom Speed Test Tool
Below we are going to break up each Pingdom section and explain in more detail what the information means as it pertains to the overall performance of your website and how to do a waterfall analysis.
- Pingdom Summary
- Performance Insights
- Response Codes
- Content size and requests by content type
- Content size and requests by domain
- Waterfall Chart
- Case Study Domain Configuration
When you run your WordPress website through Pingdom it generates a performance grade, a total load time, the total page size, and the number of requests you have on your website. In our example, we are using perfmatters.io, an ecommerce site running Easy Digital Downloads. It’s hosted on Kinsta’s blazing fast servers.
As you can see we ran our first test and we scored an 88/100 on Pingdom and the total load time is 541 ms. It lets us know the total size of our combined assets and the number of requests.
We then ran an additional test and now our total load time is 392 ms with the same page size and number of requests! What is that all about? You might notice this if you are running your website through the Pingdom speed test tool multiple times. Larger sites will notice even greater differences.
There are three main reasons why happens: DNS caching, CDN caching, and WordPress caching. This is why you should always run tests multiple times. Of course, external calls to third-party resources and APIs could also impact this. Find out why further below in our waterfall analysis.
Want to get a better Pingdom score on your WordPress website? Depending on your site and configuration it might not always be possible to score a perfect 100/100, especially for those of you running ecommerce sites and marketing pixels. But simply spending some time on improving your score is a good place to start. The overall speed is really what’s important.
Sometimes the user experience might also trump some of the web performance tricks you read around the web. You can’t forget the user experience! But rest assured, we will be sharing with you some tips and tricks further below on how we got the above site to where it is, so keep reading.
The performance insights section of the Pingdom speed test tool was removed in 2018 and is no longer available. This is most likely because some of the suggestions they were reporting are no longer as relevant as they used to be. When it comes to web performance optimizations, things are always changing. Also, this section probably caused more harm than good with people trying to chase after the perfect Pingdom score.
However, we are leaving this section in our post because it’s important to understand how these scores are calculated. These are essentially all based on the Google PageSpeed Insight rules. Generally, if you improve these on your site, you should see a decrease in your overall load times.
Here are a few of the categories that the performance insights section used to be made up of:
- Avoid Bad Requests
- Minimize Redirects
- Leverage Browser Caching
- Minimize Redirects
- Remove Query Strings From Static Resources
- Serve Static Content From a Cookieless Domain
- Parallelize Downloads Across Hostnames
- Specify a Cache Validator
- Specify a Vary: Accept-Encoding header
Now let’s dive into some of these and see which ones are still relevant today.
Avoid Bad Requests
Avoiding bad requests is always relevant! This warning is just like it sounds, it’s a request that could not be completed successfully. This typically happens you manually link to an asset or image which has since been deleted, resulting in a 404 error. This shows up as an orange circle in Pingdom, along with a 404 on the response header status.
Always make sure every request on your site returns with success status. This will ensure there aren’t any queries being generated to assets which no longer exist.
Too many redirects are always something you need to watch out for. Simple redirects like a single 301 redirect, HTTP to HTTPS, or www to non-www (vice versa) are fine. And a lot of times these are needed in certain areas of your website. However, each has a cost on your site’s performance. And if you start stacking redirects on top of each other, it’s important to realize how they impact your site’s performance. This applies to page and post redirects, image redirects, everything.
A redirect shows up as a blue circle in Pingdom, along with a 301 or 302 on the response header status.
Minimize redirects in PingdomHow much do redirects impact your site? Let’s do a little test. First, we run a speed test on our contact us page:
https://perfmatters.io/contact/. As you can see below we get a total load time of 417 ms.
We then modify the URL slightly and run another speed test to see the impact of multiple redirects.
http://www.perfmatters.io/contact. As you can see, the same page now takes 695 ms to load. That’s an increase of 66%. Yikes!
Check out our in-depth post on WordPress redirects, and the best practices for faster performance.
Leverage Browser Caching
A very common warning people struggle with is leverage browser caching. To put it in laymen’s terms, every script on your WordPress site needs to have an HTTP cache header attached to it (or it should). This determines when the cache on the file expires. To fix this, ensure your WordPress host has the proper
cache-control headers and
expires headers setup. Kinsta has these headers in place on all of our servers. Check out the steps on how to add caching headers to your server manually.
The other issue is that when you’re loading third-party scripts you don’t have access to add the caching headers, as you don’t have any control of their web servers. Common culprits include the Google Analytics script and marketing pixels, like Facebook and Twitter. To fix this you can host your Google Analytics script locally (although this isn’t officially supported) with a plugin like Perfmatters. WP Rocket also now has an option to host your Facebook marketing pixel locally.
Moving scripts locally can vary in terms of how much it impacts your site’s performance. The one advantage is that you then have complete control over the file and can serve it from your own CDN. This also removes another third-party DNS request. However, it’s also important to remember that these files might already be cached in people’s browsers.
See our in-depth post on how to fix the leverage browser caching warning.
Remove Query Strings From Static Resources
https://domain.com/file.min.css?ver=4.5.3. Some servers and proxy servers are unable to cache query strings. So by removing them, you can sometimes improve your caching.
However, before you immediately go strips out query strings on your site it’s important to know why query strings are used. Versioning on files is typically used by WordPress developers to get around caching problems.
For example, if they push out an update and change
?ver=4.7, it will be treated as a completely new URL and won’t be cached. If you remove the query strings and update a plugin, this could result in the cached version to continue serving. In some cases, this could break the appearance of your site until the cached resource expires or the cache is completely flushed.
Also, some CDNs can cache query strings. The Kinsta CDN can and does by default. So if you’re a Kinsta client, query strings are already cached on your assets.
See our in-depth tutorial on how to remove query strings from static resources.
Serve Static Content From a Cookieless Domain
We have an in-depth post on how to deal with the serve static content from a cookieless domain warning. A lot of times you can ignore this warning as new protocols such as HTTP/2 now make this less important. The cost of a new connection is usually costlier than streaming everything over the same connection. However, two ways to solve this is to use a CDN provider that strips out the cookies or create a separate domain and or subdomain.
Parallelize Downloads Across Hostnames
The “Parallelize Downloads Across Hostnames” warning results because of a limitation of HTTP/1.1 and web browsers being limited to the number of concurrent connections they can make to a host; which is typically 6 connections. This warning is typically seen on websites with a large number of requests. In the past, the only way to get around this limitation is to implement what they call domain sharding. However, if you are using a web host or CDN provider that supports HTTP/2, you can safely ignore this now as multiple resources can now be loaded in parallel over a single connection. But you can also check out our tutorial on how to fix the parallelize downloads across hostnames warning by implementing domain sharding.
Specify a Cache Validator
This warning refers to missing HTTP caching headers which should be included on every origin server response, as they both validate and set the length of the cache. If the headers aren’t found, it will generate a new request for the resource every time, which increases the load on your server. These headers include
Expires. Just like with the leverage browser caching warning, these headers should automatically be added by your WordPress host. If you have third-party requests you are seeing this on, there is nothing you can do as you don’t have control over their web servers.
Read our in-depth post on how to fix the specify a cache validator warning.
Specify a Vary: Accept-Encoding Header
We have an in-depth post on how to fix the Specify a Vary: Accept-Encoding header warning. This is an HTTP header and should be included on every origin server response, as it tells the browser whether or not the client can handle compressed versions of the content. This is automatically added on all Kinsta’s servers
The next section in Pingdom speed test tool is the response codes. Response codes, also referred to as HTTP status codes are like a short note from the web server that gets tacked onto the top of a web page. It’s a message from the web server letting you know how things went when the request to view the page was received. Some common ones are:
- 200: “Everything is OK.” This is the code that is delivered when a web page or resource acts exactly the way it’s expected to.
- 301: “The requested resource has been moved permanently.” This code is delivered when a web page or resource has been permanently replaced with a different resource. It is used for permanent URL redirection.
- 404: “The requested resource was not found.” The most common error message of them all. This code means that the requested resource does not exist and that the server does not know if it ever existed.
You can read more about all the different response codes in our in-depth post on HTTP status codes.
The next sections are the content size by content type and the requests by content type. Each of these is useful to quickly see what is taking up the most resources on your web page. According to HTTP Archive, images generally make up for 43% of an average web page’s total size. We also see this to usually be the case as well. However, as you can see below on this site, it is not always the case.
For optimizing your images, we highly recommend reading our in-depth post on how to optimize images for web. There are many great tools and plugins out there to further compress your images and ensure they aren’t the bulk of your website’s page load. And in our case above, the perfmatters.io site is taking advantage of using large font awesome icons in place of images. This can be one great strategy that makes a huge difference. And of course, we have some additional tips in our page speed guide on how to further decrease your content size.
The content size and requests by domain section is a good way to quickly see which external services and scripts on your website. In our example, you can see that we have all of our assets loading from our CDN. Then there is the initial HTML DOC load for the website from the web server, and an external call to the Google Analytics domain. Depending upon your site you might have a lot more external services, such as Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.
Generally the fewer external requests you can make the better, because each external services introduces its own latency, TLS handshake delays, DNS lookups, etc. Make sure to read our in-depth post on how to identify and analyze external services on your WordPress site.
Generally, it’s best to reduce the number of requests as much as possible and host the assets in one place, such as moving them to your web server or CDN. One example would be font awesome. Instead of linking to the external script for font awesome, download it, and serve it up directly.
And last but not least, we have the Pingdom speed test tool requests section which generates a waterfall chart of all the individual requests on your web page (as shown below). You can then analyze each request to see what is causing delays and performance issues on your site. This is what we mean when we say we are doing a waterfall analysis. Below is a more in-depth summary and or definition of what each status color means.
So what is DNS? Well, think of it like a phone book. There are servers called Domain Name Servers which hold the information about your website and which IP it should be routed to. When you first run your website through Pingdom, it performs a fresh lookup, and it has to query the DNS records to get the IP information. This results in some additional lookup time. The location of the DNS server also matters.
When you run your website through Pingdom more than once, it caches the DNS because it already knows the IP information and doesn’t have to perform the lookup again. This is one reason why your website appears faster after running it through Pingdom multiple times.
As you can see in the screen below, on the 2nd test we ran, the DNS lookup time on the initial DOC load is on 3.6 ms. Typically it will drop to 0 ms, in fact, it should, as the request is already cached. This is one area a lot of people misinterpret!
Also, you can further optimize it by using a premium DNS service, plus it comes with a lot of extra benefits. Our Cloudflare’s free DNS is also fast!
There are also other reasons why your website might appear faster after multiple tests. One of those is if you are using a content delivery network (CDN). For those of you not familiar with a CDN, it is a network of global servers which cache your content (JS, CSS, Images, etc.) in locations closer to the visitor. When you first run your website through Pingdom, it might have to grab the assets from the CDN fresh. A CDN cache works much like DNS, once it is cached, it is then much faster on consecutive loads.
Another tip on speeding up DNS is to use DNS prefetching. This allows the browser to perform DNS lookups on a page in the background. You can do so by adding some lines of code to the header of your WordPress site. See some examples below.
Or if you are running WordPress version 4.6 or newer, you might want to use resource hints. Developers can use the
wp_resource_hints filter to add custom domains and URLs for
The purple status color stands for the time that your browser takes to do an SSL/TLS handshake. Whenever you run a website over HTTPS it means there is an SSL certificate involved and extra time involved due to the encryption process (SSL/TLS handshake). On our example domain, we have a certificate on both our web server at Kinsta and our CDN, KeyCDN. So there is an SSL negotiation time on both the initial HTML doc load from the web server and our assets.
While there is slight overhead to running HTTPS, it very negligible now thanks to HTTP/2, which is a new protocol helping speed up the web! Due to browser support HTTPS is required to utilize HTTP/2. Check out our ultimate guide to HTTP/2.
It’s also important to note that even in 2018 not all providers yet support HTTP/2. This includes both from the web hosting side and the CDN side. So when you are shopping around for hosting and CDNs, make sure both support it! Kinsta is proud to support HTTP/2 for all of its WordPress clients.
As of mid-2018, Pingdom finally upgraded their tool to use Chrome 60 and higher. You can see the
user-agent being used in the request header. Previously they were using Chrome 39, and Chrome didn’t support HTTP/2 until version 49. So we are glad to say that the Pingdom tool now shows all the advantages of HTTP/2 when running tests!
The connect time in Pingdom is referring to the TCP connection, or the total time required to create a TCP connection. You don’t really need to understand how this works, but this is simply a communication method between the host/client and the server that has to take place.
The wait time in Pingdom is actually referring to the time to first byte, also known as the TTFB in some tools. TTFB is a measurement used as an indication of the responsiveness of a web server or other network resource. Generally, anything under 100 ms is acceptable and good TTFB. If you are approaching the 300-400 ms range you might have something misconfigured on your server or it might be time to upgrade to a better web stack.
The easiest way to decrease your TTFB? The best two ways are effective WordPress caching and a CDN. So let’s run a couple tests.
TTFB Without WordPress Host Cache
We first ran a test after clearing the cache on our WordPress site. This means it has to preload the cache again. As you can see our total load time was 541 ms and the TTFB (wait time) on our initial request was 185.2 ms.
TTFB with WordPress Host Cache
We then ran the test again. It is now serving directly from cache. As you can see our total load times dropped down to 392 ms and the TTFB on the initial request is now 52.8 ms! That is the difference caching makes.
If you have a website that is serving visitors in different parts of the country, or around the globe, the other easy way to drastically decrease your TTFB is to use a CDN. We again ran a few tests to show the difference.
TTFB without CDN
We first ran a test with our CDN disabled and as you can see our total load time was 1.93 s and our average TTFB on an asset was around 176 ms.
TTFB with CDN
We then enabled our CDN and ran the test again. As you can see our total load times dropped down to 1.21 ms and our average TTFB on a CDN asset is now 4.6 ms! What a difference a CDN can make.
Another important thing to note is that we chose the “Pacific – Australia – Sydney” location to perform this test. Why? Because we wanted to show you the real improvement that can be had. Our WordPress site in this example is hosted by Kinsta on the Google Cloud and located in a central location in the USA. By performing the test against Australia we are able to show how the Kinsta CDN caching increases the speed and reduces the TTFB.
And of course, having a good WordPress host with a carefully thought out architecture is also crucial to lowering your TTFB.
Send (Orange) and Receive (Green)
The send and receive status’s in Pingdom don’t really need much of an explanation. The send time is simply the time it takes for the web browser to send data to the server. And the receive time is the time it takes for the web browser to receive data from the server. Both of these will usually be very low or non-existent in your tests.
HTTP Response Headers
You can also click on an individual request while doing your waterfall analysis and see the HTTP response headers. This provides valuable information. In the screen below we can instantly see things such as gzip is enabled on the web server, and that it’s being served from cache (HIT, would show MISS otherwise), the cache-control headers, expires headers, the browser user-agent and more.
If you got this far down in our waterfall analysis post then you are in for a treat. It is always annoying to see people share tips and case studies but then not share how they got there. So below is our exact configuration for the case study domain used above! Feel free to replicate it.
- The case study domain (perfmatters.io) is hosted with Kinsta on the Google Cloud Platform in the USA (Council Bluffs, Iowa, USA (us-central1). Kinsta currently offers 18 different data centers to choose from. GCP’s premium tier network is included with all plans for lightning fast network latency.
- Kinsta uses HTTP/2, Nginx, MariaDB, which all contribute to the fast load times.
- The site is using KeyCDN, which powers the Kinsta CDN. Free CDN bandwidth is included in all hosting plans.
- The site is not using any caching plugin. Kinsta caches everything at the server level which greatly simplifies things!
- The site is using PHP 7.3. Newer versions of PHP have always shown great performance improvements. Check out these PHP benchmarks. Kinsta allows you to switch between the two with press of a button.
WordPress Plugins and Theme
Here is a list of the plugins that impact performance being used on the WordPress ecommerce site.
- The premium Perfmatters plugin, developed by a team member at Kinsta. This gets rid of unnecessary HTTP requests such as embeds, emojis, and also has a script manager to enable/disable certain scripts from loading on a per page/post/sitewide basis.
- The premium Imagify plugin is used to compress images.
- The free Safe SVG plugin is used to upload SVG images to the WordPress site.
- The premium GeneratePress WordPress theme was used to build the EDD site.
Recommended Tutorials for Further Reading:
- How to Disable Emojis in WordPress
- How to Disable Embeds in WordPress
- How to Score 100/100 in Google PageSpeed Insights with WordPress
- How to Diagnose High Admin-Ajax Usage on Your WordPress Site
As you can see, knowing how the Pingdom speed test tool works a little better and what all the charts mean can help you make a more data-driven decision when it comes to performance. A waterfall analysis as we call it is crucial to know how your individual assets load and how they are impacted by your WordPress host, physical location, a CDN, etc. Got any other great Pingdom tips?
If you would like to see more in-depth articles like the one above, please let us know below in the comments!