Time To First Byte
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.
Why it is important for a low TTFB
TTFB is often used by web search engines like Google and Yahoo to improve search rankings since your website will respond to the request faster and be usable before other websites would be able too. There are downsides to this metric since a webserver can send only the first part of the header before the content is even ready to send to reduce their TTFB. While this may make 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 less 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
2. Check your application
As for reducing the TTFB for Joomla, make sure you enable caching (beware though, Joomla's caching comes at an expense).
TTFB vs Load Time
Load time is how long it takes for a webpage to be loaded and usable by a browser. Often time in web page delivery a page is compressed in the Gzip format to make the size of the download smaller. This practices prevents the first byte from being sent until the compression is complete and increases the TTFB significantly. TTFB can go from 1-2ms to 100-200ms 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-10x 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 webserver resulting in increased CPU loads because of sequential load requests.
- "TTFB Is Still (And Always Will Be) Meaningless". LittleBizzy. 2015-11-15. Retrieved 2015-11-16.