Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop worrying about Time To First Byte (TTFB)

blog.cloudflare.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Stop worrying about Time To First Byte (TTFB)

#11

Post by bad_user »

infinity wrote: post #8
henrikschroder wrote: post #4

But 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?

In the article it was examined what some of the tests for page load speed measure as TTFB: The tests measure the time until the arrival of the first character of the HTTP headers. When using a dynamically generated page it is possible to send the HTTP headers, then maybe send some some content and then do some server side calculations or database access, and finally send the rest of the page content. The TTFB measure…

Not many web frameworks are configured to start writing the response before the response is actually ready.

This is because when sending the response you need to know the HTTP status of that response. Is it a redirect? And if you're querying the database lazily, after your page started to render, what about DB errors that could happen? Then you'd need to send an HTTP 500.

This is the drawback of using this feature in Rails 3. You have to ensure that there's no way something unpredictable happens. And you have to activate the feature explicitly in your controllers. And after you did that, you're probably going to be aware that TTFB is not that relevant.

Re: Stop worrying about Time To First Byte (TTFB)

#12

Post by TazeTSchnitzel »

forgotusername wrote: post #6

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…

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.

Re: Stop worrying about Time To First Byte (TTFB)

#13

Post by saetaes »

One thing that's interesting is that the Navigation Timing API available in modern browsers varies from being wildly incorrect to accurate, depending on the browser. In a quick test on my Mac, Firefox 13 showed an incorrect result (basically, the same issue as WPT and Gomez - almost immediate TTFB), while Chrome 20 correctly detected the 10s TTFB.

Re: Stop worrying about Time To First Byte (TTFB)

#15

Post by xpose2000 »

I am glad that TTFB worries have been debunked by cloudflare. However, more issues still linger:

1) Response times, in general, are terrible with Cloudflare enabled. This chart [http://goo.gl/JX1v6] shows how Googlebot responds when cloudflare is enabled and disabled. With Cloudflare enabled in June, response times are above 1000ms. I have since disabled it in the middle of June and response times returned to normal.

2) Cloudflare is getting worse. Look at the chart again. Notice the elevated response times in April? I also had cloudflare enabled then. They hit around 400 - 500 ms in response time. Then I disabled it again at the first of May.

3) Ajax requests, most notably, POST have increased noticeable latency. Some days are better than others.

I do not have anything "special" enabled. Minimize HTML,JS, CSS are not enabled. Nor is rocket loader.

I'd also like to add that when "cache everything" + Minimize HTML, JS, CSS + Rocketloader is enabled, then response times seem to be perfectly normal on a different site hosted on the same box. Googlebot: [http://goo.gl/DRDnF]. However, most of us cannot use this feature unless our content is static.

Everything posted here is based off a free account. I will also be cross-posting this on the cloudflare blog post that this links to.

Re: Stop worrying about Time To First Byte (TTFB)

#17

Post by saetaes »

saetaes wrote: post #13

One thing that's interesting is that the Navigation Timing API available in modern browsers varies from being wildly incorrect to accurate, depending on the browser. In a quick test on my Mac, Firefox 13 showed an incorrect result (basically, the same issue as WPT and Gomez - almost immediate TTFB), while Chrome 20 correctly detected the 10s TTFB.

One more data point: On Windows, both IE 9 and Chrome 20 measure TTFB correctly via NavTiming, while Firefox does not.

Re: Stop worrying about Time To First Byte (TTFB)

#18

Post by jgrahamc »

xpose2000 wrote: post #15

I am glad that TTFB worries have been debunked by cloudflare. However, more issues still linger: 1) Response times, in general, are terrible with Cloudflare enabled. This chart [ http://goo.gl/JX1v6 ] shows how Googlebot responds when cloudflare is enabled and disabled. With Cloudflare enabled in June, response times are above 1000ms. I have since disabled it in the middle of June and response times returned to norma…

It might be better to put in a support request on this rather then posting on the blog. I've highlighted your comment on our internal chat.

Re: Stop worrying about Time To First Byte (TTFB)

#19

Post by josephscott »

The small table comparing a large Wikipedia page is really the main point, a relative comparison of TTFB.

The mistake was is making a relative comparison on such super small numbers. If your TTFB is less than 2ms, then you are fine. You are better than fine.

If your TTFB is 1.5 seconds, then you are struggling.

In determining if you have a TTFB issue comparing the relative improvement of super small numbers isn't likely to help you much.

Re: Stop worrying about Time To First Byte (TTFB)

#20

Post by huggyface »

TazeTSchnitzel wrote: post #12
forgotusername wrote: post #6

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…

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 given piece of code executed one or in the single digits, annihilating the JIT benefits.

Safari on Windows is a horribly, horribly slow, sloggy browser, yet it has amazing JavaScript numbers.

Post reply on HN