The Time To First Byte (TTFB) expresses, in milliseconds, the time a server takes to respond. It is taken into account by Google and other search engines to assess the speed at which content will be available. So, as you’ve probably understood, it is an important indicator for your loading times, and also one that counts for your SEO.
A metric that assesses what you don’t yet see
When an internet user visits your website, the browser requests information from a server (an origin server, possibly far away, a CDN server, etc.), which then sends it to the browser to display the elements that must appear on the page. That time it takes for the server to send the first byte to the browser is the Time To First Byte (TTFB) —not to be confused with Start Render or First Contentful Paint, which indicates the moment when the first element appears on the page, as we saw in the previous section.
In other words, the Time To First Byte (TTFB) indicates the server’s responsiveness when handling an HTTP request, which takes place in several stages, including network latency:
- establishment of the network connection
- secure connection handshake (TLS)
- sending of the HTTP request
- sending of the page’s first byte.
The faster the process, the sooner the browser is informed of the fact that the server is indeed active and will send a response. Otherwise, the browser will wait for a response until it times out, a point set by the browser.
If the page cannot be retrieved, here are examples of the error messages that may be generated:
- 401 – Unauthorized: the page is password-protected
- 403 – Forbidden: the server received the request, but refuses to process it (for example, because the password is wrong)
- 404 – Not found: the page cannot be found, either because of an error in the URL or because the page does not exist
- 500 – Internal error: the server encountered a problem
- 503 – Service unavailable: the service is temporarily unavailable (this may happen during peak loads)
Why is the Time To First Byte (TTFB) important?
It helps detect application slowdowns (databases, search engines, microservices, etc.).
The server response time is directly linked to the speed at which data is retrieved by the browser. Additionally, if there’s a long server response time, the website’s fluidity is affected, the browsing experience is harmed, your users will be frustrated by having to wait for the page to load, and they may end up leaving if it takes too long—at best, without having read or bought anything and, at worst, to turn to one of your competitors.
Server response time is connected to SEO
The server response time is an important criterion for your search rankings. Indeed, besides affecting the page’s loading time, the faster your server responds, the more the Google robots will be able to easily crawl your pages. While we can’t say there’s a direct link between web performance and SEO ranking, we have seen a correlation between a website’s speed and the number of pages crawled, as demonstrated, for example, by Rue Du Commerce (case study in French). What’s more, Google recommends that the Time To First Byte (TTFB) not be longer than 200 ms.
How do you analyse the Time To First Byte?
Time To First Byte (TTFB) depends on the servers’ capacity and the internet connection. For one-off tracking, we recommend using WebPageTest. For daily tracking, we recommend using Pingdom, which allows you to check response times from all over the world by sending “pings” at regular intervals.
Where do you stand?
Lighthouse says that a Time To First Byte (TTFB) is abnormally high at 600 ms or longer, but... says that a Time To First Byte (TTFB) below 200 ms is good. Ideally, it should be less than 100 ms.
That said, these reference values must be viewed according to what you’re measuring. For a web page, having a good Time To First Byte (TTFB) is important for the perceived speed. For an individual resource, it all depends on the criticality of the resource in question—it is less important to reduce the Time To First Byte (TTFB) for less critical resources.
If you are a publisher of third-party scripts, you should work relentlessly on your Time To First Byte (TTFB) because your script impacts the loading times of many sites!
What hurts the Time To First Byte?
Dynamic content
While it’s essential, one of Time To First Byte (TTFB) greatest enemies is dynamic content (personalised content inserted by the server, database requests, requests from the server to third-party services, etc.)! Why? Because the main problem of dynamic content is that the more there is, the more the page has to retrieve from databases and/or by sending requests to third-party services. Having lots of these data requests slows down server response times: each step adds milliseconds to your loading times.
Furthermore, generating pages with lots of data requires calculation by the server, which also slows down page loading.
Peaks in traffic
Tab's peaks can saturate your server and lead to an increased Time To First Byte (TTFB). Changes in this indicator can also alert you to potential loading problems. Some practical advice: in case of a peak load, make sure to have in place an overflow page to maintain the browsing experience.
API calls
API calls can also hurt the Time To First Byte (TTFB), especially when it involves processing large volumes of data.
Your server’s configuration
Your server’s configuration can affect the Time To First Byte (TTFB). The more settings and conditions there are to take into account, the more time your server will need to perform its calculations. For example, processing requests from databases for formatting intended for the end user can slow down page loading.
How can you improve your Time To First Byte?
Optimize the configuration of your server
Depending on the configuration of your application server, you can improve your TTFB. As we’ve seen, the fewer calculations the server has to make, the faster it can respond to the browser. So, to maintain your server response time, keep things simple.
Cache your data
At the HTTP or application level, putting content in a cache saves time for your server. It reduces the requests to retrieve data since the browser can more quickly access pre-built elements via the cache. That way, the browser can more quickly get a ready-to-use HTML file.
Take into account the advantages, but also the limits, of lazy-loading
To send information as fast as possible to the browser, you can make smart use of the lazy-loading technique. It can be useful for pages that have a lot of dynamic content. Without lazy-loading, that content would be included in the HTML page, which would affect the TTFB.
However, lazy-loading can be counterproductive if it applies to too many page assets because it wouldn’t make much of a difference compared to a page without lazy-loading that would take a while to load.
Compress, but do so carefully
The more you compress your data, the less time they take to move from your server to the browser. With the GZIP and Brotli formats, you reduce the size of files, making them lighter to transport. However, you have to account for a particular factor: the CPU time and power needed for compression. Indeed, until the file is completely compressed, not a single byte will be sent to the browser, thus pushing back your Time To First Byte (TTFB).
So, a high level of compression allows you to serve the page to the user faster, but the server response time may be negatively impacted. Conversely, you may have a very short server response time, but data that need a long time to display. Thus, you have to strike a balance between all of the parameters.
In general, like successfully cooking a recipe, the effectiveness of web performance optimizations depends on getting just the right amounts of the different ingredients. Each action carried out to support one indicator can have effects on other indicators. That’s why optimizations must be smartly combined to work well; that’s also one of the many advantages of our engine.
Learn more about how Fasterize engine works,
and how our features work together to improve your web performance:
