I’ve seen many hosting reviews in which Time To First Byte (TTFB) or Server Response Time is directly associated with hosting speed. Sort of, the smaller Time To First Byte, the faster web hosting.
This research is based on 125 hosting-months of continuous testing and monitoring the performance of different hosts. I will show you how really much TTFB has to do with hosting speed. There were 11 mln TTFB and 733K hosting speed measurements done in total to figure this out.
- Intro and what you’ll know
- Methodology of testing and data source
- Wars of opinions: importance of TTFB influencing website loading speed (hosting speed) and website ranking
- TTFB and other related terms definitions and explanations
- My research on how Time To First Byte (TTFB) is connected with hosting speed
Intro and what you’ll know
The reason why I wrote this article is to explain the topic of Time To First Byte (TTFB) and how it corresponds with hosting speed and website speed. I wrote it so that a website owner without specific technical knowledge could easily understand it.
It will help you avoid misleading hosting reviews based on false assumptions that Time To First Byte (TTFB) affects website speed to a great extent. And you will be able to make right decisions when choosing faster hosting.
Also it was interesting to put together the relevant hosting monitoring data I have. And I’m happy to share it with you.
In this article you’ll know both theoretical and practical (real-life) stuff:
- What Time To First Byte (TTFB) really means.
- How much TTFB correlates with hosting speed in real life.
- How significance of TTFB depends on who is analyzing it.
- My research results after 125 hosting-months of TTFB and Full Page Load Time aka hosting speed testing (11 mln TTFB and 0.7 mln speed tests performed).
- Which of the 15 hosts that I’ve been monitoring with my test websites have the best TTFB and the fastest speed.
- Definitions of other terms connected with TTFB and often misused or generalized (good for better understanding of TTFB).
Methodology of testing and data source
In short, since February 2016 I’ve been testing and monitoring different hosts. I bought hosting anonymously and hosted there my practically identical testing websites. I used automated uptime and full page load time (speed) testing service to gather the statistics on the hosting performance.
At the time of writing this post I’m monitoring the performance of 15 hosts using automated service. In total I’ve gathered statistics during 125 hosting-months. Uptime tests (including Time To First Byte) are performed every minute and Full Page Load Time (website speed) gets measured every 15 minutes.
The tests are run from the two US locations which are located at large distance from each other (East and West Coast).
Thus, in total from February to December 2016 there have been done about 11 mln Time To First Byte (TTFB) tests and more than 733,000 speed tests. All this data is used in this research for convenience as monthly averages values.
You can see all source data I’ve used for this article in screenshots of the hosting performance reports that I publish monthly in these posts.
Wars of opinions: importance of TTFB influencing website loading speed (hosting speed) and website ranking
I’ve put together this section to show you that the topic of how Time To First Byte (TTFB) is important and questionable for website owners and webmasters. Although after some research it becomes clear whether TTFB is a good measurement for website speed or hosting speed, website owners still feel lost in this topic.
I hope my article will help making this much clearer.
The reason for the quarrels on the TTFB topic and different opinions on it is that people put different meaning in the terms they use. Also, people don’t look deep enough into technical details, or simply pursue their business interests.
Thesis: Time To First Byte (TTFB) is meaningless
The war between opinions on TTFB’s importance started in 2012 when CloudFlare published a blog post titled “Stop worrying about Time To First Byte (TTFB)”.
The main useful point of the article that most readers will take away (from my perspective) is that TTFB should not be treated as the (only) metric to measure website loading speed. The author of the article (John Graham-Cumming) also mentioned that TTFB can even negatively correlate with a full page load time. For example, depending on web application and server environment it can be that the less TTFB the more website loading time.
And I agree with its main message considering the fact that it targets a certain audience group (which is not every technical). The idea that a typical reader (website owner, webmaster) should understand about TTFB is that it should not be the main or the only metric to focus on. Yes, the title of the article is a bit provocative. But this is content marketing and I take it quite easy.
Antithesis: Time To First Byte (TTFB) absolutely matters
In response to John’s article, a guy from Google, Ilya Grigorik, posted on his G+ page almost insulting post abusing CloudFlare of making “silly tests”. His main idea was that Time To First Byte (TTFB) absolutely matters.
Illya in a typical smart IT guy’s manner criticized the article. He underlined that TTFB should not be discounted because this is an important metrics for measuring and optimizing web application performance. And from a developer point of view TTFB is indeed an important metrics.
Synthesis: Web performance is what really matters
Interesting part of it is that both Ilya and John were right on what they focused. Ilya neglected the fact that the target audience of CloudFlare’s blog post are not programmers. And “Stop worrying that much about TTFB” is a good advice for website owners who wanted to make Time To First Byte (TTFB) as little as possible thinking that it would necessary make their websites faster.
But at the same time it’s a bad idea for technical guys to ignore TTFB.
Anyway, the collision of the who opinions from different perspectives initiated not just a long discussion in the comments, but also a wave of follow-up posts on different blogs. So, I even could assume that all this clash of the opinions might be a successful blog post promotion rather than a real fight for the truth 🙂
After all, this is website speed (hosting speed) what matters in the end.
Here’s a nice infographic about it below. By the way, pay attention to the last section of the infographic. Dramatical Ebay‘s website speed improvement went along with the decrease of its First Time To Byte (TTFB). And in case with Wallmart, its TTFB stayed practically the same whereas its speed just rocketed.
Presented by Skilled.co
Speculations: TTFB impacts search ranking in Google
Then, as web performance optimization has been gaining more and more popularity, MOZ published a controversial statistical research with the idea that you sort of should optimize your TTFB to rank better in Google.
This idea has appeared from the fact that back in 2011 Google announced that the website loading speed affects ranking to some extent. But TTFB is not an equal factor to website loading time.
Anyway, people desperately want their websites to rank well. And the people took this idea quite literally. they assumed that TTFB could be one of the (secret) Google significant ranking factors.
That was not what probably Google would want. And Ilya suggested taking care of overall user experience, not just a part of it which is TTFB. This is where Google’s and CloudFlare’s extremes finally met :). The lesson is that anyone should stop being obsessed so much with TTFB.And people should stop measuring TTFB and seeing the results make decisions right away. But people should consider improving performance taking Time To First Byte (TTFB) as just a part of the website optimization task.
- Opinions on Time To Fist Byte (TTFB)’s importance can be different. It depends on who (website owner, IT-specialist , marketer, etc) is dealing with or talking about TTFB.
- Better TTFB does not necessary mean faster hosting. Although it depends. More details and my statistical research on it see further.
- Optimizing TTFB does not make automatically your website faster.
So, you get the general idea. And now I’ll brush up some theoretical aspects for consistency. And then I’ll get closer to numbers and useful practical advice for you.
One of the reasons why people are confused with how Time To First Byte (TTFB) affects website speed and if TTFB can be used as measurement for hosting speed is the following. A lot of people just don’t really know what TTFB means.
Understanding what’s really behind TTFB and how it’s interconnected with other metrics of website or hosting performance will help you make better decisions and judgments regarding hosts and website speed optimization.
In addition to Time To First Byte (TTFB) definition, I put together some other related terms to understand the IT context better and to see what TTFB can be confused with.
Website owners without deep IT knowledge will find this chapter useful.
What is Time To First Byte (TTFB)?
A general meaning of this term is how much time it takes for a client (e.g. your browser) to make a HTTP GET request to a web server (or to put it simply, to your website) and receive the first byte. This first byte goes in a packet of a hundred bytes or so.
In other words, a general meaning of Time To First Byte (TTFB) is composed of the following:
- Time it takes HTTP request to travel from the client (e.g. browser) to a web server,
- Time it takes for web server to process the request,
- Time it takes HTTP request to travel back from the web server to the client (a packet of bytes).
And to be more precise, the following metrics can be segmented from TTFB if you want a more detailed analysis:
- DNS lookup.
- Initial connection.
- SSL negotiation.
- Waiting for the server to process the request of the connection (Server Response Time).
- Receiving data.
- Closing connection.
In a general approach, all the above components together are treated as Time To First Byte (TTFB). Narrower meanings of TTFB may exclude some stages at the beginning (or/and at the end) of the the metrics queue.
On the way to and from the web server, the performance may be affected by many factors. They are the speed of your network, the distance to the server, any network issues or interruptions on the way.
You can see these parts in a waterfall analysis using such tools as webpagetest.org:
As you can see, Time To First Byte (TTFB) does not exactly regard how fast a web server processes any request. And it’s not about how fast a page visualizing (rendering) goes.
Moreover, it does not mean that TTFB is proportionally or unconditionally correlated with a hosting speed (more details on it below). TTFB is just about the first portion of data transferred and processed on a particular server considering transferring data through the network.
Here’s the image that summarizes the meaning of Time To First Byte (TTFB):
What is Server Response Time?
To put it simply, Server Response Time is how much time a web server needs to respond to a request sent by a client (e.g. a browser).
Look again at the above explanation of Time To First Byte (TTFB). Server Response Time is the time that it takes for the server to do its work to process the request of the given connection. Again, this is just about a single request in a particular server-side circumstances.
And the circumstances can be different for a server in a particular moment (operations queue, call to a database, running scripts).
So, whereas a server hardware is something that can be considered as a constant variable in this equation (at least till the next hardware upgrade), server-side circumstances are not constant. That’s why Server Response Time (and therefore Time To First Byte too) fluctuates depending on a number of parameters which can change every moment.
For example, Server Response Time (as well as Time To First Byte) measured on a a shared hosting at a particular time would depend on a number of users visiting all websites on that server at that particular time.
By the way, Server Response Time is sometimes referred as Time To First Byte (TTFB). So, just be aware that the terms can be used differently.
What is Server Latency?
This is the time that a command requires to be completed on a server-side.
Although for a general purpose it can be used as a synonym to server response time, it’s a narrower definition. Latency considers only physical and mechanical parts of the process. Latency regards hardware, physics and mechanics.
To make it more clear, here are some examples of what affects latency:
- electromagnetic limitations,
- electronic delay in hardware,
- logical operations limitations in hardware and software,
- mechanical movements limitations in a storage device.
Server latency is also one of the components which compose Time To First Byte (TTFB).
What is Round Trip Time (RTT)?
Round Trip Time (RTT) is also a part of a general meaning of Time To First Byte (TTFB). RTT is the time that a request needs to get from a client (e.g. a browser) to a web server and back. The processing time on the server (server response time or server latency) is not included in RTT.
So, using the definitions above here’s how Round Trip Time (RTT) can be defined:
RTT = General meaning of TTFB – Server Response Time
What is Full Page Load Time?
Full Page Load Time is the time which is needed to download and render (display) the web page completely on a client side (e.g. in a browser). This is the most useful and intuitive metrics for a typical user (website owner, webmaster) who has not very deep knowledge in IT and web development.
Some terms like Time To First Byte (TTFB) are sometimes misused or referred as different meanings which causes confusion and even online disputes. So, just be aware of this.
If you understand what the terms mean in general and in each particular case, then it will be easier for you to make right decisions. It’s important when you choose a faster hosting or optimize your website performance.
My research on how Time To First Byte (TTFB) is connected with hosting speed
Although I use the terms such as correlation and dependency in this chapter, I don’t overwhelm my writing with complicated statistical and probability calculations. In this article I’m not using the words such as correlation ratio, standard deviation, R-squared, confidence interval etc. I believe that a simple graphical analysis that anyone can clearly see and understand would be enough to represent the ideas I discuss in my article.
To put it very simply, let’s look at the charts and see what we can see.
General overview: TTFB vs Hosting Speed monitoring results
As I said in the section above, I’ve analyzed 11 mln Time To First Byte (TTFB) tests and 0.7 mln Full Page Load Time tests to see how website speed is connected with TTFB. Here’s the chart that summarizes the measurements:
Each dot on the chart above represents an average performance of one of the 15 monitored hosts during one month. The performance is represented by two metrics: First Time To Byte (TTFB) and Full Page Load Time (website loading speed).
As you can see, in general there is a noticeable correlation between First time To Byte (TTFB) and website speed (which is monitored hosting speed in our case). The more FFTB the slower hosting.
However, if we segment the data into some separate pieces, the conclusion may be not so evident.
Segmented overview: TTFB and Hosting Speed uncertainty
I’ve visually divided data on the chart into three sections: A, B and C. I assume that if I had tested not 15 hosts but many more, the chart could have looked a bit different. But still after millions of tests during a number of months I’ve done this is a good example to present the ideas how Time To First Byte (TTFB) can be connected with hosting speed (Full Page Load Time measurements).
Let’s look at section “A” first. This is outsiders group. Time To First Byte (TTFB) is big – more than 900ms. And hosting speed shows the worst values. Also, there’s a clear correlation – the bigger TTFB the slower hosting speed in this segment. It’s all look logical and expected.
Now look at sections “B” and “C” together. We still can see the general tendency that the bigger TTFB, the slower hosting in this part. But hosting speed does not show a very clear correlation with TTFB. And moreover, the less TTFB the greater variety of the hosting speed values.
Also, maximum values of hosting speed in section “B” are lower than maximum values of hosting speed in section “A”. This shows that sometimes smaller TTFB may result in slower web hosting. This is counter-intuitive and that’s why this is a useful observation.
Specifically section “B” is still a quite logical part. In general, in this section the same expected formula works as in section “A” – the bigger Time To First Byte (TTFB) the slower hosting speed. Although this dependency is not that vivid as in section “A”, it’s still pretty apparent.
As regards section “C”, it represents that the rule “the less TTFB the faster hosting” or “the more TTFB the slower hosting” does NOT work very well. Also it’s important to note that section “A” contains most of the observations.
Let’s add hosting breakdown on the chart in the next section to see more interesting details.
Per host view: TTFB and Hosting Speed performance
On the chart below I displayed the monitored hosts and how they performed monthly (click the image to enlarge):
Section “B” (Time To First Byte between 600 ms and 900 ms) contains practically just two hosts – MochaHost and Eleven2. Although these hosts show comparatively bad Time To First Byte (TTFB), their speed is quite average.
Section “C” (Time To First Byte below 600 ms) is very diversified. There’s no clear pattern in correlation between Time To First Byte (TTFB) and hosting speed. This is so not only in general, but also per several individual hosts.
Some hosts show an “expected” dependency between Time To First Byte (TTFB) and hosting speed, i.e. the more TTFB the worse hosting speed.
Best hosts according to TTFB and Full Page Load Time tests
Let’s see now the hosts which have been performing the best among the 15 monitored hosts. I’ve selected on the chart only those hosting performance observations which were faster than 600 ms Time To First Byte (TTFB) and faster than 1.5 seconds Full Page Load Time (website loading time):
In the table below I put together these hosts with their scores. A score for a host represents how often the host gets into this high-performance section.
For example, score “4 out of 7” means that during 4 out of 7 months the host performed exceptionally well (i.e. hosting speed below 1.5 seconds and TTFB below 600 ms).
All my recommended hosts are on this page (and “My review / Read” links in the table above go to this page with my recommended hosts to a selected hosting review as well).
I also suggest looking at more details how these and some other hosts performed every month.
If you want to see each and every monthly report on the hosts performance (including Time To First Byte data), go here.
If you’d like to know the winners of the monthly hosting Contest, go here.
According to my data set for the 15 hosts I’ve been monitoring, Time To First Byte (TTFB) and Full Page Load Time (or hosting speed) show some correlation. At the same time it depends on a particular host and the TTFB value.
If Time To First Byte (TTFB) is slow (more than 900 ms), then TTFB is strongly correlated with hosting speed (i.e. website loading speed measured via Full Page Load Time tests). The more TTFB the slower hosting. But note that only one hosting has come into this category, so it might be not very representative conclusion.
If TTFB is average (between 600 ms and 900 ms), then the correlation between TTFB and hosting speed is very noticeable, but less than in the above case with slow TTFB. Only two hosts have come to this category. So the results for this category is also not very representative.
And if TTFB is within the most frequent range (below 600 ms), then the correlation between TTFB and hosting speed is not obvious in general. Some hosts even show negative correlation (better TTFB leads to worse hosting speed). And many hosts show different hosting speed when their TTFB does not change.
After all, the rule “The smaller TTFB goes together with faster hosting” does work from a generally statistical point of view. But there are some notes when looking at it closer:
- This is just correlation, not causation. In other words, if you make TTFB faster (or if you choose a hosting with a faster TTFB) it does not guarantee that your website will be faster with this host compared to other host with lower TTFB.
- Each host has its own pattern of dependency between FFTB and hosting speed. In other words, hosting speed may fluctuate when TTFB stays the same or almost the same.
- There are other factors which affect hosting speed greatly rather than TTFB. As a result, some hosts may show better TTFB but final website loading time may become worse. And vice versa: worse TTFB may go along with better website loading time at the same hosting.
And if you want a super-very short summary of the whole article, here it is:
- Be aware of that the terms like Time To First Byte (TTFB) can be used differently by different sources.
- The smaller TTFB the better, but this rule is not strict and depends on a lot of factors (including caching options or firewalls/CDN).
- Even within one hosting a better TTFB does not always mean better website loading time.
- Speed of shared hosting is subject to many other factors (e.g. performance boost options) which affect it. So TTFB is far not a major factor.
- I’ve run 1.7 mln tests on 15 hosts during 11 months. Here are the take-aways. TTFB less than 600 ms is quite normal (most measurements fall into this range). And TTFB more than 900 ms is likely a not good sign.
- The best three hosts which show the smallest TTFB and the fastest loading speed (in the period from Feb 2016 to Dec 2016) are GeekStorage (9 out of 9 scores), HostWinds (6 out of 7 scores) and A2 Hosting (5 out of 8 scores). More details above.
P.S.: Note that fast hosting with great support is just a part of the successful foundation of your online business. Strong website security and reliable backup solution are the other two major components of your strategic technical advantage.