Shared publicly  - 
Cloudflare ran a test and concluded that time to first byte (TTFB) does not matter.. Except, it absolutely does. As they say: if you're experiment contradicts intuition, check your experiment.

The problem is that it's not only the time that matters, but also what's in those first few bytes. If you're smart, then you first packet (1460 bytes), will  be able to flush just enough of your HTML head to allow the browser to begin the parsing and kick off resource prefetching: JavaScript, CSS, etc.

By doing this, while the TCP connection is still going through the slow-start phase, the browser can kick off the connections for blocking resources and consequently make the whole experience much faster.

Cloudflare's test is just silly. Of course it doesn't matter if you flush your '200 OK' after 1ms vs 1s - nothing magical there. But if you know what you're doing and craft the response right, then it can make a huge difference.

TL;DR: Time to First Byte Matters, when you know what to put into those bytes.
Andrea Pernici's profile photoFrédéric Peters's profile photoBrian Jackson's profile photoEpp Krusenvald's profile photo
When compressing the reply one can still flush (Z_SYNC_FLUSH) the compressed stream after the </head> to send the TCP packet, even if it's not full; slightly worse compression over the whole reply but it gets the <head> underway.
I agree with the conclusion that it's important what's in those first packets and we are looking at precisely what we send during the slow start as +Ralph Corderoy suggests. There's a significant difference in how nginx handles gzip vs. uncompressed content and we will be optimizing it. We actually have folks worrying about the packet level stuff to optimize connections and will be rolling out SPDY and other improvements.

The larger message was that there's more to web performance than one metric and we see a lot of people questioning why TTFB isn't where they think it should be without seeing the bigger picture. Although the TTFB server is contrived it illustrates that the metric itself is not what most people think it is... it's not the time it takes for the first useful byte to get to the browser. And so our message was "Stop worrying about that as a metric".

We also think that browser level metrics about the end user experience will be more useful measures. TTFB may turn out to be useful when debugging why end user metrics aren't where people want them to be.
on linux 3.0+ these days you actually get 10 segments in the first burst, that is enough to fit labjs, instructions to download your js assets and a big chunk of your page 
also, in the real world, ttfb - rtt = server time for the vast majority of cases ...
+John Graham-Cumming thanks for the followup. I'm still of the opinion that the article you guys posted is simply traffic bait with wrong conclusions. If you want to be pedantic about the literal "first byte" back to the client then that's a different conversation. However, even there, on a high RTT connection (mobile), doing that first exchange early will help to grow the window sizes - the net effect may not be huge, but still there.

The nginx discussion is orthogonal to the implied conclusion. When and how nginx does compression is an architectural issue for nginx and CloudFlare - nothing more, nothing less. Just because you guys can't currently flush the relevant data early does not meant it's not a useful optimization.

I'm all for "user perceived" metrics and optimizing the end user experience, but TTFB is an important component of that overall metric, and is not to be discounted.

Many large sites (Google, Facebook, Amazon) have been using early flush strategies with great success. Likewise, other content accelerators (like Strangeloop and others), have specific infrastructure to address this same use case transparently (I believe Strangeloop calls theirs "response headstart", or similar).

In other words, to quote your own conclusion: "At CloudFlare TTFB is not a significant metric." That's cool. But that doesn't mean the rest of the industry can't do better.

P.S. Your biggest fan.
I'm going to ponder a follow up blog post on this once we've implemented changes that push data out as early as possible. We want to optimize getting the browser started downloading more assets by pushing out as early as possible.

The larger message (especially to our customer base) was that obsessing about TTFB as they see measured from some web measuring service isn't helpful. There are so many factors that are involved in that number (nginx ones that I mentioned, network latency, where the testing is done from) that the data is very blurred.

The doesn't mean we don't believe that optimizing the time we get the page out on the server doesn't matter. We do.
+John Graham-Cumming While you ponder your follow-up post please you can think about the following too:

1. If you're going to post a test, document the test environment so that at least we can see quickly if it makes sense e.g. CPU, RAM, OS, HTTP daemon, VM vs real HW, test on a single server vs on local LAN vs internet - basically the stuff +Baron Schwartz covered in his  #VelocityConf  talk

