What Is Time to First Byte and How to Improve It

Perhaps you have heard the phrase Time to First Byte but somehow the concept seems to escape some people. Be it because it seems incredibly tech oriented or because it seems like an abstract concept, not that important to everyday use. Nothing could be further from the truth.

Time to First byte is not actually a concept or an idea that only the techie people should understand. Everyone should be able to grasp it’s meaning and apply it into practice.

In this article I’m going to explain to you, in few words: what is Time to First Byte, how does this affect your site and why you should pay considerable attention on this subject if you want to give your readers the best experience possible when browsing your site.

What is Time to First Byte?

Time to first byte (TTFB) is a measurement used as an indication of the responsiveness of a webserver or other network resource.

TTFB measures 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. This time is made up of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page. Although sometimes misunderstood as a post-DNS calculation, the original calculation of TTFB in networking always includes network latency in measuring the time it takes for a resource to begin loading.

That’s the “techie” explanation taken directly from Wikipedia. Now let’s translate that to a simpler one that serves everyone.

Time to First byte is the time it takes from you pressing that button to load a website to the moment it starts rendering. If you were to speak of this in gaming terms, Time to first byte would be similar to the “latency” or “lag” you have while gaming. The latency is a direct representation of how much perceived responsiveness your site has.

What Factors Affect Time to First Byte?

Time to first byte can be represented by several factors but since this is a WordPress article, we are going to reduce everything to what is being affected when WordPress is in place.

• DNS response time
• Server configuration and performance (PHP and webserver)
• WordPress Plugins/Theme
• HTML Caching Enabled/Disabled

Each and every one of those factors adds an additional latency to the time it takes for your site to start rendering. This means that it all adds up. It’s not that some of those factors may impact latency, all of those factors contribute to more latency! So you can guess that for an ideal scenario, everything should be fast for you to get a very good Time to First Byte and if something in that chain is taking more time to process, your final Time to First byte will suffer.

This is important because Time to First byte affects everything that you or your readers do on your site. Each time a reader clicks on some link, picture, blog post or page, Time to First Byte will be taken into consideration. You can see that a bad Time to First Byte will mean that the reader will have a situation similar to a gamer connected to a poor server. Each click will have a considerable lag associated and that will impact the experience.

Note: From this point forward I’m going to use the acronym TTFB to denote Time to First Byte just to speed things up a bit.

1. DNS response time

DNS resolution is the first factor in the equation. Always be sure to use good DNS servers and that they have nodes spread all over the word to get the best resolution possible. A good way to reduce TTFB in this step is to use a good global service like CloudFlare as that kind of service implements Global DNS caching. This method is extremely good for reducing TTFB by caching further resolutions.

2. Server Configuration

The second step in TTFB latency is the actual server. This is where your hosting comes into place. The type of webserver configuration it employs and the caching techniques will greatly reduce TTFB. For example, if your server implement the old PHP 5.4 interpreter you’re gonna get a very high TTFB whereas using a modern PHP 7.1 configuration will reduce that time by a factor of 2 or more.

This is because the PHP interpreter plays an important role in the process. Each time you ask for a website page or blog post that is uncached, the server will need to process the PHP files in question to convert them in HTML format back to your browser. The more complex the PHP files are, the more time it will take to pre-process them and send them back to your browser.

You can see that performance of the server will also take an important part on the whole process. The faster the CPU and the more resources your hosting allocates to you, the faster it will process those files and hence, your TTFB will be smaller.

Also, if your hosting implements a PHP caching, this will be further reduced on the second request as it will provide a cached version of that file instead of having to process the PHP file all over again.

You can see now there are 2 types of hosting business, the general (uncached) services and the WordPress exclusive hosting services that usually implement a caching mechanism for PHP, reducing your TTFB in the process.

3. WordPress Plugins and Theme

The third step in the TTFB equation is your actual site. This is the most important factor and I’m going to show you why.

Usually WordPress will give your hosting several PHP files to process and the more complex they are, the more time it will take to process. WordPress is served by plugins and those plugins adds extra code to the final PHP processing so with this in mind you can clearly see that the more plugins you have installed, the more time it will take for your hosting to process them and hence, your TTFB will increase.

The Less the better

As a rule of thumb, less plugins is typically better. Of course, one poorly coded plugin can be much worse than 10 expertly coded plugins or it’s possible to install two plugins that happen to conflict. But generally speaking condensing down the number of plugins makes it easier for you to manage updates and keeps your site speeds up. Here is an example of a reasonable amount of plugins for an installation.

