What is Time To First Byte?
>>Time To First Byte ( TTFB ) is often used as a measure of how quickly a web server responds to a request and common web testing services report it. The faster it is the better the web server.
>>TTFB helps enterprises identify weak points in the connection process. By determining where delays occur, enterprises can tweak their services to perform faster and more reliably. Since a website’s speed can impact its web search rankings, TTFB has become crucial to optimizing performance and increasing visibility.
WHAT AFFECTS TIME TO FIRST BYTE?
>>TTFB is impacted by three key actions:
1) sending a request from a client machine to the server
2) processing that request on the server and generating a response, and
3) sending the response from the server to the client.
Action 1: Sending a request to the server
Measuring TTFB begins with the request. The time it takes for a server to receive a request can vary based on the time it takes to perform a DNS lookup, the speed of the user’s network, the distance to the server, and any interruptions in the connection. Enterprises have no control over the link between the user and the Internet, but any delays will still impact their TTFB.
Action 2: Processing and generating the response
Once a server receives a request, it has to generate a response. This involves starting processes, making database calls, running web scripts and communicating with other systems on the network. Common strategies used by enterprises to reduce TTFB include caching web pages, optimizing server-side code, and improving hardware resources.
Action 3: Sending the response back to the client
Once a server generates a response, it needs to transmit it back to the user. This step is dependent on both the enterprise’s connection speed and the user’s connection speed. The TTFB is determined the moment the client begins receiving the response, literally when the client receives the first byte. Transmitting a request and a response over a network can account for almost 40% of the TTFB.
Action 1: Sending a request to the server
Measuring TTFB begins with the request. The time it takes for a server to receive a request can vary based on the time it takes to perform a DNS lookup, the speed of the user’s network, the distance to the server, and any interruptions in the connection. Enterprises have no control over the link between the user and the Internet, but any delays will still impact their TTFB.
Action 2: Processing and generating the response
Once a server receives a request, it has to generate a response. This involves starting processes, making database calls, running web scripts and communicating with other systems on the network. Common strategies used by enterprises to reduce TTFB include caching web pages, optimizing server-side code, and improving hardware resources.
Action 3: Sending the response back to the client
Once a server generates a response, it needs to transmit it back to the user. This step is dependent on both the enterprise’s connection speed and the user’s connection speed. The TTFB is determined the moment the client begins receiving the response, literally when the client receives the first byte. Transmitting a request and a response over a network can account for almost 40% of the TTFB.
TTFB Numbers
“Good” TTFB Numbers
On a well operating system, the TTFB can be under 100 milliseconds (ms) for static content such as HTML, images, CSS, and javascript files. These low numbers make sense if you consider what happens on the server side. The web server simply has to open a file, which may be in the file cache, and send it to the client. This process is very fast.
For dynamic content, the TTFB is often 200-500ms. The longer numbers reflect what is happening behind the scenes. Consider a WordPress Blog. When you make a request, the PHP scripts have to open a number of include files, make a connection to the database, parse the results, and send back the final HTML document. All of this takes time. So even on a well powered, lightly loaded system, TTFB numbers will almost always be higher for dynamic content than static content.
“Bad” TTFB Numbers
For static content, if your TTFB is more than a few hundred milliseconds, you may have some bottlenecks on your server. This could be your HTTP server not able to handle requests fast enough. Many servers will accept a connection and then hold it until it is ready to process. This backlog of requests can slow down the response time.
Another common issue with poor Time to First Byte numbers is disk IO. If your disk IO is slow, then the system may take longer than desired to open up a file and send it. Faster disks may help this situation, but you may also want to consider more RAM. More RAM may allow more files to be held in the internal file cache and lower disk IO.
For dynamic content, you cannot really define a global “bad” time to the first-byte number. If you have a complex application, then waiting for 1-2s may be reasonable. While we like things to be faster, setting a real-world expectation for your application is important.
If your dynamic content’s Time to First Byte is longer than desired, you first want to check some hardware metrics, such as:
- Disk IO
- Swap Usage
- RAM Usage
- Network Bottlenecks
If you find your server’s hardware is adequate, then the configuration of your server could be the problem. You will want to systematically review:
- Apache (web server) Configuration
- PHP Settings
- MySQL Settings
- Network Settings
If you are making calls to remote networks or services, checking into the latency of those systems is required as well.
BENEFITS OF OPTIMIZING TIME TO FIRST BYTE
Optimizing TTFB benefits both users and content providers.
Users see an improved browsing experience since they have to spend less time waiting for a web service to generate a response.
Enterprises see higher customer engagement and retention as users are less likely to leave due to delays or slow loading times.
-----xxxx-----
