How Time to First Byte Impacts Web Performance

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, 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.

The following two tabs change content below.
Jeff is the CEO and founder of rackAID. He has been working in hosting industry since the days of Rackshack's famed customer appreciation parties back in the early 2000's. Jeff is an avid cyclist, wine enthusiast, and admitted Kraftwerk listener (please don't hold that against him). You may spot him at any number of hosting, startup and small business conferences


  • Luke Brookhart November 10, 2011 at 1:43 am

    At Onjax, as an Saas (software as a service) provider, we take application speed very seriously. RackAID has been instrumental in giving us great feedback and assistance to us help in this area. Great article. Thanks for sharing!

  • Marcus March 3, 2012 at 9:44 am

    Many thanks for the explanation of First Byte Time.

  • Igor May 22, 2012 at 11:06 am

    Thank you for detailed explanation of what “first byte” term is. Our client site loads too slow with 20s first byte load. We are trying to figure out what is going on there. Hopefully the

  • Jeffrey Huckaby May 24, 2012 at 10:53 am

    @Igor 20s is certainly too long.  This is typically due to a bottleneck on the web server. You likely have limited resources or a poorly designed script.

  • toan July 2, 2012 at 11:05 am

    i’m not sure does it have to do with location as well? if my server is in the east coast and i’m surfing in the west coast my byte time is slow >1 second
    my site is

    if it is the host server that is slow, what can i ask of them? my host is nexuses which has a lot of ram but I’m on a shared environment.

  • Rahul March 16, 2013 at 9:08 am

    Great post! My first byte time comes to about 150 ms. It improved dramatically when I moved from shared to VPS hosting.

  • balu May 2, 2014 at 8:04 am

    Slow Responses is 4 m 40.35 s this means whst? and 4m what is this M means Metrics or minutes? plz clarify me

    • Jeff Huckaby May 2, 2014 at 1:43 pm

      4 m 40.35 is 4 minutes and 40.35 seconds. The important number on WebPageTest to focus on is start render. That is when the page will start to be displayed to the customer. Anything less than 1s can impact traffic negatively.

  • Alain June 27, 2014 at 5:15 pm

    Dear colleagues,

    I am experiencing 3,3 seconds to load the first byte. We opimized the webshop and acheived in gt metrix page speed grade A 93% and y slow grade B 81%. I want to know what is the cause of this disappointing result :-( Is it a underperfoming hosting server or is it a MYSQL problem?

    Does somebody recommend a tool which I can use to investigate this problem so I can determine the cause and I can finally get this problem fixed?

    Thanks in advance,

    Kind regards,


    • Jeff Huckaby June 30, 2014 at 10:34 am

      I recommend you try NewRelic. Should be able to help you pinpoint where the slow down occurs.

  • Alain August 21, 2014 at 9:46 am

    Hi Jeff,

    Thanks, guess I’ve missed a notification of your message. We will be moving the webshop to The shop performed zero dot fifty five 0,55 sec server response :-) :-)

    Thanks I will look to the software, might come in handy for the future.