Time to first byte is a measurement used as an indication of the responsiveness of a webserver or other network resource. 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 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.
Time to first byte is important to a webpage since it indicates pages that load slowly due to server-side calculations that might be better served as client-side scripting. Often this includes simple scripts and calculations like transitioning images that aren't gifs and are transitioned using JavaScript to modify their transparency levels. This can often speed up a website by downloading multiple smaller images through sockets instead of one large image. However this technique is more intensive on the client's computer and on older PCs can slow the webpage down when actually rendering. 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;
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.
Load time is how long it takes for a webpage to be loaded and usable by a browser. Often in web pagedelivery 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.
