Time To First Byte
Our customers worry about Time to First Byte more and more. It is one of the key indicators that Google PageSpeed uses to determine whether your website loads quickly enough and whether or not it gets a good score. Let’s talk about its meaning and usefulness.
Meaning TTFB
So what is TTFB? Wikipedia states it is “the duration from the user or client making an HTTP request to the first byte of the page being received by the client’s browser.”
Google PageSpeed refers to https://web.dev/time-to-first-byte/ and states that:
“This audit fails when the browser waits more than 600 ms for the server to respond to the main document request. Users dislike when pages take a long time to load. Slow server response times are one possible cause for long page loads.”
So it say Time to First Bye (TTFB) is about the server response to the main document request. And that you get a failed audit when it hits more than 600ms. And in general each request differs depending on how busy the server is.
TTFB Useful or Meaningless?
Cloudflare said back in 2012 that TTFB is meaningless and shows in a blog post that slower TTFB can sometimes mean better serving methods for pages such as when Gzip compression is used. It also mentions the effect of network latency as part of TTFB:
Measuring TTFB remotely means you’re also measuring the network latency at the same time which obscures the thing TTFB is actually measuring: how fast the web server is able to respond to a request.
At CloudFlare TTFB is not a significant metric. We’re interested in optimizing the experience for end users and that means the real end-user page being visible time. We’ll be rolling out tools specifically to monitor end-user experience so that all our publishers get to see and measure what their visitors are experiencing.
Google PageSpeed certainly begs to differ and often fast loading websites get penalized for it while doing test with their tool. Currently Optimizin bounces up and down between a 83-90 score on mobile and when it is in the low 80s it is always mainly about TTFB. And that is not due so much to plugins nor the theme as we hardly use any plugins and we have the awesome Roots Sage 9 as our theme. So what is a man to do?
Efficient Document Serving
Well to gain another 5-10 points the document preparation for serving must be done as efficiently possible. And then we are talking the database request, page and database caching and compression of the document.
Pingdom test https://tools.pingdom.com/#5bec593d75000000 shows DNS and connection time take the longest and connection time is all about the preparation time before server allows request to be fulfilled:
DNS
DNS can often be a bottle neck as is SSL. So you should check that out as part of the general TTFB (See Kinsta on this). Our DNS is is with Digital Ocean though domain is with Dreamhost. Authority has been passed on to DO and in general Digital Ocean is a decent DNS hoster. Number 3 in Europe according to DNS Perf.
DNS Test
When checking DNS at http://www.solvedns.com/dnsspeedtest/optimiz.in we get ~36-90ms (AMS the best of course as were are at AMS3). According to Kinsta they get ~12ms with Amazon Route 53. However, in Europe Amazon Route 53 is on spot 9 whereas Digital Ocean is on spot number 3. So perhaps this goes for sites in the US only.
Discrepancies & Latency
Oddly enough DNS Perf talks about DNS query speed of 11 ms whereas we are getting 36 on average at best from Solve DNS. Perhaps a latency issue? Well yes, and, if you check the Amsterdam numbers only, you get at 3-5 ms most of the time. So Google PageSpeed might deal with latency here as well. As Cloudflare stated in earlier mentioned post
Probably the only time TTFB is useful is as a trend. And it’s best measured at the server itself so that network latency is eliminated.
At the server itself being the key here. Just now I tested from Frankfurt with Pingdom and DNS was a whopping 179ms! And that is from within Europe!
Connection Time
The connection time or time for server to server a document post any caching or compression can be a bit slow at times as you could see at Pingdom, but overall this is not a real issue on our 2GB RAM Droplet though perhaps dedicated MySQL Droplet and more CPU may help.
So what about your setup? Well, you should check you have caching set up and well to serve pages quicker bypassing PHP and database processing. You should also make sure your server is quick enough and that no things like memory throttling take place.
You also need to make sure you only use the best plugins and theme to reduce server memory and CPU usage.
And lastly do make sure you tell the browser to cache things properly with expire headers and such. This will reduce server requests and make the server all that snappier.
So what to do?
Well in our case it seems that Cloudflare for DNS would be the next best thing to reduce DNS latency quite a bit. Cloudflare works well in Europe and pretty much anywhere in the world though Amazon is king in the US. And as we prefer not to work with Amazon, Cloudflare is what we may go for next. Though as you can see below in the GTMetrix test we are not particularly worried at the moment:
DNS in this case took a mere second and was done from Canada apparently.
For you, if DNS is also an issue, you should check DNS Perf and decide whether you want to move to another DNS provider and which one to use. Best of luck!