If you use tools to measure the performance of your website like Pingdom Tools, GTMetrix and others you will have seen a parameter called Time To First Byte abbreviated TTFB and translated would be Time Until the First Byte . But do you know what it means? Can we improve the result it offers?
In this article we are going to see what is this Time To First Byte what affects you and how to improve your results, how to optimize it .
Because the TTFB is one of the parameters that add load time to your website, sometimes more than reasonable. We will see why and how to improve it
What is Time To First Byte?
Without getting too great, so that anyone can understand it, we will say that is the time that passes from that you click on a link or type in the URL of a web until it starts 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 you visit a resource / url of your website but every time a new resource / url is requested affecting notably to the perception of performance and usability of your site, either positively or negatively.
As you may have guessed, the first thing to be clear is that:
- 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
- ] Configuration and performance of the server (PHP and web server)
- Plugins / WordPress theme
- If the HTML cache is active / inactive
Each of these factors add delay to the TTFB of your site, of each requested resource of your site, not just one, but the set of all of them.
With this I want to tell you that you should not focus on improving only one or two of these factors, but you should optimize them all ] because the user experience will be affected by the sum of all of them.
Anyway, we will explain how each one of these factors affects and how to optimize them .
Response time of the DNS
The DNS response (name server) domain) is the first factor of 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.  Therefore, a good way to reduce the TTFB in this factor is to use a CDN service like CloudFlare, which basically cache 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 web.
Configuration and performance of the server (PHP and web server)
The second step in the response time of the TTFB is the server, WordPress hosting where you have hosted your site . The type of server configuration you use and your cache systems will greatly reduce the TTFB.
A simple example to understand is that if you use an older version of software, such as PHP 5.4, you will get a much higher TTFB than if you were using  PHP 7.1, which reduces the response time by half or more .
This is because the PHP interpreter plays an important role in this process. Each time a page that is not in cache is requested, the server will have to process the PHP files required to convert them into HTML format and that 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 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 cache PHP will reduce the times of each second request, offering in this second visit to each resource the cached version of the file instead of having to re-process all the PHP .
Therefore, it is vital that your hosting offers machines fast and optimized, with updated software and server caching services that improve the response of your web.
In WordPress Help we have this very clear and therefore we rely on SiteGround to host the blog and all other websites and services because SiteGround offers optimized and specialized hosting in WordPress, with SSDs, latest generation hardware, own caching services and specific tools for WordPress.
If you want enjoy yourself also the same quality hosting using WordPress or Yoast Help here you have a discount to try it out and see the difference .
Plugins / WordPress theme
The third factor that affects the TTFB is already your site, in our case WordPress. And it is not a minor factor, rather the opposite, is one of the most important and on which we have more potential for improvement without the help of others.
As we saw in WordPress loading sequence this hosts various PHP files that are being processed, and the more complex the longer they take to process.
But also, our site is usually powered by plugins, and those plugins add more code to PHP total to be processed .
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 is incremented.
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 ultimately size does matter .
Although it is true that 10 optimized plugins will generate fewer requests and needs e processing that 1 badly programmed, at the end each line of code counts, take it into account and use / install / activate only what is strictly necessary for your website .
When you do not control this you can reach a point in which you have so many plugins installed, even those that are optimized, that damage the loading time of your site, just the opposite of what you were looking for.
This has been proven by many users when installing plugins such as W3 Total Cache and Check that your web was slower despite caching part of the code, and that 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 the HTML cache is active / inactive
The last factor is the most important and it has to do with the cache system you choose to use in your WordPress installation.
Fortunately the solution is also Also simple, you just need a good cache plugin like SG Optimizer to serve as HTML all the code and processes of your installation and to do it from the server, without affecting to your installation / plugins / theme.
In this way is your hosting, who caches all your content and processes from the server.
How can it be otherwise, any redirection, to be of server, transparent, or whatever type, will affect the TTFB because it is an additional "section" that must be navigated by the browser before showing our website .
Not to mention if they are cross-domain redirects, of changes of permalinks, etc.
Of course, remember that each URL has its own TTFB, so that the redirections of specific inputs also affect the waiting times.
And yes, also HTTPS is a redirect because all traffic is redirected from HTTP to HTTPS, and also negatively affects (in little) the TTFB. Fortunately compensates in this case, by 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.
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 cache:
And yes, you guessed right, it's WordPress Help.
As you can see, despite the time of wait (latency) that adds the SSL certificate, which always adds something, the waiting and reception times, the factors previously seen, total in only 168 milliseconds, less than 0.2 seconds until the web starts loading.  Can you have a TTFB of 0, yes, zero? To be able, but that already we will see it later, today we are at the master level, the God level we leave it for another day, right?
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?
Another example, in this case of a Time To First Byte reasonable, in the average of what is usually found out there, with normal hosting, where at least they do not spoil the equation, it goes something like this:
In this case we already see that the DNS eats the alone 179 ms, the SSL certificate also takes its time, let alone the connection with the server and the waiting and reception time.
The result is that, before starting to see a character / pixel / byte of our web already the browser of your (future) visitor has taken more than half a second to try to show lgo of it.
Is it little, is it a lot? We are in the limit. From there up we enter the dangerous zone.
As a curiosity, the total load time of the web analyzed was 2.61 seconds, so the web itself only took 2 seconds to load, the rest It was the TTFB. I said, in the limit of what is reasonable
Major words if we already started to see these times of Time To First Byte :
What it means? Well since s or the TTFB has eaten the optimal load time that every user waits for the total load of a web, and we have not seen even a single byte of your site . Terrible .
As much as you optimize then, it will be very difficult to download 3.5 or 4 seconds of load l (in the example 4.31 sg), by much plugin cache and minimization of code that you get later.
And still, the user experience will be bad, because many will abandon the attempt to load your website before they start to see something of your site
So that later one has to read that the WPO does not affect the SEO at all, when the reality is that a bad WPO affects SEO very negatively, and vice versa .
We ended up with an intractable monster:
Here we do not have anything to do. As much as the webmaster has achieved that the total load is less than 5 sg, although 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's free is expensive, very expensive . It's costing you time, reputation, money elsewhere
Where do I check the TTFB of my WordPress?
Also give in the usual speed check and web optimization services like Pindgom Tools GTMetrix and WebPageTest there is a specific site to check only this parameter, Byte Check which gives you very clearly and visually each factor that affects the TTFB
As I think you've checked, the Time To First Byte is one of the most important factors in loading your website and the factors that they affect it are few, but important.
And, summarizing, there are two major actors involved:
- Your hosting, which should provide you with the best hardware, software and configurations.
- You, that you must maintain the amount of code to process to the minimum necessary.  But most importantly, it is useless to use hundreds of hours, thousands of lines of code, plugins and optimizations afterwards, if before starting to load the first byte of your website the client had to wait 2 or 3 seconds , if it's still there.