TTFB Is Still (And Always Will Be) Meaningless

As with pretty much every buzzword and digital marketing trend, the concept of TTFB has proven to maintain lasting controversy within the so-called SEO community as hundreds of bloggers and developers continue to bring it up on discussion forums, in comment threads, at marketing conferences, and in other venues for several years on end.

TTFB, an abbreviation for ‘Time To First Byte’ is a resurrected networking metric which, despite having existed for decades, was a term all but unknown until it exploded in popularity in 2012-2013, as documented by Google Trends. In short, TTFB is a measurement in (micro)seconds of how long it takes for a client (user) to receive the first byte of data from a web page after beginning an HTTP request from within their browser; or as Wikipedia states, “This time is made up of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page.”

“A synonym is a word you use when you can’t spell the other one.”
― Baltasar Gracián

Let me make my point early on: TTFB is meaningless. It is meaningless because it is a metric that depends completely on the unique environment of each end user. It is meaningless because 99% of the time, it is being used to describe something that is NOT, in fact, TTFB. It is meaningless because, in reality, it is largely composed of networking elements out of the control of the end user, web designer, and server administrator alike. It is meaningless because, ultimately, it is just the latest trendy acronym being thrown around by SEO “gurus” in order to sound technically intuitive and/or sell whatever they are hawking.

One of the biggest critics surrounding TTFB hype has been CloudFlare, a free service that protects and accelerates millions of domains (and which has been on the receiving end of mockery and criticism from Young White Male Millenials (YWMM) practically since the day they launched). Attempting to assuage concerns over TTFB in July 2012, CloudFlare took to their blog to share a post called Stop Worrying About Time To First Byte (TTFB), which naturally was immediately criticized by grayhat SEO fanboys the world over as soon as it went live, many of whom had been purposefully manipulating “TTFB” on their servers in an effort to “trick” Google into thinking their sites loaded faster than they did, and/or to encourage “persistent” HTTP connections (all of which A) is pointless and B) hasn’t mattered since SPDY/HTTP2 arrived).

The article, despite making several undeniable points, continues to be widely mocked by such “gurus” (a.k.a. CloudFlare haters). For example, the team at CloudFlare explained how easy it is to “manipulate” TTFB metrics if desired; they also reminded readers that Nginx + GZIP, despite its ability to greatly accelerate web page loading speed for end-users, actually tends to report a slower TTFB metric while the server prepares (compresses) the HTTP request; lastly, if all that wasn’t enough, CloudFlare also revealed that various TTFB measurement “tools” are in fact reporting erroneous performance data, explaining, “The TTFB being reported [by various online SEO tools] is not the time of the first data byte of the page, but the first byte of the HTTP response. These are very different things because the response headers can be generated very quickly, but it’s the data that will affect the most important metric of all: how fast the user gets to see the page.”

All to say, faster “TTFB” metrics have absolutely no guarantee of a faster loading web page for actual end users.

To make matters worse, soon thereafter SEOMoz published a grossly misleading case study from an agency called Zoompf which argued that “improving your TTFB” would directly “improve your rankings” on Google. Talk about pandering to hype in order to sell a few SEO packages… if this was a health product, it would be banned by the FDA for fraud! But perhaps quite illustrative, the most up-voted comment on the post was by one Emma North, who conjectured:

“I would suggest here though that correlation does not equal causation. In fact, I don’t think it’s a very big leap to suggest that ‘bigger’ sites or brands likely to rank well will have faster sites and servers on the whole. An interesting experiment and summary though and I definitely think site speed has some impact on rankings but I believe it is only in as much as very slow sites won’t rank as well.”

Kudos to Emma for recalling a little something called The Scientific Method; indeed, correlation ≠ causation, for TTFB does not have any effect on search engine rankings whatsoever — nor could it ever, since TTFB is completely dependent on the environment of each individual end user. And if we are really looking for a conclusive opinion from Google, perhaps it is tell-tale that the Chrome browser documentation is quick to mention TTFB as a “devtool” feature for end-user perpective, while the Google Developers guide for server administration is careful to completely avoid the phrase. In its place, the generic concept of “server response time” has been chosen by Google, as they purposefully clarify that network latency (end-user TTFB) is NOT correct terminology when discussing server optimization. In other words, if you want to claim that site speed matters, by all means, please scream it from the hilltops (we do!). On the other hand, if you are going to ignorantly interchange the very clearly defined networking term “TTFB” with general website performance concepts… please, STOP.