2. Can you run the test multiple times so that we don't have a single result that could be adversely affected by all sorts of things - warm the test up and then measure for a period.

 3. Can you test it with more that one HTTP daemon before declaring it doesn't matter
Ha! I discontinued using Cloudflare partly because of high TTFB. My TTFB was about 2 times as much when compared to runing direct EC2.

My website also runs Nginx. Thier "tests" are simply in an effort to justify the poor TTFB and maybe convince others into not taking it seriously? I also found even though the pages loaded a tad faster with Cloudflare, Google's WMT page speed actually increased over time instead of decreasing.

But hey, at least I got a free t-shirt out of the whole thing! lol
If TTFB is important for Google regarding SEO, so it should be important for webmasters ; is it TTFB google considers?
Ilya I can see you work in Google ; I have been accepted in Google Page Speed Service Beta. Is it worth to try it instead of Cloudflare? My website is hosted in Germany but my visitors are at 70% from France so I want to speed loading time.
+Vincent Abry don't worry about what Google considers.. anything that makes the experience better for your users is what you should be after - the rest will automatically fall into place. With that in mind, faster response times do lead to better user experience! Re: CloudFlare or PageSpeed Service.. that's your call, but I can definitely vouch for good performance with PSS - my own site is on it.
thank you +Ilya Grigorik. Yes I meant this is primary for users for sure, but as my website was affected by Panda 7 months ago (-68% trafic) I am working on all criteria, including loading time and geolocation. After Google answered me twice my site was not manually penalized, I asked help from several guys with 10 years in experience in SEO and nobody was able to find something critical on my site. So now loading time is my last fight, after I will continue to write as usual and if the algorithm (hoping I'm not a collateral damage) doesn't want me back to business, I will have to stop this blog (started in jan 2006) and do something else.
I just saw you are the man behind Postrank, this is amazing, I am hoping this service come back one day in my Google Reader (is it equivalent to "Sort by Magic"?) because it was one of the best tools ever. It was so easier to watch most important news. 
Serendipitously, I’ve just been looking into what can be flushed and when for a client’s legacy web-site. My conclusion is it’s as much of a mess as the implementation language; PHP, not my normal fare. :-) Running under Apache with libphp5, it has mod_deflate taking PHP’s output. PHP’s ob_flush() and flush() only push as far as deflate where the data then sits. mod_deflate can be told to flush but no interface exists from PHP under libphp5. TTFB seems therefore out of reach.

Further, there are cases where PHP has work to do after mod_deflate has the whole page. In Unix terms, one wants to close(2) the write-end of the pipe so the reader sees EOF. Again, no interface exists to do this under libphp5. Only when the script finishes does deflate know no more can arrive. There is some hope; if one switches to running PHP under Apache and FastCGI with PHP-FPM then fastcgi_finish_request() is available. Still doesn’t help with TTFB though.

(Knowing C, Perl, Python, and now Go, I’ve avoided PHP for years through prejudice. Until now. It’s everything I feared. All the beauty of Perl with none of the power. And it seems to have largely dragged down the quality of the ecosystem around it.)
+Vincent Abry loading time will not save you from your traffic loss.
Don't look only at your website, but study the big picture cause probably in the latest years something changed.
TTFB may maybe help for SEO ... "ceteris paribus". If Google decide to rank better a site, you can be 5 times faster, the site google decided to promote will still rank better. We have enough elements to show Google make penalties to some websites and rank better website doing spamdexing. The HomeAway group buy backlinks and there is no sanction. Maybe because Google Ventures put money in that company ? We still investigate and will publish a report on that soon.
Damn, all of this gave me a head ache. There are so controversial opinions on whether TTFP makes a difference or not...I've even been battling myself in trying to understand if TTFP plays a role in Google search ranks or not as some say it definitely does while others say it has no importance what-so-ever. Well, the least I got to do for my site, was that I simply decided to choose a faster theme for my site (it runs on Wordpress). As I took the speed for the main aspect for my site, I found the best theme from here: - the only place I found to have TTFP and speed index pointed out. It seems to have worked as my bounce rate is much lower. In the end, even if you're not very tech-savy, the change is only good. Thanks for clearing this topic a bit!
Add a comment...