TTFB Is Still (And Always Will Be) Meaningless

   |  15 Nov, 2015  #

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.”

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 ~

Tags: , , , , , , , , , ,

Photo Credit:

Share This Article:

4 comments on "TTFB Is Still (And Always Will Be) Meaningless":

  1. Hey Jesse,

    Thanks for sharing some details on TTFB.
    I think we might have a slightly different view on the importance of TTFB.

    TTFB is one component of overall load time, and in many circumstances is a symptom of something else that is not setup correctly (eg too many cache misses, slow load from disk cache, slow or too far away POP for cache server,…).

    For WordPress in particular it can be a reflection of complexity of theme, ram/cpu correctly sized and number of and speed of database queries.

    Many of these are directly in control by the webmaster.

    It is a little disingenuous of cloud flare to claim it doesn’t matter since they increase it. Sometimes that has an overall positive effect on page load performance but many other times it doesn’t.

    I don’t think it’s appropriate to brush off SEO concerns since its been shown to have an impact. But even SEO aside, we should consider the overall user experience.

    Many studies (need link but one done by Jakob Nielsen comes to mind) show that perceived load time is heavily impacted by how quickly something starts to happen, and ux guidelines often call for loading indicators if the time to load is greater than 2s.

    This gives us our upper bound for TTFB, since your browser is blank, spinning with no page loading while waiting for TTFB. So I would argue it is better to respond with something in less than a second even if it takes slightly longer to deliver the overall page. Users will perceive this as loading faster.

    I agree that the environment used for testing any loading speed should be consistent. However the danger in tests from data centers is that they can mask speed issues caused by the network. Though many now also simulate bandwidth and latency common to consumer networks, the OS environment and available CPUs is different. Configurations such as not having flash installed or running multiple sessions in a constrained RAM environment will skew loading speeds as well.

    Chrome has two distinct loading indicators when it is waiting for the website to respond vs downloading data. I might be misusing terminology, but I generally think of TTFB as the point at which the browser has connected with the server and has started downloading resources.

    • Hi Vanessa, thanks for stopping by. As mentioned I fully support improving server response times, but it’s best to stop using the term TTFB inappropriately. I definitely do not “brush off” SEO concerns when it comes to speed, as that was my entire purpose in founding LittleBizzy (and one of the reasons my clients are able to improve their rankings so drastically). TTFB by definition includes network latency measurements, which is out of the control of webmasters — so by your definition, yes, you are misusing the term unfortunately.

      In an ideal world, we could improve both server response AND page load with GZIP, but unfortunately GZIP does report a (sometimes noticeable) slower server response time in many cases despite its powerful ability to improve overall page load times. My other article goes into more detail:

      Ideally Google recommends a 200ms (or less) server response time, and that is without network latency, so that is why their (and other speed tests) ignore the latency. If you want to test the network problems with your home or office, there are tools like DSLReports for that, but best not to be using website speed tests to diagnose latency issues.

      Ultimately server response is wonderful, but its only one of many elements in Google’s ranking algorithm (or in the way users judge/navigate your site). If your site is fast enough to maintain users’ respect (and increase conversions) then it’s probably doing fine :)!/bDUtpj/ loads in 400ms (total) and Google approves of our server response time as well, and that is behind CloudFlare. I do hope that CloudFlare can improve its own server response time in the near future, but ultimately it does also depend on the way you code and design your homepage, etc, as well (the lighter, the better).

  2. Thanks Jesse,
    Makes sense of server response time vs network latency.
    How do you debug servers that may not have best interconnections to the backbone, or a poorly chosen point of presence location in reference to the majority of users?

    I’m also curious as to why Cloudflare sometimes increases server response time – I’ve seen it both be neutral and increase it. Are there Cloudflare configurations that have more of an impact on first response?

    I’ve got some sites (like where TTFB (including network latency) is <100ms and it goes through Cloudflare.

    • As far as servers with poor locations, moving them to a proper datacenter is the first step. After you can eliminate as much network latency as possible you can move on to analyzing what else can be improved about their server response time.

      As far as CloudFlare’s often slower server response time, honestly I’m not sure. It’s likely related to their Web Application Firewall (WAF) and other security measures that do some heavy filtering and analyzing of incoming traffic. While I do hope they can improve it slightly, I’m of the opinion that it’s quite fine already when considering the huge benefit to site security and stability that their service provides (for free).

      In other words, higher traffic sites or more complex sites likely require more traffic analytics from CloudFlare for security purposes. And I doubt they will ever fully divulge all the details of that for privacy and business reasons! ;)

Leave a Reply

Your email address will not be published.*