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 , and translated would be Time To First Byte . But do you know what it means? Can the result it offers be improved?
In this article we are going to see what this 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 add loading time to your website, sometimes more than is reasonable. We will see why and how to improve it.
Index of contents
What is the Time To First Byte?
Without getting too great, so that anyone can understand it, we will say that it is the time that passes from when you click a link or type the URL of a website until it begins to load its content .
It is a measure that indicates 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 perception of performance and the usability of your site, either positively or negatively.
As you may have already guessed, the first thing to be clear about is that:
- A high TTFB is bad.
- A low TTFB is good.
What factors affect the 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)
- Plugins / WordPress theme
- If HTML cache is active / inactive
- Redirects
Each of these factors add delay to the TTFB of your site, of each resource requested from your site, not just one, but all of them.
With this I want to tell you that you should not focus on improving just one or two of these factors but that 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 and
how to optimize them .
DNS response time
The DNS (domain name server) response is the first factor in the entire 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 by this factor is to use a CDN service like CloudFlare, which basically caches your DNS globally.
If you do not use a CDN at least make sure that your hosting has a data center close to the target audience of your website.
Server configuration and performance (PHP and web server)
The second step in the 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.
An easy to understand example is that if you are using an older version of software, such as PHP 5.4, you will get a much higher TTFB than using PHP 7.1, which cuts response time in half or more .
This is because the PHP interpreter plays an important role in this process. Every time a page that is not cached 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, 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 total of the TTFB. For example, the faster the CPU the faster the files will be processed, and the TTFB will be lower .
Also, if your hosting company uses PHP cache, it will reduce the times of every 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 updated software and server cache services that improve the response of your website.
In WordPress Help we have this very clear and that is why we trust SiteGround to host the blog and all other websites and services , as SiteGround offers optimized and specialized WordPress hosting, with SSD disks, state-of-the-art hardware, its own cache services and tools specific to WordPress.
If you want to enjoy the same quality hosting that WordPress or Yoast Help uses , here is a discount so you can try it and see the difference .
Plugins / WordPress theme
The third factor that affects TTFB is already your site, in our case WordPress. And it is not a minor factor, quite the opposite, 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 , it hosts various PHP files that are processed, and the more complex they take the longer to process.
But also, our site is usually powered by plugins, and those plugins add more code to the total of PHP to process .
The rule is simple:
The more plugins you have active, the more code you have to process and the longer it will take your site to load them, and the TTFB increases.
And yes, it is often said that it is not a question of quantity with plugins, that quality matters more, but that is a relative reality, because in the end size does matter .
Although it is true that 10 optimized plugins will generate fewer requests and processing needs than 1 poorly programmed, in the end each line of code counts, keep it in mind and use / install / activate only what is strictly necessary for your website .
When you do not control this, you can reach a point where you have so many plugins installed, even those that are to optimize, that affect the loading time of your site, just the opposite of what you were looking for.
This has been verified by many users when installing plugins such as W3 Total Cache and verifying that their website was slower despite caching part of the code, and it is such an extensive plugin, with so much code to process that a deficient configuration as a whole it can produce just the opposite result than expected.
If HTML cache is active / inactive
The last factor is the most important , and it has to do with the cache system you decide to use in your WordPress installation.
Fortunately, the solution is also simple, since you only need a good cache plugin like SG Optimizer , which serves as HTML for all the code and processes of your installation , and which does it from the server, without affecting your installation / plugins / theme.
In this way, it is your hosting, who caches all your content and processes from the server.
Redirects
As it cannot be otherwise, any redirection, be it server, transparent, or whatever it may be, will affect the TTFB as it is an additional prior “section” that the browser must go through before displaying our website .
Let’s not say if they are cross-domain redirects, permalink changes, etc.
Of course, remember that each URL has its own TTFB, so specific input redirects also affect wait times.
And yes, HTTPS is also a redirect , since all HTTP traffic is redirected to HTTPS, and it also negatively affects (little) TTFB. Fortunately it compensates in this case, for the benefits of SEO and optimization if it allows you to use HTTP / 2 .
Examples of how Time To First Byte affects
All of the above will sound like heavenly music if we do not put it in numbers, in real cases.
Optimal TTFB
For example, this would be an example of a low TTFB, in which all these factors are optimized , from hosting to WordPress, of course the cach
e:
And yes, you got it right, it’s WordPress Help.
As you can see, despite the waiting time (latency) that the SSL certificate adds, which always adds something, the waiting and reception times, the factors seen before, add up to a total of only 168 milliseconds, less than 0.2 seconds until which starts to load the web.
Can you have a TTFB of 0, yes, zero? Power is possible, but we will see that later, today we are at the master level, the God level we leave it for another day, okay?
Then the total load time will depend on many other factors, such as GZip compression and other WPO elements that we have seen in previous articles, but a good start is always a good start, right?
Medium TTFB
Another example, in this case of a reasonable Time To First Byte , in the average of what is usually found out there, with normal hosting, where at least they do not spoil the equation, it is something like this:
In this case we already see that the DNS eats itself 179 ms, the SSL certificate also takes its own time, let alone the connection with the server and the waiting and reception time.
The result is that, before even a character / pixel / byte of our website begins to be seen, it has taken your (future) visitor’s browser more than half a second to try to show something of it.
Is it a little, is it a lot? We are at the limit. From there up we enter a dangerous zone.
As a curiosity, the total loading time of the analyzed website was 2.61 seconds, so the website itself only took 2 seconds to load, the rest was the TTFB. What has been said, in the limit of what is reasonable.
Bad TTFB
Bigger words if we already start to see these times of Time To First Byte :
What does it mean? Well, only the TTFB has eaten the optimal loading time that every user expects for the full load of a website, and we have not yet seen a single byte of your site . Terrible .
No matter how much you optimize later, it will be very difficult for you to lose 3.5 or 4 seconds of total load (in the example 4.31 seconds), no matter how much cache plugin and code minimization that you put later.
And even so, the user experience will be bad, as many will abandon the attempt to load your website before they start to see something from your site .
So that later you have to read that WPO does not affect SEO at all, when the reality is that a bad WPO affects SEO very negatively, and vice versa .
Terrible TTFB
We end up with an intractable monster:
Here we have nothing to do. As much as the webmaster has achieved that the total load is less than 5 seconds, despite the fact that more than 3 seconds are eaten by the TTFB, the user experience, the navigation, let alone the conversion, will be bad .
Well yes, something can be done. Change hosting urgently (I have already notified the affected, my friend). And in this there is no cheap or expensive hosting, a cheap hosting that prevents you from growing, converting, even if it is free, is expensive, very expensive . It is costing you time, reputation, money elsewhere.
Where do I check the TTFB of my WordPress?
In addition to the usual speed check 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 each factor that affects the TTFB.
In conclusion
As I think you have seen, the Time To First Byte is one of the most important factors in the load 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 should provide you with the optimal hardware, software and configurations.
- You, who must keep the amount of code to be processed to the absolute minimum.
But most importantly, it is useless if you spend hundreds of hours, thousands of lines of code, plugins and subsequent optimizations, if before starting to load the first byte of your website the client has had to wait 2 or 3 seconds, yes is that it is still there.
Did you like this article? You can’t imagine what you’re missing on YouTube !
