4 ms·

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

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 into account factors like the ability for the browser to progressively render partially transmitted HTML, or large hangs as a result of external objects (e.g. web fonts, GL models, etc.), especially in a world with increasingly complex front-end Javascript blocking the browser's UI thread (syntax highlighters on blogs, anyone?). As Apple demonstrated on the iPhone, it's more than possible to hide multi-second delays using tricks as simple as showing a facsimile image of what will shortly be loaded, similarly a web app that animates a form submit with an unintrusive 400ms animation (hiding a 500ms response time) may appear snappier from a user's perspective than an app with no animation but a 300ms response time. Actually CloudFlare's own signup process is exemplary in this respect, they bury half minute long DNS queries in the background while the user continues filling out forms.

infinity 14y ago
>>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 for the loading to finish, but the browser sometimes freezes completely (for example, this happens sometimes with Opera), which is a bad user experience. "Perceptible latency" requires that we have some people who will load the page and measure if is was fast or slow or sluggish. In my experience this is often said to be too expensive or too much work. Actually, it requires just a few people with different browsers and internet connections to get a good idea if the website is fast or slow - BUT: this is nothing that is measured precisely. The TTFB given by the tests, mentioned in the article, on the other hand, looks like really hard data, measured exactly in fractions of seconds. This can be plotted nicely in a graph, for example. Another way to see if a website is fast or slow is to ask the visitors. There has been a survey on one large website, which I have created, with some open questions about the new website. One open question was: What do you like about the website. More than 90 percent of the visitors, who have filled out the survey, answered that they have noticed how fast the website loads.
- lukeschlather 14y ago
  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.
TazeTSchnitzel 14y ago
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.
- huggyface 14y ago
  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.
  - TazeTSchnitzel 14y ago
    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.
- jexe 14y ago
  Do you have a link to the MS talk/article about their work with Metro? I'd be very interested.
  - TazeTSchnitzel 14y ago
    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.
jaequery 14y ago
I'm shocked at how Cloudflare is downplaying the importance of TTFB just because their service happens to INCREASE them. 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 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).

infinity 14y ago

>>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 for the loading to finish, but the browser sometimes freezes completely (for example, this happens sometimes with Opera), which is a bad user experience. "Perceptible latency" requires that we have some people who will load the page and measure if is was fast or slow or sluggish. In my experience this is often said to be too expensive or too much work. Actually, it requires just a few people with different browsers and internet connections to get a good idea if the website is fast or slow - BUT: this is nothing that is measured precisely. The TTFB given by the tests, mentioned in the article, on the other hand, looks like really hard data, measured exactly in fractions of seconds. This can be plotted nicely in a graph, for example. Another way to see if a website is fast or slow is to ask the visitors. There has been a survey on one large website, which I have created, with some open questions about the new website. One open question was: What do you like about the website. More than 90 percent of the visitors, who have filled out the survey, answered that they have noticed how fast the website loads.

lukeschlather 14y ago
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.

TazeTSchnitzel 14y ago

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.

huggyface 14y ago
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.
- TazeTSchnitzel 14y ago
  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.
jexe 14y ago
Do you have a link to the MS talk/article about their work with Metro? I'd be very interested.
- TazeTSchnitzel 14y ago
  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.

jaequery 14y ago

I'm shocked at how Cloudflare is downplaying the importance of TTFB just because their service happens to INCREASE them. 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 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).