First Byte Time “FBT” findings and research results

[Anton Chigurh]

(07-30-2015 11:03 PM)pmeenan Wrote:  Cloudflare is a CDN by any definition. They also do other things but they operate in a pull mode, cache static resources and serve them directly from globally distributed edge nodes.

As far as the target TTFB being unrealistic for CDN's - yes, it's unfortunate and I am considering a few options to make it better but when the base page is served through a CDN it throws off a bunch of the calculations. From the client side, in order to estimate the server processing time you need to remove the network round trip time (usually a function of the distance to the server). Unfortunately with a CDN, the round trip time is to the CDN edge and not the origin server (additionally, if the CDN does not maintain a persistent connection to the origin it may be hiding a DNS lookup and socket connect in the "server time" as well). WPT targets 100ms of server processing time when setting the target (which is totally achievable). In the case of connecting to a CDN I may just put in a fixed 250ms estimated server RTT which is enough to allow the origin to be on the other side of the world and still provide a reasonable target.

Thanks for taking the time to consider this, and it sounds like a reasonable fix. "Achievable" though, as regards to 100ms - almost anything is "achievable" depending on what cost and resources you throw at it. IMO 100ms isn't reasonably achievable for the average, lower skilled type site owner.

Quote:As to images impacting TTFB, in theory and on a well configured server it should have zero impact since the back-end doesn't know or care about the images when serving the html (in most cases). If the server is bandwidth constrained, out of clients to handle responses or otherwise not configured well then it's possible that the image requests for other users is using server resources and slowing down the tested TTFB. If the application logic for the base page actually opens and parses the images before serving the html then that could also cause an impact. In either case the root cause should be addressed rather than optimizing the images to improve TTFB. The images should absolutely still be fixed because that will impact the user experience, your bandwidth, etc - it just shouldn't be targeted for TTFB optimizations.

I only know from what I've seen over the last few years of fixing performance issues for many people which is, with no changes other than eliminating bloat - which is almost always in the images mainly - TTFB improves. I can only speculate and theorize that at some point during the handshake the server "tells" the browser how much in kb, is coming and for whatever reason if it is a big number, this delays the negotiation. Sounds dumb I admit, but as I said I am at a loss to explain the results and observations otherwise. Just like I was only speculating about CDNs causing a really low target FBT time - which as it turns out, you have verified is true.

Quote:it just shouldn't be targeted for TTFB optimizations.

And I don't target it for that reason, have only noticed getting rid of the bloat does have the happy side effect of helping TTFB. I go after the bloat first, because it is among the easiest fixes and best performance boosting things a site owner can do. Not to target TTFB improvement.

All I do for people is try to help them based on what has worked every time it is tried and I try to keep it limited to things I know the average site owner can do. Honestly, I don't go much beyond that because I know I am not qualified to do so. I can give people the basic stuff, the common sense stuff, stuff that always at least helps - but I pretty much stop there.