Didn't TTFB become popular because back then the start-up/handover time of the request from the server to the URL handler, CGI, FastCGI, etc., was significant depending on the handler's language, ... Far less significant now. Cutting TCP packets with compression is much more useful.
Stop worrying about Time To First Byte (TTFB)
21–30 of 38 posts
Re: Stop worrying about Time To First Byte (TTFB)
#22Earlier quoted context omitted.
On the subject of perceptible latency, supposedly this is why Google's Chrome iPad app feels fast yet is actually slower than Mobile Safari at JavaScript. If you do the UI right, you can hide latency. And Microsoft spoke a lot with Metro about using animations to hide latency. By animating everything, you can hide most of the delay, and only show loading screens when it's a long wait.
supposedly this is why Google's Chrome iPad app feels fast yet is actually slower than Mobile Safari at JavaScript The JavaScript performance fetish has shockingly little relevance to the actual runtime performance, beyond being a loose correlation with "focus on performance". Aside from JavaScript still being relatively trivial, benchmarks focus on the same code running thousands of times, where reality often sees a…
Yep. Safari also performs great in some ridiculous benchmarks (like a personal CSS 3D transforms abuse benchmark), but it's not a very nice browser in real use.
Re: Stop worrying about Time To First Byte (TTFB)
#23But if you have a dynamic webpage, TTFB measures how long it took you to process the page and start outputting results. The rigged server in this test doesn't seem relevant to that case, or am I missing something?
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 modify their TTFB test to require a complete header, so the single-character cheating wouldn't work.
Re: Stop worrying about Time To First Byte (TTFB)
#24I'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…
On the subject of perceptible latency, supposedly this is why Google's Chrome iPad app feels fast yet is actually slower than Mobile Safari at JavaScript. If you do the UI right, you can hide latency. And Microsoft spoke a lot with Metro about using animations to hide latency. By animating everything, you can hide most of the delay, and only show loading screens when it's a long wait.
Do you have a link to the MS talk/article about their work with Metro? I'd be very interested.
Re: Stop worrying about Time To First Byte (TTFB)
#25"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 user in optimized form. Because all requests go through their servers - there's one additional hop. With this hop TTFB increases significantly.
Although I agree that TTFB is actually not that important from end user's perspective, the reason why Cloudflare wrote this article is strictly marketing.
Re: Stop worrying about Time To First Byte (TTFB)
#26There'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 often have to wait for more than the first packet to arrive. (Due to TCP slow-start, this may be another round-trip.) This means they are also waiting longer to start fetching contents.
There's a simple fix for this, which is to call deflate(..., Z_SYNC_FLUSH) on a chunk that is likely to compress to under 1500 bytes, like maybe all of or the first 4k. The total compressed size will be slightly larger, but the tradeoff is usually worth it. Nginx doesn't currently do this, but would be a nice optimization to make available.
It's possible to work around this in Nginx by using the embedded perl module and SSI. After , I use SSI to call perl's $r->flush, which Nginx correctly translates into Z_SYNC_FLUSH. The improvement is small, but measurable.
Re: Stop worrying about Time To First Byte (TTFB)
#27Completely 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 over 20 seconds (search for TTFB in the forums and you'll be shocked). It is usually a combination of shared hosting and excessive database queries by their CMS but it is common enough that completely ignoring it would be a very BAD idea.
Companies like Cloudflare can help the real TTFB (without cheating) by optimizing the conection between the end user and the origin site. Most CDN's call it DSA where they maintain a persistent connection back to the origin and eliminate some of the round trip times. Cloudflare's recently-launched Railgun feature should have a similar benefit.
It's actually a pretty well-known best-practice for web performance to "flush the document early" if you have any expensive back-end processing to do. This isn't cheating and involves sending as much of the HTML content as possible to give the browser a head-start downloading external resources (css, js, etc).
Doing it with just the HTTP headers in order to cheat the metric itself is not in anybody's interest.
Re: Stop worrying about Time To First Byte (TTFB)
#28actually, http headers are not that easy to send. how do you plan to create "content-length" header before rendering whole response?
This is why nginx gzips the body before writing the headers out.
You can use 'chunked_transfer_encoding' to enable chunking, combined with 'proxy_buffering off', your backend can stream the body and nginx will gzip the chunks. Disabling buffering has other consequences, so be sure to read up and experiment before you go to production.
Re: Stop worrying about Time To First Byte (TTFB)
#29Earlier quoted context omitted.
On the subject of perceptible latency, supposedly this is why Google's Chrome iPad app feels fast yet is actually slower than Mobile Safari at JavaScript. If you do the UI right, you can hide latency. And Microsoft spoke a lot with Metro about using animations to hide latency. By animating everything, you can hide most of the delay, and only show loading screens when it's a long wait.
Do you have a link to the MS talk/article about their work with Metro? I'd be very interested.
Oh, er, I don't have a link, but I believe it was from a talk they did at //build about Metro. It shouldn't be too hard to find.
Re: Stop worrying about Time To First Byte (TTFB)
#30I'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…
>>increasingly complex front-end Javascript blocking the browser's UI thread I agree with you, before optimizing the performance somewhere near the HTTP layer there is often much that can be done at the front-end or the back-end level. The loading of web fonts can actually block a browser for some time until the font is loaded (and often makes the page much harder to read ) - it is not just that the user has to wait…
TTFB is terrible data for anyone trying to optimize a website's page load. There are a dozen other easily quantifiable metrics one can easily gather
- page render time server side - time until the user sees something meaningful (you ought to be able to measure this with a headless browser if you have some idea what the first thing you want the user sees) This will get you what people might think they're getting out of the TTFB metric. - full page load latency - data transfer latency
TTFB might be useful if you have some data that suggests your web server is a significant bottleneck, but I wouldn't gather it as a matter of course in trying to optimize page load times.