sd2009 wrote:What's the story on "time to first byte"? Everyone seems to think this is important, but you guys don't even mention it? Why not? What's
the story?
Well, "time to first byte" is the amount of time between when a request is made to a server and the first byte of actual data arrives over the HTTP/S connection into the client. This value is indicative of the raw, no-history access speed of a connection.
A lot of monitoring people consider this value, and the "ping time" and the "DNS lookup time" to be the main indicators of accessibility of a site. While these are important speeds, of course, we don't agree that this is the correct metric.
Instead, what we recommend doing is to measure the TOTAL TIME from the instant a request is made until the last byte is delivered to the browser.
This total time is the REAL performance indicator and while it may include the other three low-level measurements it generally is a much larger number. For example, total time for a page might be 1,500 msecs (1.5 secs) whereas the other figures are measured in 10's or 20's of millseconds.
An important factor to remember is that your browser is multi-threaded: a page with several component parts is downloaded in parallel in multiple threads by your browser. There could the 3 or 4 or 5 or more threads running in parallel, each delivering a part of the page asynchronously will the other threads.
If you add up the HTTP/S times for a page -- for example, if you simulate a browser action by downloading all of the individual URLs in sequence -- the total time is MORE than if you let the browser do the work, which it does by issuing multiple threads. This is the reason why we favor the "from the browser" numbers: they are accurate measures of what the user sees in practice. Naturally enough, eValid likes to be accurate.
The eValid Team
by sd2009 » Fri Oct 09, 2009 4:00 pm