Time to first byte: use this network performance metric with caution

Time To First Byte (TTFB) is the time elapsed between the opening of a TCP connection between a client and a server and the receipt by the client of the first packet with payload from the server.

Some performance management software vendors refer to the TTFB metric as Application Response Time (ART), while it is a very poor indicator of application response time. Here are some further explanations.

A common measure

The Time To First Byte is a common network performance measure for two reasons:

1. The first is that it covers a number of possible causes of performance problems. As shown in the diagram above, the Time To First Byte includes a portion of RTT, which provides an indication of network performance. It also includes the server response time (SRT), which is an application performance metric, and connection time (handshake), which can indicate abnormal network latencies or excessive server load. It is, therefore, a general performance metric that will highlight problems of different kinds.
2. The second reason is that it is a relatively easy performance metric to calculate. It does not require correctly managing long sessions, and therefore the particular case of keep-alive packets, which should not be included in the server response time calculations. It is neither necessary to keep heavy memory consuming contexts to separate the different types of packages over time, nor to manage possible interpretation errors of long series of requests and responses.

Relevance

If the Time To First Byte metric has its advantages, what about its relevance in application metrology? As this metric covers different kinds of problems, it should be seen as an overall index of performance, rather than as a metric of server response time, as this is often considered.

HTTP

For a protocol with short sessions such as HTTP, the Time To First Byte seems to be a good metric, the first hit of a web page being crucial since it serves as the root for building the entire page.

Moreover, search engines are suspected of using the TTFB as ranking parameter. This makes TTFB the reference measurement in the web world. But even for the web, the relevance of TTFB is limited. The use of the Keep-Alive header and HTTP 1.1 protocol leaves HTTP connections open to transfers of other data. Therefore, the TTFB only measures the response time of the first hit of the page, without taking into account the multitude of following hits, without which the page is not yet visible or usable by the end-user.

Examples of HTTP performance problems not covered by Time To First Byte include :

• A heavy image to load
• An AJAX call that requires a long server-side SQL request

Another problem of TTFB relevance comes from its popularity in the SEO industry: certain websites or servers artificially cause short TTFB to improve their ranking, even if the real user experience becomes even slower.

Other protocols

If the TTFB quickly reaches its limits for the HTTP protocol, its relevance is even more questionable in case of protocols with long sessions, such as those used for databases or file servers.

SQL

Database servers often use persistent connections because opening sessions on transactional databases can be quite time-consuming. In the best case, the TTFB will be able to calculate the response time to the first request only. At worst, if the sessions are open for very long periods of time, no TTFB measurement will be calculated after the first request.

Here’s an example of a packet analysis on a basic use of a PostgreSQL server. When connecting to the server with the PostgreSQL protocol, the server immediately sends a payload, resulting in one very short TCP TTFB before an SQL query is even sent.

First TTFB on TCP

Let’s assume that the protocol analyzer understands the PostgreSQL network protocol and does not base its TTFB calculation on this initial payload: the first request will then be taken into account, and it alone, whether representative or not of all the exchanges that follow.

(See our series of articles on TCP performance and analysis.)

First quick request

If a long query happens next, it will not be taken into account in the calculation of a TTFB.

Long request (~15s) arriving just next in the same TCP session and that will not be analyzed.

CIFS

As with SQL servers, file servers use long sessions, making the TTFB unusable. Especially if this latter is only based on the TCP layer. Indeed, if we consider the CIFS (SMB) protocol, any connection will generate an authentication dialogue that must be understood by the network analyzer, otherwise, the TTFB will be irrelevant.

In the image above, we see TTFB on TCP calculated while the authentication has not yet been performed and no business request has been executed.

In the same way as for SQL protocols, even if the network analyzer is able to understand the SMB protocol, it will only provide the measurement of the first response, whether representative or not.

References:

[1] http://moz.com/blog/how-website-speed-actually-impacts-search-ranking

[2] http://www.tornadoweb.org/en/stable/networking.html

[3] Search Engine Optimisation

[4] ttfb-time-to-first-byte-considered-meaningless