This next example could be problematic (again – it does depend partially on what you have installed).

And of course, anything past the 30 plugins barrier is likely not good for your latency. You can be sure that a website with more than 40 plugins will have a severely high TTFB even if it’s hosted on a spectacular hosting service and I’m going to show you why.

4. HTML Caching

The last factor is the most important and it is related to the caching mechanism you decide to implement on your WordPress installation. Although there are several types of caching mechanisms in WordPress, the most effective of them all is HTML Caching.

Having a good plugin like KeyCDN Cache Enabler will have a tremendous impact on your TTFB, even more so than the hosting itself. It will convert all those files into HTML so once the cache is active your readers will not need to pass through the PHP pre-processor on your hosting and it will be only the webserver itself responsible for serving your content. You can even speed up the process even more if you decide to use a hosting that includes nginx instead of apache as the main webserver as I’ve explain in this article.

Time to First Byte Case Studies: Why It’s Important

Now let me show you what we’re talking about. The following case studies are real life examples of website configurations on various servers, with a handy benchmark summary at the end.

A Slow Website on a Slow Server

Having a slow site can be a pain for TTFB and if you don’t care about a good hosting service then you must be prepared to face the worst outcome possible.

Let’s analyze this site in detail. For this purpose I’m going to use Pingdom Tools because it’s an excellent tool for letting you see the TTFB. The trick is to open up the detail on the first request done to the site.

As you can see, the site has a TTFB of no less than 4.2 seconds! This means 4 complete seconds pass until you get any indication that the website is actually available.

Now multiply that time by all the clicks you’re going to do on the site and you can see how much pain that could be to a reader. Of course, TTFB must be added to the total time the site takes to render. The result will be catastrophic for performance as the site will take as much as 7 seconds to render properly sometimes.

The combination of several factors lead to this. A poorly optimized website without a caching mechanism, a very slow hosting service and a completely outdated PHP interpreter, which is still running PHP 5.4. Even when the site uses cloudflare as an external caching mechanism there is nothing that could be done to improve the situation, if your site and your hosting don’t cooperate.

A Fast Website on an Average Server

Let’s see what happens when we put a very fast site on an average server that uses Apache and PHP 7.1

With a site that has less than 10 plugins on it without a cache, the result is at least 5 times better than the previous one. You can see that TTFB is now set at 521ms. That means that the site will take 0.5 seconds to start rendering on your browser, from the moment it goes from the server to the moment it reaches your computer.

What happens when we activate the cache on that website? Magic happens. A generally average server running on Apache can give excellent results with just 152ms of TTFB. You can see how much a good WordPress caching mechanism affect the results.

A Very Slow Website on a Fast Server

Now let’s see the opposite. What happens if we put a very slow site onto a very fast server.

An optimized server running Plesk with nginx and PHP 7.1.11 will take 1.29 seconds to render a site filled with plugins (more than 27).

But when we activate Caching on WordPress through the lovely KeyCDN Cache Enabler the result is amazing. The very slow site has it’s TTFB reduced to just 400ms.

A Fast Website on a Fast Server

Now let’s see the optimal situation. A fast website running on a fast server.

The same server that was giving a 1.29 seconds TTFB on a slow site responds in less than 500ms on a fast site without cache.

If we enable cache, the results are simply amazing. A fast server, combined with a fast website with caching enabled gives less than 150ms of TTFB!

Benchmark Results

Let’s see the results all in one big graph for benchmark lovers.

You can see that hosting serves an important role in reducing your TTFB and improving the latency and perceived performance of your site but what you do with the site has the most impact on performance.

Wrapping Up

Having a good TTFB metric will guarantee you that you’ll have a fast and responsive site, it will cut your general rendering time and will serve as an excellent metric to determine the performance. Usually, the higher the TTFB, the slower your site will be. Having TTFB in mind when you benchmark your site is paramount as this timing can also be used to determine bottlenecks on your WordPress installation. You can do a simple exercise by simply disabling all plugins and swapping to a basic theme and then measure TTFB again. You’ll be amazed by the results.

I want to finish this article by saying this is by no means the “one metric to rule them all” as there are other factors to consider including database performance, bandwidth available and network speed. But since TTFB is usually affected by all those factors too, it’s a good indication of bottlenecks elsewhere.

Hopefully you’ll take a chance to experiment with your TTFB. Leave your comments below. We’d love to hear about your own testing, or help with any questions you might have.