Hacker News new | past | comments | ask | show | jobs | submit login

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 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.

    > There is no single metric that conveys
    > the user experience (or performance)
True. But if you need to pick one, TTFB isn't as good as something like Speed Index [1]. Getting your TTFB down will usually help you get your content in front of the user faster by, as you say, giving it a head-start on external resources, but that will also show up in the Speed Index.

[1] https://sites.google.com/a/webpagetest.org/docs/using-webpag...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact