Performing various tests I observed that the Time To First Byte for the very first resource shown on the graph has always been the longest for my site. Why is that. What’s wrong, what could be improved, and how?
The following test result shows the time as being 207 ms, but often it is even a higher number.
The first byte time is usually slow because of back-end processing that is done to generate the pages themselves (usually the actual guts of the application/site).
207ms is quite a respectable first byte time though. 80ms of that is the round trip time (I usually just look at the socket connect time as a reasonably good barometer of the RTT to the server). The other 130ms is the time it takes your server to process the request and includes forking processes, starting up whatever interpreter the site uses (php, etc assuming it’s not a static HTML file), etc.
If you’re not already doing it, the one place that you have control in the application is to “flush early” and send as much of the document as possible before doing any back-end processing (the document head and beginning of the document if at all possible). Getting much faster from where you are is probably going to be an exercise in tuning the web server and application environment itself (and possibly even switching web server platforms if you can’t get LiteSpeed to where you want it to).
-Pat
Pat, thanks for the valuable feedback. I will be exploring various ways of improving this. I already temporarily disabled my CDN, and asked my host to see if there is any way to address this by tuning up the server. I will also see if I can remove some unneeded code fro m templates, or move things around a bit.
[attachment=91]
The above screenshot shows what I occasionally see, and don’t quite understand. Randomly, the time-to-first-byte can be unusually long even for a static file like a 40 byte small clear.gif (1 pixel by 1 pixel in size).
At the time of the above test, the Server Load Averages were as follows:
0.06 0.04 0.02 | 100 Users Online (3 members and 97 guests)
There could be a couple of causes - if you haven’t already, one good way to track it is to enable response time tracking in your access logs (if you’re on Apache anyway). That way you can see how long the server thinks every request took to process.
Even if the web server itself isn’t overloaded, it’s possible the mysql server is (most hosting providers run the database servers on different machines). Does the 1x1 pixel itself have any code behind it to do logging or is it all taken from the access logs? Or if the files are stored on SAN or NFS it’s possible that there was a hiccup there.
The other possibility is packet loss. If one of the request or response packets get lost you could see a longer time (though usually it’s only really painful for the actual connect time, not the requests themselves since TCP has a better RTT estimate by then).
Pat, thanks a lot. My host is looking into it.
I’m having same problem with wordpress page running nginx + php fastcgi 5.3.6.
I’m running on my home dedicated server so it’s not hosting-hardware fault for sure.
before I added WP-super-cache
http://www.webpagetest.org/result/110406_E7_B80V/
585 ms + 816 ms = 1401ms.
after I added WP-super-cache
http://www.webpagetest.org/result/110406_YV_B820/
it didn’t helped me alot there is still time to first bye 611+ 185 ms = 796ms well it’s alot.
edit:well whenever I type into webpagetest my domain with www so the server doesn’t redirect without www to www the first byte is smaller:
http://www.webpagetest.org/result/110406_AT_B8BM/1/details/cached/
If you can, go enable http keep-alives on your server. It should cut the overall load time in half.
Have you tried W3 Total Cache? At least from feedback I have seen it generally works better than Super Cache (and lets you do more advanced optimizations like combine style sheets and js, etc).
-Pat
comprasion:
with keep-alive enabled:
without keep-alive:
it just reduced load time of first time by 400ms. great 
anything else?;p
What about that CDN and combine 90% for what is it used for?
Yes I had but it didn’t seemed to work at all on nginx maybe I had bad config at nginx (the config was from internet that about cache) or sth I will try that again.
Seems like wp super cache is better:
results:
super cache:
http://www.webpagetest.org/result/110406_KH_BDJ0/
total cache:
http://www.webpagetest.org/result/110406_56_BDHF/
Make sure to run more than a single test because both platforms need to cache the page the first time it is loaded. Also take a lok at the install docs for W3TC because there are a lot more tweaks that you can do beyond just the base page (though that is critical) to have it automatically combine css, etc for you.
Regarding your reply “the one place that you have control in the application is to “flush early” and send as much of the document as possible before doing any back-end processing (the document head and beginning of the document if at all possible)” …
I am not clear how that is accomplished. How do you “flush early”?
Thanks
How to improve Time To First Byte?
Pat
Regarding your message below. We have a site with a 2+ second time to first byte. I have KeepAlive enabled. A “KeepAliveTimeOut 1” Do you recommend another TimeOut value?
Thanks for creating this tool
jbr
[attachment=839]
Can you give some insight regarding the very slow “First Byte” time below?
Typical .html sites and .php sites are typically under 500 ms for first byte on the same server. But database backend sites have this issue.
See attached screenshot …
I am trying to improve my First Time Byte for https://webmastershare.com/ but not sure it’s still low respond
I am using Vultr VPS, the CPU is 3.5Ghz, NVMe disk and website is new. But the FTB still not as good as I want.