TTFB Is Not Your Most Important Metric

TTFB, or Time To First Byte, is considered by many to be a very important metric in website performance and SEO… Many think that TTFB is the way to evaluate the speed of a server but in this article we aim to dispel this urban myth and equip you with a more accurate way to judge what really matters about site speed from a business perspective.

Firstly what is TTFB?

In order to fully explain TTFB we will have to get a little technical, keep reading as we don’t want you to miss out on this conversion and ranking gold.

When your website loads, the browser (e.g. Google Chrome) needs perform several steps to actually get to the content:

  1. The browser connects the local internet providers DNS server.
  2. The recursor goes out to the internet and looks up the IP address for your site.
  3. The browser has to establish a connection to the server hosting your site. (e.g. Entrecloud) This takes multiple round trips to the server. If your site is hosted far away, you can see a noticeable performance drop here. (This is why CDN’s come in handy because they duplicate your content globally)
  4. The browser needs to send the request for data to the server.
  5. The server needs to process the request (e.g. load WordPress)
  6. The server needs to send the response back.
  7. The browser needs to parse the received content.
  8. Some or all of the above steps have to be repeated for all resources included into your site (images, videos, CSS files, etc) depending on where they are hosted.

Out of these, TTFB signifies the time that elapses between the browser sending the request and the server returning the very first byte of the response. The keen eyed among you may discover the obvious flaws in using TTFB as your primary metric, but let me lay it out for you:

  • TTFB doesn’t say anything about how much time the DNS lookup takes.
  • TTFB doesn’t say anything about how much time the rest of the response needs to arrive.
  • TTFB doesn’t say anything about how much time the rest of the content (images, etc) need to load.

Bottom line: TTFB is not only an indication of server speed, it also incorporates a measure of the quality of your sites code.

Ok, ok, but you’ve read that Google cares about it for SEO reasons, right? Well, sorry to disappoint: that is advice that gray and black hat SEO people give. You know, people you should avoid if you care about the long term viability of your search engine ranking.

(In running Entrecloud we have seen our fair share of site owners who have lots their search ranking due to the shady dealings of the aforementioned “professionals”, but that’s a story for another day.)

To further emphasize how little Google cares about TTFB, let’s look a direct quote from John Mueller, Senior Webmaster Trends Analyst and host of the English Google Webmaster Central office-hours hangouts (a show that you should really watch if you care about SEO).

We’re seeing an extremely high response-time for requests made to your site (at times, over 2 seconds to fetch a single URL). This has resulted in us severely limiting the number of URLs we’ll crawl from your site, and you’re seeing that in Fetch as Google as well. My recommendation would be to make sure that your server is fast & responsive across the board. As our systems see a reduced response-time, they’ll automatically ramp crawling back up (which gives you more room to use Fetch as Google too). Google Product Forums

While you may see a site load on more than two seconds, a TTFB for a single request to exceed 2 seconds is extremely rare. Even if you pack WordPress full of plugins and run it on your mobile phone, chances are you won’t exceed it. And just to drive the point home, a slower TTFB affects the CRAWLING, not the LISTING. In fact, John Mueller said so himself:

  • Is there a ranking factor that includes rendering time?
  • I don’t know how much of that is […] still used at the moment. We do say we have a small factor in there for pages that are really slow to load where we take that into account […] [YouTube, 2015]

If you follow what Google has been up to lately, they no longer take purely technical metrics into account, but rather focus on the user experience. And they can do that, Even Google Analytics now has data on how much time the page needs to load in full. They no longer need to look at just server response times.

This has been reemphasized by the recent change Google did for mobile ranking:

Today we’re announcing that starting in July 2018, page speed will be a ranking factor for mobile searches.
The “Speed Update,” as we’re calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries. It applies the same standard to all pages, regardless of the technology used to build the page. The intent of the search query is still a very strong signal, so a slow page may still rank highly if it has great, relevant content.

Ok, what if you don’t believe me OR Google? OK then, how about what Cloudflare has to say?

Neither for SEO nor for conversion should you look at TTFB as your metric. It’s useless. A site can have a very low TTFB and then use insane amounts of JavaScript to slow their site down to a point where it is unusable, while a different site can have a mediocre TTFB but to excellent frontend work to get full page load times of sub two seconds. Needless to say, Entrecloud servers live on the best network money can buy and are powerful enough to serve millions of views with no problems, but you as a website owner should focus on how soon your customer can start reading or watching your content. As far as Google is concerned, user experience is the most important factor and TTFB is not an accurate representation of that. In regards to general conversion site speed, the time until a potential customer can use the site is the most critical factor.

And that, my friends, is a topic you will see explained in future posts. Happy optimizing!

CTO @ Entrecloud, DevOps engineer with over 10 years of experience in system administration and software development; public speaker and author.

Likes crazy side-projects and when they mature, applying them in practice.