Last week I told you how I moved the site to a new host and that the site now runs on a server with better specs for a lower price. I also shared the results of a test to measure server response time and while response times are better with Siteground than my old host, they weren’t anything to brag about.
Today I want to share the results of some other tests I ran. I’ve been running these tests throughout this on-again off-again series as I’ve made changes to both the site itself and the server that houses it.
I’m specifically interested in results for the time to first byte (TTFB) and the Speed Index number specific to the WebPageTest site. The waterfall charts that accompany these tests also pointed out something interesting about HTTP.
What are Time to First Byte (TTFB) and Speed Index Again?
As a reminder, the time to first byte (TTFB) is a measure of how much time it takes from the initial request for a web page until the first byte of data is returned. It includes the time needed to send the HTTP request, make a DNS lookup, and create the HTTP handshake between client and server. It also includes the time needed for the server to process the request and send back the first byte of the response to the client, hence the name time to first byte.
Speed Index is a metric specific to WebPageTest. It attempts to measure the average time until visible parts of the page are displayed. It’s meant to be a measurement of the overall experience and perceived performance of the page in question.
The Initial Test Results
Since Speed Index is only available through WebPageTest and they offer results for TTFB, that’s where all these results come from. WebPageTest runs three tests for each location you test. The numbers in parenthesis are for the second and third runs and most of the time they’ll be better than the first run due to DNS caching.
Note: I should point out that the results of these tests can vary from day to day. I’ve run them several times while writing this post and sometimes receive results that are either much better or worse than when run on another day. I did my best to pull numbers from what seemed to me a middle set of results.
Here are the last set of results I received for the site while it was still on my old host. Not shown is the overall grade of C the site received for the TTFB times.
| Location | TTFB (2nd, 3rd) | Speed Index (2nd, 3rd) |
|---|---|---|
| Dallas | 0.613s (0.441, 0.454) | 1407 (997, 998) |
| Paris | 0.584s (0.670, 0.555) | 1414 (1902, 1318) |
| Sydney | 1.225s (1.199, 1.128) | 2785 (2843, 2698 ) |
Here are the results from when I first tested the site on Siteground. It received an overall grade of F for the TTFB times. Huh?
| Location | TTFB (2nd, 3rd) | Speed Index (2nd, 3rd) |
|---|---|---|
| Dallas | 0.974s (0.823, 1.200) | 1748 (1551, 1918) |
| Paris | 1.494s (1.287, 0.994) | 2538 (2300, 1816) |
| Sydney | 2.018s (2.150, 1.889) | 3026 (3126, 2728) |
You’ll notice that all the numbers on Siteground are worse, which didn’t make sense. Given the better specs of the new server, my upgrading to PHP 7, the use of HTTP/2, and the better results for server response times which I shared last week, I naturally assumed TTFB and Speed Index would also improve, but they didn’t.
My first reaction was to double check to make sure I had the old numbers correct and also to rerun the tests I had just run. I had the old numbers right and repeating the test led to very similar numbers.
Waterfall Charts to the Rescue
I still felt like something wasn’t right, but to figure out what it might be I needed to look further down on the results page to scan the waterfall diagrams. Here’s the first run waterfall from Dallas.
As soon as I saw the waterfall I noticed something strange. The HTML for the page (the bluish gray bar in the top two lines) downloaded twice. It took a moment or two, but I realized this was because the URL for the page redirected from http to https. If you look all the way to the left in the image, you can see there’s no lock icon next to the first line, but the icon is there for the second and third lines and so on with one lone exception.
I reran the test using https directly to eliminate the redirect and here’s the resulting waterfall diagram.
You can see the initial request is gone and everything happens about 400ms quicker than it had previously. Here’s the TTFB and Speed Index results running the test against https directly.
| Location | TTFB (2nd, 3rd) | Speed Index (2nd, 3rd) |
|---|---|---|
| Dallas | 0.604s (0.515, 0.504) | 1252 (1250, 1214) |
| Paris | 0.967s (0.872, 0.724) | 1908 (1916, 1708) |
| Sydney | 1.089s (0.895, 0.940) | 1958 (1691, 1858) |
That looks better and it’s the improvement I originally expected. The overall grade for the TTFB times is now a B. Still some work to do, but a definite improvement.
That’s good news, but only when someone accesses the site using https URLs. It means I have some work to do to update all the absolute URLs I’ve used over the years that still point to the http versions of pages.
Also where possible, I should probably change the URLs on other sites that point back here. Many I’ll have little control over, but forum signatures and social profile pages are URLs I can easily change. All the http links will still redirect properly, but anyone clicking them will have to wait a half second or so longer for the first page to load. I already have a task set in Things to update the URLs.
Most of the traffic to this site comes from search engines, specifically Google and I’ve noticed that Google has already started to display the https version of most pages and is probably displaying https only by the time you’re reading this.
Closing Thoughts
Aside from the Paris results, all the tests indicate that the site is loading faster on Siteground than it did running on my old host’s servers. As I mentioned last week, it shows that changing web hosts can improve the performance of your site.
By accident I also saw firsthand how redirection can slow down a site. In this case it was 400 ms or nearly half a second of time to redirect from http to https. Imagine how much time might be lost by chaining redirection so URL-1 points to URL-2 points to URL-3 and so on.
Next in this series I want to talk about the performance of dynamic sites as compared to static sites, specifically potential performance issues with PHP and MySQL and what you can do to make both run faster.
Download a free sample from my book, Design Fundamentals.
Hello, Steven! Thank you so much for your article! It’s well-written and well-explained! Agree that high speed is a crucial factor for your website success!