How to Interpret Site Performance Tests

By Kellen 

Everyone wants faster pages! They make you more money! People looking to speed-up their pages often point to a variety of performance testing tools as evidence to whether or not something is getting faster or slower. Often times, the tests aren't assessed with full context or don't paint a full picture. Let's shed some light on this tricky business!

Tool Time

When you're looking into the performance of your web applications, there are a few different ways you can perform an analysis.

Why are fast applications important? We've written on that very topic: Why App Speed Matters: Revenue.

Client Speed Tests

These tests reveal how potent the network connection of a client is. If you're on a mobile device or a desktop, you can figure out the latency and bandwidth of your connection. Two popular client speed tests are the famous and Netflix's slick and minimal

These tests are excellent at determining what sort of connection you have with respect to your bandwidth but speak little towards your latency. For a refresher, bandwidth is how much data can move in parallel through a connection, latency is how fast the data moved through that connection.

Most developers want to know more about a client's latency when accessing their pages, less about the general strength of their client's connection. Performance assessments seem to be done in a vacuum that assumes a maximally powerful client. The reality is much more random and, in less modernized countries, bleak; you'll have connections of all shapes and sizes - from all sorts of locations - show up to your pages. It is helpful to keep that in mind!

Page Speed Tests

Web-page rendering is a lot like a rousing, hyper-fast game of fetch. Client says to server: "Get this thing!", server races off and returns with thing. This back-and-forth results in an ultimate rendering of the page, or how long the Document Object Model took to become fully realized. In the modern pages of today, many assets are fetched from many places.

How your web-server behaves and how you've written your code has, as one would expect, a dramatic impact on performance. There's a few tools that offer to grade your pages, testing whether or not you're applying modern development techniques - and if you are, how well you're applying them.

Some nifty examples are Pingdom's Website Speed Test, and Google's PageSpeed Insights or Chrome-baked Lighthouse. Putting your hostname into one of these tools will let you know what sort of things you can do to improve the speed of your applications. They aren't bullet proof, though. One noticeable flaw is that they don't yet incorporate best HTTP/2 practices into the mix.

These tools are great if you're looking for ways to optimize your pages so that key page content renders before non-key content. Google calls this the Critical Rendering Path. It's a way of lazily loading assets so that they appear along with the user's journey through your pages. Other tactics include minification, compression, and managing input latency, so the user perceives speed and not delay, ultimately measured by the time to the first meaningful paint: the time it took to generate an enjoyable experience.

While there are many useful tools to help you find optimizations to deploy, the most valuable one is the mind of an experienced developer peering through the granular data presented within the developer tools of their browser.

Connection Speed Tests

Last but not least are the types of performance tests that we see Fly users share with us to make performance comparisons. Due diligence is commendable; nothing like the allure of a promising tool that actually makes your stuff slower. If a Page Speed Test is one that indicates how well your constructed pages are loaded, a Connection Speed Test indicates how long it took to begin loading, then ultimately load your constructed pages.

When doing a page speed test, like in Pingdom for example, you enter your application's URL and select a location. The testing is then done from that location to your application. If you select Melbourne, Australia and you're hosting within San Francisco, your assets need to travel from wherever they are to Australia.

A common misconception is that one blob will go from where you're hosting your pages to the client. Your site is likely made up of assets that are stored in many different places. CDNs, third-party snippets and scripts, all phone-home to somewhere else. With HTTP/1.X, browsers on average max out at 6 connections at a time. HTTP/2 breaks this limit.


Your browser, or a tool like Pingdom, will break this down for you. Above is a screenshot from an NHL team site produced by; it's modern, high-traffic, dynamic, and rich. The image above reveals a small portion of total assets delivered -- there's over 300 in total! We already see 7 different sources; hopefully they're close by!

Each and every asset goes through the same process of connectivity, which can be broken down into 3 key categories that your delivery network should improve:

As unearthed by Moz research, your site's TTFB - among many factors - will impact your search-engine rankings; it's the quickest performance metric that a search engine like Google can receive about sites en masse. You can test TTFB, along with DNS resolution, the SSL handshake, the initial TCP connection, and the total time, within your terminal using curl:

