Time to first byte
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client's browser. This time is made up of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page. Although sometimes misunderstood as a post-DNS calculation, the original calculation of TTFB in networking always includes network latency in measuring the time it takes for a resource to begin loading.
Often, a smaller (faster) TTFB size is seen as a benchmark of a well-configured server application. For example, a lower time to first byte could point to fewer dynamic calculations being performed by the webserver, although this is often due to caching at either the DNS, server, or application level. More commonly, a very low TTFB is observed with statically served web pages, while larger TTFB is often seen with larger, dynamic data requests being pulled from a database.
Uses in web development
Time to first byte is so important that some webpages have forgone eager loading for lazy loading in an attempt to make their content appear to load faster. This is helpful with webpages that have many images and large amounts of data. However, there are several reasons that TTFB can be high:
- database requests are fast but often require post-query logic to format the data for the end user;
- Application programming interfaces used on the server-side can increase overall response time, as is common in restful APIs that process large amounts of data from a database.
TTFB is often used by web search engines like Google and Yahoo to improve search rankings since a website will respond to the request faster and be usable before other websites would be able to. There are downsides to this metric since a web-server can send only the first part of the header before the content is even ready to send to reduce their TTFB. While this may seem deceptive it can be used to inform the user that the webserver is in fact active and will respond with content shortly. There are several reasons why this deception is useful, including that it causes a persistent connection to be created, which results in fewer retry attempts from a browser or user since it has already received a connection and is now preparing for the content download.
The steps for optimizing TTFB are as follows:
- Check your server. For example: If there are complex firewall rules or routing issues then the TTFB time may be huge.
- Check your application.
TTFB vs load time
Load time is how long it takes for a webpage to be loaded and usable by a browser. Often in web page delivery a page is compressed in the Gzip format to make the size of the download smaller. This practice prevents the first byte from being sent until the compression is complete and increases the TTFB significantly. TTFB can go from 100–200 ms to 1000–2000 ms, but the page will load much faster and be ready for the user in a much smaller amount of time. Many websites see a common 5–10× increase in TTFB but a much faster browser response time garnering 20% load-time decrease. There are some drawbacks however in using Gzip compression:
- server CPU load increases during compression.
- data can take a long time to process and since a first byte isn't sent until it's done compressing it can make the webpage appear to be hung.
- long times to first bytes will often cause a user to cancel and reissue their request to the web-server resulting in increased CPU loads because of sequential load requests.
- "TTFB Is Still (And Always Will Be) Meaningless". LittleBizzy. 15 November 2015. Retrieved 2015-11-16.
- "Improving Search Rank by Optimizing Your Time to First Byte". Moz. Retrieved 2016-06-21.