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.

Knowing how to properly analyze the data from @Pingdom can help you speed up your WordPress site! ⏱Click to Tweet


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.

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 website speed test
Pingdom website speed test

Pingdom currently allows you to test the speed of any website from 7 different locations (5 continents) strategically placed around the globe:

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

A web page is made up of different assets, such as HTML, JavaScript, CSS, images, and videos. Each of these generates requests to render what you see on your website. Typically the more requests you have, the slower your website will load. That is not always the case, but it is true most of the time.

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

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, 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.

Pingdom speed test before DNS and cache
Pingdom speed test before DNS and cache

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.

Pingdom speed test after DNS
Pingdom speed test after DNS

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 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.

When it comes to web performance optimization, you can't forget the user experience! 🚀Click to Tweet

Improve Page Performance

The performance insights section, now “Improve page performance” was updated in 2018 and they have removed some old items and added new ones. 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. And it can be sometimes troublesome if people are simply trying to chase after the perfect Pingdom score.

pingdom performance insights
Pingdom performance insights

However, we are leaving this entire section in our post (some old and new) 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 improve page performance section is made up of:

Now let’s dive into some of these and see which ones are still relevant today.

Use a Content Delivery Network (CDN)

One of the most important services to implement on your WordPress site today a Content Delivery Network (CDN). These are a network of servers (also known as POPs) located around the globe. They are designed to host and deliver copies of your WordPress site’s static (and sometimes dynamic) content such as images, CSS, JavaScript, and video streams.

If you’re a Kinsta client, we include a CDN on all of our hosting plans. Enabling it on takes a few clicks. A few benefits from a CDN include a performance boost (lower TTFB and network latency), lower bandwidth and hosting costs, and even SEO advantages.

Important: The newly updated Pingdom tool currently has a bug correctly detecting any CDN provider accurately.

Use a Content Delivery Network (CDN)
Use a Content Delivery Network (CDN)

Some third-party CDN providers we recommend include:

In our own CDN speed tests, we’ve found that a CDN can decrease page load times by over 50% in some cases!

Avoid HTTP 404 (Not Found) error

This section was previously called “avoid bad requests.” And this 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.

Avoid bad requests - 404 error
Avoid bad requests – 404 error

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.

Minimize Redirects

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 - 301

How much do redirects impact your site? Let’s do a little test. First, we run a speed test on our contact us page: As you can see below we get a total load time of 417 ms.

Website speed test with no redirects
Website speed test with no redirects

We then modify the URL slightly and run another speed test to see the impact of multiple redirects. As you can see, the same page now takes 695 ms to load. That’s an increase of 66%. Yikes!

Website speed test with multiple redirects
Website speed test with multiple redirects

Check out our in-depth post on WordPress redirects, and the best practices for faster performance.

Add Expires Headers

This suggestion was previously called 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 and read our guide on about how to add expires headers.

Leverage browser caching - caching headers
Leverage browser caching – caching headers

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

Another common issue is dealing with query strings. Your CSS and JavaScript files usually have the file version on the end of their URLs, such as Some servers and proxy servers are unable to cache query strings. So by removing them, you can sometimes improve your caching.

You can use a premium plugin like Perfmatters which has an easy one-click option to remove query strings.

Or you can add the following code manually to your theme’s functions.php file. A better alternative would be to use a free plugin like Code Snippets to add the code. This way you don’t have to directly edit your theme.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
add_action('init', 'remove_query_strings');

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 style.css from ?ver=4.6 to ?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.

Remove query strings from static resources warning
Remove query strings from static resources warning

See our in-depth tutorial on how to remove query strings from static resources.

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.

Serve static content from a cookieless domain warning
Serve static content from a cookieless domain warning

Compress Components with GZIP

The “Compress Components with GZIP” warning occurs when Pingdom detects an asset that hasn’t been compressed with GZIP. GZIP is a compression method used to reduce the size of text-based files like HTML documents and CSS/JS files. GZIP compression is enabled on the server, and compresses web pages and assets before sending them to a visitor. From our tests, we saw that enabling GZIP compression reduced the file size of a request by over 78%.

Compress Components with GZIP
Compress Components with GZIP

At Kinsta, you won’t have to worry about enabling GZIP manually because it’s already enabled by default on all of our servers. If you notice that your web host hasn’t enabled GZIP, we recommend reaching out to their support team to enable it immediately because it can have a huge impact on your page speed. If you still see the “Compress Components with GZIP” after enabling GZIP on your server, it’s possible that a server hosting an external asset required by your site does not have GZIP enabled. If that’s the case, there isn’t anything you can do on your end to change the server behavior.

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.

Parallelize downloads across hostnames warning
Parallelize downloads across hostnames warning

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 last-modified, ETag, Cache-Control, and 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.

Specify a cache validator warning
Specify a cache validator warning

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

Specify a vary: accept-encoding header warning
Specify a vary: accept-encoding header warning

Pingdom Response Codes

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:

You can read more about all the different response codes in our in-depth post on HTTP status codes.

Content Size and Requests by Content Type

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.

Pingdom content type
Pingdom content type

For optimizing your images, we highly recommend reading our in-depth post on how to optimize images for web and about WebP. 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 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.

Content Size and Requests by Domain

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.

Pingdom requests by domain
Pingdom requests by domain

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.

When evaluating web performance it's important to decide which files you should and shouldn't host. ⚡Click to Tweet

Pingdom Waterfall Chart

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.

Pingdom waterfall analysis
Pingdom waterfall analysis

DNS (Pink)

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.

DSN delays in Pingdom
DNS delays in Pingdom

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.

Struggling with downtime and WordPress problems? Kinsta is the hosting solution designed to save you time! Check out our features

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!

Cached DNS in Pingdom
Cached DNS in Pingdom

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! Check out Cloudflare’s Automatic Platform Optimization.

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.

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//">
 <link rel="dns-prefetch" href="//"> 
 <link rel="dns-prefetch" href="//">

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 dns-prefetchpreconnectprefetch or prerender.

SSL (Purple)

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.

SSL load time in Pingdom
SSL load time in Pingdom

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! 👏

Pingdom HTTP/2 support
Pingdom HTTP/2 support

Connect (Teal)

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.

Pingdom connect time
Pingdom connect time

Wait (Yellow)

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.

Wait time - TTFB
Wait time – TTFB

The easiest way to decrease your TTFB? The best two ways are effective WordPress caching and a CDN. So let’s run a couple of 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.

Pingdom TTFB before WordPress cache
Pingdom TTFB without WordPress cache

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.

Pingdom TTFB with WordPress cache
Pingdom TTFB with WordPress cache

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 without CDN
TTFB without CDN


We then enabled our CDN and ran the test again. As you can see our total load times dropped down to 1.21 s 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.

HTTP response headers
HTTP response headers

Case Study Domain Configuration

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.


Update PHP version of WordPress site
Update PHP version of WordPress site

WordPress Plugins and Theme

Here is a list of the plugins that impact performance being used on the WordPress ecommerce site.

Recommended Tutorials for Further Reading:


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!

Save time, costs and maximize site performance with:

  • Instant help from WordPress hosting experts, 24/7.
  • Cloudflare Enterprise integration.
  • Global audience reach with 29 data centers worldwide.
  • Optimization with our built-in Application Performance Monitoring.

All of that and much more, in one plan with no long-term contracts, assisted migrations, and a 30-day-money-back-guarantee. Check out our plans or talk to sales to find the plan that’s right for you.