Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



When it comes to website and search engine optimisation one of the first topics that comes up is page speed. In the case of SEO, for example, we know that Google looks at page speed when determining the ranking of pages in its search engine. There are many means of measuring page speed, but little is known about how Google themselves distinguish a slow loading page from a fast one. However, research from the likes of SEO specialists Moz have suggested that there is one site speed factor that influences search engine rankings more than any other – Time to First Byte (TTFB).
In this article, we will take a look at precisely what TTFB is, how it impacts SEO, and what you can do to reduce the time to first byte on your website.
Simply stated, TTFB is the time it takes your browser to load the first byte from a web server when you request a URL. In more technical terms, Time to First Byte is calculated by the latency of a round trip to the web server and back to the end user.
TTFB is calculated in milliseconds, and is composed of three main elements:
TTFB is distinct from how page load time is generally understood, where the time is calculated by how long it takes for the page to load completely. In this sense, TTFB is not a user-focussed metric, as the user is oblivious to the time to takes to load the first byte of a webpage, and judges speed only by the time it takes to load the page. However, a website with a long TTFB waiting period can frustrate visitors, leading them to bounce back to the search results if they are kept waiting for too long.
So, what determines a positive TTFB? According to Google, you should be aiming for 200 milliseconds or less, but anything above 500 milliseconds is rated as above average. Here’s the breakdown:
There are several tools online that you can use to measure your First Time to Byte, including Google Chrome DevTools, Geekflare and WebPageTest.
As we made reference to in the introduction of this article, recent research has revealed the potential impact of TTFB on search engine rankings. The study tested the performance of over 100,000 websites in the search engine results pages for 2000 different search queries. The results of the test revealed a ‘clear correlation between a faster time to first byte and a higher search engine rank‘. The study found this to be the case not only for searches containing a couple of keywords, but for long tail keywords (search phrases containing three or more words) as well.
It is an established fact that user experience is a key focus for Google in ranking webpages, and page speed is one of the most objective metrics available to Google when it comes to evaluating the quality of a user’s experience with a particular page. As such, page speed can have a very real impact on the rankings of your website. The aforementioned research provides further insight into how Google measures page speed, and highlights just how important TTFB is in that calculation.
In this section we will take a look at some of the steps you can take to reduce the TTFB on your website.
Improving your DNS response time is a quick and effective way of reducing your TTFB. A high end DNS provider such as Cloudflare will help to reduce TTFB as they have nodes throughout the world and implement Global DNS caching.
If you’ve updated your DNS provider but still haven’t been able to move the needle on TTFB, the next step is to look at your web hosting. For example, if you’re currently on a shared hosting plan, then it’s quite common to experience slow TTFB as you are sharing your web server with other websites. To improve your TTFB, you will want to explore other web hosting options. Here are three of the most popular:
As the name suggests, this type of hosting hosts your website on a dedicated server. If you are upgrading from shared hosting, this can help to reduce your TTFB significantly.
On a cloud hosting plan, your website is hosted on multiple servers rather than just one. This also represents an improvement on shared hosting, and is a good alternative to dedicated hosting, often providing slightly more functionality.
Managed hosting provides an ‘all-in-one’ hosting package, including web hosting as well as website building functionality. This is a great option for new businesses, or businesses who are thinking about redesigning their existing website.
Latency is a big factor in TTFB as it determines the speed at which the end-user is served the first byte from the server. While latency is not something you will have direct control over generally, you can help to improve it by using a content delivery network (CDN). A CDN is a group of servers spread throughout the world which work to serve HTML and JavaScript files and images faster than a regular server. Because the physical distance between the server and the end-user is reduced by a CDN, latency is also reduced, as the round trip it takes for a request to travel from the user to the server and back again is shortened.
Finally, it’s crucial that you monitor the speed of your TTFB. External monitoring is important as it enables you to measure the impact of the changes you have made to improve TTFB, as well as the capacity to track performance over time.
The StatusCake page speed tracking application allows you to monitor your time to first byte speed to ensure that you do not drop below the 200 millisecond threshold.
Share this
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
3 min read In the previous post, we explored how AI accelerates delivery and compresses the time between change and user impact. As velocity increases, knowing that something has gone wrong before users do becomes a critical capability. But detection is only the beginning. Once alerts fire and dashboards light up, humans still have to interpret what’s happening,
Find out everything you need to know in our new uptime monitoring whitepaper 2021