What is TTFB (Time To First Byte)

TTFB (Time To First Byte) measures the time that a network component (such as a server) takes to return the first byte requested by a user (for example a user’s browser).

You might think that, in practice, this metric indicates a server’s response speed in delivering website content. And you would be right, but things are slightly more complex due to various factors.

[divilifeshortcode id=’9530′]

TTFB: the result of many factors

First, it must be said that TTFB is the result of several factors:

• The time a client request needs (eg browser request for a page) to reach the web server: here DNS resolution times and latency due to distance can cause delays;

• The time a web server needs to process the request and give a response: various factors come into play here, from the level of code optimisation, presence or absence of caching mechanisms, to server performance at the hardware level (hard disk, memory, etc.);
• The time it takes to the web server to respond and reach the requesting client: here the times essentially depend on the network connection speed.

It is important to clarify this aspect since often servers and CDNs are configured to provide the famous « first byte » in a short time, only to return the rest of the data with a certain delay due to latency. How can we put it…a good beginning does not necessarily make for a good ending!

Acting decisively on these three aspects requires acting on several fronts, we will analyse this in the next paragraphs.

How to measure TTFB: tools for testing

There are several ways to measure TTFB and it is possible to find numerous testing tools on the Internet. If we use Chrome as a browser, Google offers us an immediate solution, which in the Developer Tools > Network section also allows us to measure the parameters determining TTFB.

However, it must be said that this type of measurement, being performed on the client side, is also influenced by connection speed. Other tools performing the server-to-server test are therefore more reliable.

Among other things, some of these tools allow you to run the test by simulating a request coming from different locations and they assess the results, based on parameters suggested by Google Pagespeed Insights: a value below 200 ms is recommended, while it becomes optimal if below 100 ms.

Here are some of the most popular tools to measure TTFB:

• Pingdom
• GTMetrix
• WebPageTest
• GeekFlare
• Bytecheck

Is TTFB a ranking factor?

Whether and to what extent TTFB is a ranking factor for search engines has long been discussed. So much so that some of the main IT service providers (CloudFlare) and SEO optimisation platforms (Moz), but also some engineers in Google itself, fuelled the debate with articles very well argued and supported by data that led them to opposite conclusions.

In fact, if it has been established for some years (also because Google itself has stated this forcefully) that the loading time of a web page is a decisive factor for ranking, as it is a fundamental for user experience; however, understanding how much in this context TTFB is considered influential, judging from these sources, it is not easy at all.

To those who give TTFB a decisive value, Grigorik, a Google’s Performance Engineer, replied that a low TTFB is not enough to determine a good pagespeed score if the rest of the elements of the page are not optimised and load slowly. This is especially true in cases where the server responds very quickly by resetting the HTML header of the page, only to send all the resources (CSS, JS, images, videos…) with a certain delay after.

Rewarding the best user experience

Of course, this is not enough, but the path traced by Google is now clear: rewarding those who offer the best user experience, which translated into more concrete terms means rewarding those who offer quality content and smooth and fast navigation.

To draw a first conclusion, necessary to move forward, let us focus on the few but important certainties we have: regardless of how much TTFB directly reflects on positioning, this parameter contributes (together with others) to determining the overall loading speed and therefore to influencing user experience.

It is therefore worth taking all the possible measures to ensure that also, but not only, this value is as low as possible. How? We will tackle this in the next paragraph.

How to reduce server response time?

As we have said, TTFB is influenced by many factors concerning the infrastructure at the hardware, software and configuration levels of its various components.

We briefly list the interventions that can be made to optimise our infrastructure and lower not only TTFB but also the overall loading time, increasing the speed of the site.

• Hardware performance: capacity and speed of disks and memories when it comes to traffic are the first elements to affect a server’s response speed. Assess if an upgrade is appropriate.
• Hosting server configurations: check with your IT department or provider that the server is optimised to respond as quickly as possible.
• Database configuration: As with the server, database configuration can have a significant impact on query times. Optimise if necessary.

• Enable server-side caching: using a caching system at server level makes it possible to reduce the number of requests and thus its possible overload, helping to reduce TTFB.
• CDN: the CDN allows you to optimise server response times both by distributing content from the closest node geographically (latency reduction), and through cache management and optimisation (weight reduction) of static objects (JS, CSS, images …).

Precisely on this last and decisive point, Aritmetika has worked alongside important development partners to create iSmartFrame, a solution able to optimise resources at unparalleled levels on the market. Not just that, the iSmartFrame solution, in addition to optimising resources and drastically reducing loading times, also performs numerous technical SEO optimisations without touching the source code.