But of course, it doesn’t stop there: One particularly douchey Google software engineer, Ilya Grigorik, decided to jump into this fight back in 2012 and, despite Google never publicly discussing whether “TTFB” effects search rankings (nor confirming what Google’s definition of “TTFB” would be in that case), Grigorik decided to attack CloudFlare and accuse them of writing a “traffic-bait” article. Grigorik went on to assert that sites like Amazon or Facebook have used “early flushing” techniques with great success (sending the HTML head in the first data packet… again, NOT TTFB!). When CloudFlare’s John Graham-Cumming responded that “[TTFB] itself is not what most people think it is… it’s not the time it takes for the first useful byte to get to the browser… our message was [simply] ‘Stop worrying about that as a metric’“… Grigorik then responded with further insults, concluding, “If you want to be pedantic about the literal ‘first byte’ back to the client then that’s a different conversation… Just because you guys can’t currently flush the relevant data early does not meant it’s not a useful optimization.”

Clearly stunned by Grigorik’s level of aggressive, ignorant douchey-ness, Graham-Cumming finished by saying, “The larger message (especially to our customer base) was that obsessing about TTFB as they see measured from some web measuring service isn’t helpful. There are so many factors that are involved in that number (nginx ones that I mentioned, network latency, where the testing is done from) that the data is very blurred. The doesn’t mean we don’t believe that optimizing the time we get the page out on the server doesn’t matter. We do.” Clearly, this non-sanctioned troll-fest by Grigorik not only made Google look to employ a bunch of complete assholes (which, I’m not sure, is perhaps true), but also FURTHER fanned the flames of confusion and SEO fanboy-ism when it comes to the @#$%! term known as TTFB.

In any case… here are the 3 most important things to remember when it comes to the term TTFB:

1. TTFB is not the same thing as loading speed. The English language LOVES acronyms, and once one appears, it begins to appear everywhere. Unfortunately, this has caused mass confusion in terms of loading speed and on-site SEO, and the term TTFB is now often being used interchangeably to mean “loading speed” or other general optimization practices. Here at LittleBizzy, for example, we are obsessed with improving the loading speed of WordPress websites; in other words, we want our clients’ sites to begin loading and finish loading as soon as possible, which also means focusing on stability and security as well. There is a reason why companies like Google and CloudFlare focus on end-user experience and and discourage lengthy debates amongst “SEO gurus” about ridiculous things like TTFB, and it’s because end-users don’t give a damn. As long as a website loads quickly and consistently in a way that builds trust and increases conversions or sales, then it’s a success.

Pro Tip: Generally speaking, these days the term TTFB is often referring to “server response time” and the lesser-used term TTLB (Time To Last Byte) is referring to “page load time” i.e. the time it takes for a web page to fully load (more info).

2. TTFB is dependent on the client’s internet connection. By far, this is the part of TTFB that most webmasters simply do not seem to grasp. It doesn’t matter how amazing your website performance is, your TTFB is still determined mainly by the physical internet connection you are using. If you are in a Starbucks in Los Angeles and trying to run TTFB tests on a website hosted in New York, there is all kinds of network latency involved. This is exactly why running TTFB or any ping-related tests result in wildly differing metrics on every test run. If you really want to test your website’s loading speed, especially in the eyes of a company like Google, then you need to be running “loading speed” tests from an actual datacenter, i.e. by using a tool like Pingdom that discounts network latency. Running speed tests from a laptop computer in your home office or from a Starbucks is the equivalent of trying to take photos of the moon using your smartphone: it’s simply not setup for it.

3. If your DNS, server, and CDN are well configured, there is not much to worry about. As mentioned previously, TTFB is meaningless for a variety of reasons, and as far as SEO or web development goes, it always will be. The truth is that it is merely a technical concept based on good old-fashioned networking jargon, despite dozens upon dozens of “SEO gurus” continuing to misuse the term as some sort of post-DNS and post-socket connection metric. Accurate TTFB metrics ALWAYS include network latency when properly calculated, so any tool claiming to “measure” TTFB as a resource speed metric is simply wrong. Instead of trying to improve your “TTFB” scores as measured by such inaccurate tools, it’s a much better investment of time to improve EVERY PART of your website’s performance, whether it be “early flushing” or “caching” or otherwise.

Then again, I could be just another wannabe SEO “guru” too. But if ranking #1 on Google for any search phrase you want and achieving loading speeds of 0.4 seconds sound like things you might appreciate, I pray you keep an open mind ~