curl -kso /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" \
-w "DNS:  %{time_namelookup}, \
SSL: %{time_appconnect},  \
TCP:  %{time_connect}, \
TTFB:  %{time_starttransfer}, \ 
TOTAL:  %{time_total}\n" \

When we test it on a site, here's how it reports back. We'll use

# Time is in seconds
DNS:  0.004637, SSL: 0.086255,  TCP:  0.024378, TTFB:  0.128285, TOTAL:  0.128381

Neat! These values are useful but they only count for your client. Part of the promise of Fly and other CDN-type services is that your pages will be faster for everyone, not just those in areas with fast connections. A recommended tool for testing this is KeyCDN's Web Performance Test.

It runs the same test from a variety of locations. When run from many edge-servers around the world, you should see consistent fast speeds:


While many Page Speed Tests will give you an indication of the latency, it's often conflated with the overall time to load your application. Those tests are much more useful for optimizing your code. Connection Speed Tests are nice for network evaluation due to their relative purity. It's objective, a report on transit time for your assets.

Don't You... Forget About Me

We know how to test the connection of an individual client, the performance of the code within your pages, and the connection to where your pages are hosted. But, this still doesn't tell the whole story. We're missing a few things...


Support for HTTP/2 can provide fantastic performance improvements -- especially if your application is structured to best squeeze its juice! We've written a guide for developers that shares what one should know to make best use of HTTP/2. You can read it here.

tl;dr: Use HTTP/2 Push and create many, lighter, specialized assets.

If you were to judge a delivery network based on KeyCDN's readings alone, you'd lose sight of the value of edge-wide HTTP/2 support. With HTTP/2, you get back what you put in. Does your current methodology support HTTP/2? You can check here.


You can see the impact of caching within your browser, it tells the story well.

Let's load the site...

Without cache, 815ms:


With cache, 442ms:


There's an important fundamental idea to discuss at this juncture. When you see CDNs and Fly advertise caching, this isn't it! This is client caching, done by your browser. The data is stored within either your memory or on your disk. The caching provided by delivery networks happens at the edge.

Edge-caching means that when a client first accesses your site, if anyone has accessed it from that edge within the specified time-limit, then they will receive assets that are cached on that edge. Given that the edge-server is likely much closer than wherever the application has made port, their connection to every asset will become much faster. It's both edge-caching and client-caching together that provides drastic speed improvements, for first time and repeat visitors.

Edge Computing

Edge computing is a new paradigm. Developers know that they can write code against clients and that they can write code against servers. Now, though, services are appearing that allow developers to write code against the edge.

One thing many developers agree upon is the plague-like nature of client-side JavaScript. If you're using a service like Fly, for example, you can render that code at the edge instead. Our Google Analytics Middleware removes the client-side Google script, rescueing the client from the computational burden and making it un-blockable in the process.

For a more mind-expanding use-case, consider what you could do if you could invoke functions from specific edges around the world. If you needed to process payments within a country for compliance, you could have a function respond to their location, invoking itself within that region only. Or, returning to performance, invoking intensive compression closer to your users to reduce trip distance.

With the ability to use the edge to remove client-side JavaScript and trigger meat-y functions near the user, you receive a major reduction in distance between the client and your application and you remove excess data transferred to the client; both the reduction of distance and the reduction of data are vital for accelerated and dynamic global applications.


We looked at the three different methods of assessing a connection, then looked at their limitations. The more data you have to make informed decisions, the better; however, these tests should not be looked at in a vacuum when you're trying to determine whether or not a service will make your application faster. A service like Fly can do much to speed up your application: caching and functions through global edges, HTTP/2, and optimized SSL, to name a few things.

Ultimately, though, you'll need to wield these tools properly to maximize your applications performance. There is no substitute (yet, mwahaha!) for well-written application code. If you want a great foundation to deliver your code, a service that specializes in fast and secure delivery certainly will not slow you down.

Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.