Top 5 ‘TTFB’ Facts You Should Know:
There is already a mountain of jargon and technobabble around Web technology so let’s simplify and get to the bottom of this ‘time to first byte’ stuff together.
#5: What on earth is this TTFB thing?
Let’s say you’re sitting at home and decide to visit YouTube.
You put YouTube.com into your Chrome or Firefox browser and wait to see the site load for you.
What just happened was that:
[a] your Chrome or Firefox browser sent a ‘request’ to the server (computer) where the YouTube.com website is hosted.
[b] YouTube.com then had to process the request from your Chrome/Firefox browser (to look at that page), then:
[c] YouTube.com started sending back a response for your Chrome/Firefox browser to show you new funny cat videos. Brilliant!
That first response back to your Chrome/Firefox from YouTube.com was the ‘Time To First Byte’.
#4: What is a fast TTFB time & what’s slow?
This is a topic of hot debate, like whether a particular car’s 0-60 time is fast or slow.
For some, the Nissan GT-R’s 2.8 seconds is incredibly fast but if you’re a Tesla electric fan, that might seem sluggish.
Here with TTFB, we are talking milliseconds, thousandths of a second, and to crudely generalize, below 300 milliseconds is pretty good but even a little above that may not be an issue.
Why?
Because TTFB is just ONE PART of a fast-loading page for real human visitors to your website.
More on that below.
According to Pingdom Tools (Washington DC), here’s the TTFB on my site, terrykyle.com, hosted on WPX of course (the yellow ‘Wait’ bar is the TTFB), just over 24 milliseconds but this page has been well optimized with caching, CDN etc:
You can and should test any of these results posted here for yourself.
#3: Do all tools report the same TTFB?
No, far from it.
And this is where things get MURKY (cue sinister background music).
You see, different tools will get very different TTFB times to each other, even though they are all testing the same webpage on the same server, although from different locations.
Let’s check the terrykyle.com TTFB times with two other popular tools, GTMetrix and webpagetest.org
Firstly, webpagetest.org reports that my TTFB is almost TEN TIMES slower than Pingdom Tools (24 milliseconds) at 233 milliseconds:
while GTMetrix (Dallas) comes in at 116 milliseconds:
So which tool should you trust and which should you ignore?
Well, I would argue that if they are all acceptably low, then move on to other speed fixes on your site.
And while we’re discussing the accuracy of these tools, don’t ever forget that the page load times they report actually count all the ‘3rd party’ scripts (e.g. Google Analytics, Google Fonts, Facebook Pixel, live chat widgets, ad serving platforms etc) that load AFTER the main web page content.
That means your pages usually load MUCH FASTER than the tools report – use a free VPN like Tunnelbear.com and different browsers to see how quickly your sites load e.g. if you go to YouTube.com, the page loads almost instantly from anywhere in the world but GTMetrix offers this nonsense:
and how about the so-called ‘Performance Grade’ of YouTube.com (owned by Google of course) on Google’s own Page Speed Insights tool – seriously Google?
#2: What slows down my TTFB time?
A number of factors can slow down your TTFB time.
These include:
PROBLEM 1: Your Webpage is heavy, complicated and has a lot of dynamic content (individualized pages like checkout pages) that the server has to process before responding to a browser request
SOLUTION: Create an empty default WordPress installation on a test subdomain in your hosting account, then check the TTFB of that empty WP site.
If the TTFB is much much faster than your slow TTFB site, then it’s the configuration of your slow TTFB site and NOT the host server.
In short, you’re to blame and you need to dig deeper into the slow TTFB site configuration and start optimizing.
PLUS: Check the TTFB on your other sites with the same host. If some or all of those have a much better TTFB, then it’s the configuration of the slow TTFB causing the issues, not the host’s server.
PROBLEM 2: You are not using caching. Unless you have some complex e-commerce site that doesn’t play well with caching, you should always be using caching and not forcing the server to keep rendering pages from scratch over and over and over.
A cached page will almost always serve WAY faster than an uncached one.
SOLUTION: WPX recommends (free) W3 Total Cache as our go-to caching plugin but with our own custom settings.
Check with WPX Support for specifics, and they can configure it for you quickly too if needed (free).
PROBLEM 3: You are not using a CDN (Content Delivery Network).
WPX has its own CDN so that your website content is served NOT from where your site is hosted with us (e.g. Chicago, London, Sydney) but from the closest VPS in our CDN e.g. even if your site is hosted in Chicago, a visitor from Brazil will be getting the content from our Chile CDN location, which will be much faster.
SOLUTION: Use a high-speed CDN, like WPX’s which is free and helped us win this speed test and this one.
PROBLEM 4: Your host sucks.
Cheap hosting deals almost invariably mean ancient, overloaded servers with terrible support.
Is that the experience you want your site visitors to have – a slow, sluggish website?
SOLUTION: Same test at Problem 1 above.
Create an empty default WordPress installation on a test subdomain in your hosting account, then check the TTFB of that empty WP site.
If the TTFB is much much faster than your slow TTFB site, then it’s the configuration of your slow TTFB site and NOT the host server. If the empty test site is also very slow, then it’s time to change hosts!
#1: If my TTFB looks OK, what should I look at next for more speed?
Good news!
I already covered this topic here with pretty fast ‘quick wins’ for speed optimization.
See ya over there!
