If you use tools to measure the performance of your website such as Pingdom Tools, GTMetrix and others you will have seen a parameter called Time To First Byte, abbreviated TTFB. But do you know what it means, and can you improve the result it offers?
In this article, we are going to see what Time To First Byte is, what affects it and how to improve its results, how to optimize it.
Because the TTFB is one of the parameters that adds load time to your website, sometimes more than a reasonable amount. We will see why and how to improve it.
Table of Contents
Time To First Byte
It is the time that passes from the moment you click on a link or type the URL of a website until it begins to load its content.
It is a measure that tells us the response time of the server or a network resource to a given request.
This means that the Time To First Byte not only exists the first time a resource/url of your website is visited but every time a new resource/url is requested, significantly affecting the perceived performance and usability of your site, either positively or negatively.
As you might have guessed, the first thing to be clear about is:
- A high TTFB is bad.
- A low TTFB is good.
What factors affect Time To First Byte?
As far as WordPress is concerned, there are several factors that affect, positively or negatively, the response time known as Time To First Byte, these:
- DNS response time
- Server configuration and performance (PHP and web server)
- WordPress plugins/theme
- Whether HTML caching is enabled/disabled
- Redirects
Each of these factors adds delay to the TTFB of your site.
By this I mean that you should not focus on improving only one or two of these factors but you should optimize all of them because the user experience will be affected by the sum of all of them.
Anyway, we are going to explain how each of these factors affects the user experience and how to optimize them.
DNS response time
DNS (domain name server) response is the first factor in the whole TTFB equation.
Always make sure to use good DNS, with nodes spread all over the planet, so that they offer the best possible response times to any request from anywhere.
So a good way to reduce TTFB on this factor is to use a CDN service like CloudFlare, which basically caches your DNS globally.
If you don’t use a CDN at least make sure your hosting has a data center close to your website’s target audience.
Server configuration and performance (PHP and web server)
The second step in TTFB response time is the server, the WordPress hosting where you have your site hosted. The type of server configuration you use and its caching systems will greatly reduce the TTFB.
A simple example to understand is that if you use an older version of software, you will get a much higher TTFB than if you used one that is more up to date, which reduces the response time by half or more.
This is because the PHP interpreter plays an important role in this process. Every time a non-cached page is requested the server will have to process the required PHP files to convert them into HTML format so that they can be read by your browser.
The more complex the PHP files are the longer it will take to pre-process them and send them to the browser. And older versions of PHP offer more complex, less optimized versions.
But there are more aspects of your hosting that affect the overall TTFB. For example, the faster the CPU the faster the files will be processed, and the lower the TTFB.
Also, if your hosting company uses PHP caching it will reduce the time of each second request, offering in this second visit to each resource the cached version of the file instead of having to process all the PHP again.
Therefore, it is vital that your hosting offers fast and optimized machines, with up-to-date software and server caching services that improve the responsiveness of your website.
At WPHelp we know this very well and that’s why we trust SiteGround to host the blog and all other websites and services, because SiteGround offers optimized and specialized WordPress hosting, with SSD disks, latest generation hardware, own caching services and specific tools for WordPress.
WordPress plugins/theme
The third factor that affects the TTFB is already your site, in our case WordPress. And it is not a minor factor, quite the contrary, it is one of the most important, and on which we have more potential for improvement without the help of others.
As we saw in the WordPress loading sequence, WordPress hosts several PHP files that are processed, and the more complex they are, the longer they take to process.
But in addition, our site is usually driven by plugins, and those plugins add more code to the total PHP to be processed.
The rule is simple:
The more plugins you have active the more code there is to process and the longer your site will take to load them, and the TTFB increases.
And yes, it is often said that it is not a matter of quantity with plugins, that quality matters more, but that is a relative reality because at the end of the day size does matter.
Although it is true that 10 optimized plugins will generate fewer requests and processing needs than 1 poorly programmed one, in the end, every line of code counts, keep this in mind and use/install/activate only what is strictly necessary for your website.
When you do not control this you can get to a point where you have so many plugins installed, even those made to optimize your website, that harms the loading time of your site, just the opposite of what you were looking for.
This has been verified by many users who have installed plugins like W3 Total Cache and found that their website was slower despite caching part of the code, and is that it is a plugin so extensive, with so much code to process that a poor configuration as a whole can cause just the opposite result to the expected.
If HTML cache is enabled/disabled
The last factor is the most important, and has to do with the caching system you decide to use in your WordPress installation.
The solution is simple, because you only need a good caching plugin like SG Optimizer, which serves as HTML all the code and processes of your installation, and that does it from the server, without affecting your installation/plugins/theme.
This way it is your hosting, that caches all your content and processes from the server.
Redirections
As it cannot be otherwise, any redirection, be it server redirection, transparent, or any other type, will affect the TTFB because it is an additional previous “step” that the browser must go through before displaying our website.
Let alone if they are cross-domain redirects, changes of permalinks, etc.
Of course, remember that each URL has its own TTFB, so that redirects of specific entries also affect the waiting times.
And yes, also HTTPS is a redirect, as all HTTP traffic is redirected to HTTPS, and also negatively affects the TTFB. Fortunately, it pays off in this case, for the SEO and optimization benefits if it allows you to use HTTP/2.
Where do I test the TTFB of my WordPress?
In addition to the usual speed checking and web optimization services such as Pindgom Tools, GTMetrix and WebPageTest, there is a specific site to check only this parameter, Byte Check, which offers you in a very clear and visual way every factor that affects the TTFB.
To summarize
As I think you may have noticed, Time To First Byte is one of the most important factors in the loading of your website, and the factors that affect it are few but important.
And, in short, there are two major players involved:
- Your hosting, which must provide you with the optimal hardware, software and configurations.
- You, who must keep the amount of code to be processed to a minimum.
But most importantly, it is useless to spend hundreds of hours, thousands of lines of code, plugins and optimizations a posteriori, if before starting to load the first byte of your website the client has had to wait 2 or 3 seconds, if it is still there.
