How important is the First Time Byte / TTFB?

[MannDude]

Someone today expressed their concern with their rating on http://www.webpagetest.org/ as it showed their First Time Byte as an F. Not super familiar with how this is measured or the importance of it, I simply Google, "First time byte". The first result? A Cloudflare blog post: Stop worrying about Time To First Byte (TTFB)

The other individual was under the impression that without an A rating on that website speed tool that Google's indexing of their site would be very low, that customers wouldn't do business with them, etc. The blog posts suggest otherwise. I'm no expert, and in fact, vpsBoard ranks pretty low on the same test but I've found out Google rankings to be quite decent, but perhaps I'm missing something significant and missing out greatly on a missed opportunity. <shrugs>

So... whats the scoop? How important is the first time byte overall? I understand you don't want it to be too high, obviously, but what options are available to lessening it and is it important enough to stress over?

 

[NickM]

TTFB isn't on my radar.  It's nowhere near my radar.  As the cloudflare blog entry points out, TTFB is supposedly a test of how long your server took to process the request and create the page, but that's muddled by actual network latency.  It could be used to help figure out where a problem lies if you're also internally measuring page generation time. For example: TTFB is 1s, your script reports 150ms, and you know you're about 50ms away from the server, where does the other 750ms come from? Probably the web server itself (rewrite rules or something like that).  But as a metric that you have to constantly keep an eye on? Nah.

 

[peterw]

Google has limits on page loading times but TTFB is not the tool for measuring it. HTTP sends a lot of different information. It starts with "HTTP/1.1 200 OK", some headers and the payload. It does not make sense to messure the "HTTP OK" as a quality indicator. More important is the loading time of the payload. 1 second for "HTTP OK" and 30 seconds for the page content and 2 minutes for the static content. This site has a A ranking? Bullshit, because Google has to wait 30 seconds because it is not indexing "HTTP OK" but the content.

If you want to speed up your homepage you have to messure the payload loading and the static loading. The static content can consume cpu power because nobody is using gzip_static. All css, js and images are zipped again and again. And the post about the entropy pool to speed up ssl is important too. I know sites that route the search engines to exlusive caching servers to serve them content faster.

Whats the scoop? A new marketing gag of SEO companies.

 

[eva2000]

TTFB is important (not as much for google ranks but performance in itself) and more so on mobile devices but don't worry about the webpagetest rating itself but the actual numbers relative to other factors as well including dns speed, geographic location, net connection, browser and devices tested on. i.e. test on 3G 300ms vs Cable 5Mbps profile and see. TTFB also factors in MySQL backend performance too. 

More important is visual rendering time, users perceived loading time which ain't necessarily the same as load time. Both webpagetest.org and gtmetrix.com can show you both metrics so quite useful for such.

It's all relative, regular testing and monitoring will give you a baseline set of numbers and just tune for improvements and retest.

i.e. for SSL TTFB tweaks http://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte/ which now is supported and no need to patch since Nginx 1.5.9+ http://nginx.org/en/docs/http/ngx_http_spdy_module.html#spdy_headers_comp

and http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_buffer_size

edit: another reason vpsboard with https/SSL and Nginx should enable Google SPDY/3.1 in Nginx 1.5.10+ >> http://centminmod.com/nginx_configure_https_ssl_spdy.html

non-SPDY SSL vs SPDY SSL https://spdy.centminmod.com/spdytest.html