Speeding up your web site can be tough. The developers blame the system administrators, the system admins blame the code, the marketing team insists on their detailed tracking scripts be included on every page. One way to help sift through this infighting is metrics. A key metric, at least from the server side, is Time to First Byte(TTFB). This is a quick overview of how to interpret the Time to First Byte and where to look to improve this metric. This is one of the first steps we try to optimize server performance.
What is the Time to First Byte?
When your browser connects to a web server, the browser must execute a number of steps. These can be broken down into:
- DNS Lookup
- Initial Connection
- Waiting
- Receiving Data
- Closing Connection
The Time to First Byte (TTFB) is the time your browser spends waiting on the web server to send back the data.
Testing TTFB
Web performance testing is beyond the scope of this article, but you can check out WebPageTest.org, BrowserMob or some of our other tips on how to speed up your web site.
“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 first byte number. If you have a complex application, then waiting 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.
TTFB Rules
This is a gross simplification but something I generally use during the first steps toward optimizing a site.
If your TTFB for static content is high, then you may have reached the hardware/configuration limits of your server.
If your TTFB for your static content is low but dynamic content is high, then your application or server configuration may be to blame.
These are some simple guidelines we use for performance work. If we find a server with little load and fast static content but slow dynamic content, configuration changes to Apache, MySQL and PHP (or other language) may help.
If these configuration changes do not help, then the bottleneck may be in the code itself. In this case, you may need to consider profiling your application.
Server, Hosting and TTFB
If your site is slow, your hosting provider may or may not be to blame.
Using TTFB can help you pinpoint where the “slow” part of your site is coming from. If you find your TTFB numbers are great but your pages are still slow, then your hosting provider may not be at fault. Third party includes, poor site design, programming or other non-hosting specific elements may come into play.
On the flip side, if you find that your TTFB is incredibly long for static content, then you may want to dig into the hosting environment. Perhaps you have maxed out your hardware or there are configuration changes required to get better results.
Once again, this is a gross simplification but is where we start when handling the initial steps of performance issues.
TTFB Summed Up
The Time to First Byte is a key measure when evaluating a site performance. Using metrics like TTFB and others replaces the subjective “the site is slow” with hard data. With this hard data, you can begin to better understand and fine tune your web site’s performance.