StatusCake

How to Reduce Time to First Byte

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.

What is First Time to Byte?

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:

  • The time it takes to load the first byte of webpage
  • The time it takes to send the HTTP request
  • The connection time

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:

  • 100 – 200 milliseconds – Very good
  • 300 – 500 milliseconds – Good
  • 600 – 900 milliseconds – Average
  • 1 second and above – Poor

There are several tools online that you can use to measure your First Time to Byte, including Google Chrome DevTools, Geekflare and WebPageTest.

SEO

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.

How to Reduce First Time to Byte?

In this section we will take a look at some of the steps you can take to reduce the TTFB on your website.

DNS response time

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.

Change your web hosting

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:

Dedicated Hosting

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.

Cloud Hosting

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

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.

Reduce latency

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.

Set up page speed monitoring

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

More from StatusCake

Alerting Is a Socio-Technical System

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

Designing Alerts for Action

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

A Notification List Is Not a Team

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

Alert Noise Isn’t an Accident — It’s a Design Decision

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.

The Incident Checklist: Reducing Cognitive Load When It Matters Most

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

When Things Go Wrong, Systems Should Help Humans — Not Fight Them

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,

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

*By providing your email address, you agree to our privacy policy and to receive marketing communications from StatusCake.