31–38 of 38 posts
There's an important optimization that Nginx is missing around real-world TTFB, however that would benefit Cloudflare users. Even though it is streaming compression, zlib normally packs compressed content into larger than 1500-byte blocks. Browsers can start parsing gzipped content as soon as they can decompress a block, but they have to wait for a whole block to arrive, which means for gzipped content they will ofte…
Earlier quoted context omitted.
That's exactly their point. They claim most measurement tools will give false results if your web server outputs the headers before processing the actual request data.
In other words, web servers can cheat and look good, so we should just ignore TTFB. If you're not a web server developer, TTFB is quite useful. It tells you how quickly request processing happened. Progressive images can get started quickly. The problem is not with TTFB -- it's that tests that succeed even with "cheating" header responses need to be fixed, if possible, to fail the cheating server. WebPageTest could m…
"At CloudFlare TTFB is not a significant metric." People might think that this article is written to educate masses. The thing is - if you take webpagetest.org and run speed tests with and without Cloudflare, in MANY cases 'Load time' will actually be slower WITH CloudFlare. And the biggest difference will be in TTFB. Why does it happen? Cloudflare works as a proxy, taking HTML from your server and returning it to a…
For more information, see a long comment I wrote on this a while back (note: while reading, remember that a CDN typically has a server very near the end user but not so near as to be on the other end of the last mile of their network connectivity; in essence, they are a reverse proxy solution positioned in the network where a forward proxy would normally go), as well as the response someone left:
Completely ignoring TTFB would be a BAD idea. There is no single metric that conveys the user experience (or performance). Certainly optimizing for 1ms because of the overhead for gzip compression isn't where you should be spending your time but I have dozens of cases in the WebPagetest forums where users have had 5+ second TTFB times and needed help figuring out what was going on. I have even seen cases where it was…
> There is no single metric that conveys
> the user experience (or performance)
[1] https://sites.google.com/a/webpagetest.org/docs/using-webpag...
https://plus.google.com/114552443805676710515/posts/GTWYbYWP...
This is just silly. Time to first byte does matter , when you know what to put in those first bytes. https://plus.google.com/114552443805676710515/posts/GTWYbYWP...
This is just silly. Time to first byte does matter , when you know what to put in those first bytes. https://plus.google.com/114552443805676710515/posts/GTWYbYWP...
I'd guess this minutiae was written in response to some unreferenced critique of their service, in reality nobody with sense would use TTFB as a useful measure of application performance. In fact measuring performance anywhere near the HTTP layer is often pointless when such metrics are so disconnected from what a user actually experiences. Perhaps a better test would be something like "perceptible latency", taking i…
What I would have liked to see was them showing commitment to how they will be IMPROVING the TTFB.
I love Cloudflare but seriously, saying TTFB is not important is just non-sense. Whoever says TTFB doesn't mean anything either doesn't know what they are talking about or they just buying into the hype of cloudflare/cdn services.
Take a look at a "typical" magento store for example: http://www.hybrid-racing.com/store
It has a 1.5 TTFB. This site is slow and no matter what CDN or WPO (front-end optimizations) you do, it will always take 1.5 second page to page.
Only way to speed up this site is switching over to faster hosting, something more preferable like linode's SAS 15K5 RAID10 hosting and/or perform some caching (e.g; full-page caching via varnish).