Time to First Byte (TTFB) Under 200ms: Server Response Time

The length of time a browser has to wait before receiving its first byte of data from your server is known as Time to First Byte (TTFB).

If you are starting the process of website speed optimization you will surely come across this performance metric although it can also referred to as “Server Response Time” on some platforms. The length of time it takes for your server to transmit its first byte of data has a direct relationship to page load times and search engine rankings.

In the following article we will examine TTFB in depth – figuring out what causes slow response times and what we can do to fix it.

1. What is Time to First Byte (TTFB)?
2. Is Time to First Byte an important page speed metric?
3. Analyzing Server Response Time Data
4. Testing Time to First Byte
4.1 Google Page Speed Insights TTFB Testing
4.2 WebPageTest TTFB Testing
4.3 GTMetrix TTFB Testing
4.4 Pingdom TTFB Testing
4.5 KeyCDN TTFB Testing
5. How to Improve Time to First Byte (TTFB)
5.1 Upgrade Your Hosting
5.2 Use Content Delivery Networks (CDN)
5.3 Use A Caching Plugin
5.4 Update WordPress, Themes, Plugins and Databases

1. What is Time to First Byte (TTFB)?

Time to First Byte is a measure of the time your browser spends idling while it waits for your server to send data. Keeping things as simple as possible, TTFB is composed of three ordered processes.

Browsers make HTTP requests from the server. – Distance from the server, speed of users network, connection interruptions and DNS lookup all factor in to this process.
Servers process the browsers request. – Once the request is received the server starts to process the request. This is the point where some shared servers drop the ball, taking an excessively long time to respond caused by slow servers, slow databases and inefficient code.
Servers send the request back to browsers (packet of bytes) – Again, the distance from the server, speed of users network, connection interruptions are all factors. If your user is on a slow mobile network its going to negatively affect TTFB.

The browser to server “round trip” accounts for 40% of the total TTFB and can be even higher.

Waterfall page speed analysis provided by WebPageTest.org breaks it down into the following:

DNS lookup (Domain Name System) –The system for converting website names into numeric IP addresses
Initial connection.
SSL Handshake.
Waiting for the server to process the request of the connection (Server Response Time).
Downloading Data
Closing connection.

2. Is Time to First Byte an important page speed metric?

Google hasn’t revealed any detailed statistics showing the correlation between TTFB, overall load times and search rankings. However, Page Speed Insights makes it clear that you should have a server response time under 200ms. The longer it takes a browser to get its first byte of data, the longer it will take to load the entire website.

TTFB isn’t anywhere near as important as load time, but it is certainly a contributing factor. Experts disagree on the importance of server response time.

Internet security and CDN company Cloudflare thinks we should “Stop worrying about Time To First Byte (TTFB).

They state that TTFB is heavily affected by gzip compression. Websites that are uncompressed will undoubtedly have a faster TTFB scores, but much slower overall load times.

Having a compressed website sacrifices TTFB, but results in a much faster overall page load time.

Probably the only time TTFB is useful is as a trend. And it’s best measured at the server itself so that network latency is eliminated. By examining a trend it’s possible to spot whether there’s a problem on the web server (such as it becoming overloaded).

A Google web performance engineer named Ilya Grigorik was interviewed about TTFB and clearly refuted Cloudflare’s claims.

“Time to First Byte definitely matters, its just a question of how much impact it has relative to other things you need to fix on your page.”

Grigorik made it obvious in his interview that improving server response time was important, but only within the context of total speed optimization. That’s a nice way of saying its only if its extremely slow to begin with (>600ms).

Reducing TTFB from 300ms to 200ms is not that important relative to all other speed optimization, but reducing a TTFB from 900ms to 200ms is extremely important.

3. Analyzing Server Response Time Data

What does the data suggest?

Internet researcher Michael Bely has tested and analyzed TTFB data from millions of websites analyzing server response times and how they correlate to overall page speed.

His ResearchAsAHobby.com blog data analysis draws the conclusion that TTFB and page load time show some correlation, especially when TTFB is greater 600ms.

It is important to note that correlation does not imply causation. Upgrading hosting or tweaking settings to achieve a lower TTFB does not guarantee your website will load faster, although there is a strong indication it will help.

The chart below clearly indicates an overall correlation – notice the 600ms and 900ms data levels.

Server response times on shared hosting tends to vary pretty dramatically. My own site, hosted on A2 Swift Plan currently shows a TTFB of 330 ms according to WebPageTest.org, while my scores in March 2019 were 0.600s-0.900s.

I recently upgraded to PHP 7.3 from 7.1 (without breaking any plugins) – so that could have also helped to improve my TTFB.

4. Testing Time to First Byte

Several different speed testing websites exist to help you improve speed optimization. Each service has a unique method of referring to Time to First Byte – all used interchangeably.

Server Response Time (Google),
First Byte (WebPageTest)
Wait (Pingdom)

4.1 Google Page Speed Insights TTFB Testing

Google Page Speed Insights recommends TTFB times <200ms, but issues a green check-marks for times <600ms.

4.2 WebPageTest TTFB Testing

WebPageTest.org issues a green or “A” rating for a hitting their target TTFB + 100ms.

The target time is the time needed for the DNS, socket and SSL negotiations + 100ms. A single letter grade will be deducted for every 100ms beyond the target.

4.3 GTMetrix TTFB Testing

GTMetrix offers more detailed insights for logged in users (free account). They break load timing into segments on a chart showing connection and backend timings.

4.4 Pingdom TTFB Testing

Testing TTFB on Pingdom involves using their waterfall tool and scrolling down to the file requests section. Hover over the first file of the waterfall to display timings. The “wait” time is used on Pingdom for TTFB purposes.

Wait time can also be selected under the “Sort by” heading on the left side of the screen, allowing you to see a ranking of resources being waited on the longest.

4.5 KeyCDN TTFB Testing

KeyCDN doesn’t provide a rating or recommended TTFB for users. Instead it simply provides TTFB from various geographic locations around the world.

For global businesses having a server near the customer base is extremely important for loading static content. You can easily see how TTFB gets increase as the distance between the user and host server increases.

5. How to Improve Time to First Byte (TTFB)

Server response times can be further improved through advanced methods not included in this short list. I have decided to only include the four methods that deliver the best value based on time to implement and overall cost.

Since the importance of response time is still debated by people much more knowledgeable than you and I, its probably best to limit our time investment. Here are four surefire ways to improve Time to First Byte (TTFB).

5.1 Upgrade Your Hosting

Shared hosting is extremely economical for new websites and probably the best option. Most new website experience little traffic for the first 12-18 months, but as your website traffic grows you will need to upgrade your server to meet user demand.

If you start seeing TTFB consistently over 600ms its time to look for a new host. Quality shared hosting plans should have TTFB times between 300ms to 600ms.

If your website receives >1000 page views per day its time to upgrade your server resources. Shared hosting plans business model is putting hundreds if not thousands of websites on the same server. Each website gets a small piece of the resource pie.

This is fine if your host is sensible about the amount and type of site they allow, but this model is prone to bottlenecks and blackouts during busy times.

Several companies have created high end shared hosting to cater to websites that have outgrown basic hosting, but aren’t quite ready for VPS or a dedicated server.

This website uses A2 Hosting, but I would also recommend Siteground & Dreamhost. Here is a general idea of the tiers of hosting available.

Basic Shared
Premium Shared
VPS Hosting
Cloud Hosting
Dedicated Hosting

Its also important that your server is located close to your customer based (for local businesses). If you offer plumbing services and are physically located in Chicago, Illinois it would be smart to choose a server as close to your area is possible.

A2 Hosting offers a choice of servers in either Phoenix, AZ or Ann Arbor, Michigan during the signup process. Being that I am located in Florida I selected the Michigan location. Always selected the server closest to your physical location.

If you are a national brand, blog or eCommerce site you will need to use a Content Delivery Network (CDN) to get your server as close to the user as possible.

5.2 Use Content Delivery Networks (CDN)

If you are using shared hosting its extremely likely that your website is hosted at one server location. For example, I’m using A2 Hosting and the server I selected is located in Ann Arbor, Michigan. I selected this location because its somewhat of a midpoint between the east and west coast of the United States.

The geographical location of your server in relation to the person browsing your site has a huge impact on TTFB and fully loaded times.

Here are the most popular WordPress Content Delivery Network providers:

The raw distance of travel and the medium of transmission (fiber optic, WAN etc) account for the majority of network latency.

A user located within the United States can reasonably expect a TTFB of .350ms and a fully loaded page time of <2 seconds. However, users located in foreign countries are pretty far from Michigan and will experience much slower times.

Its probably not important that load times are fast in non-english speaking countries. However, countries like Australia and Canada are english speaking and experience slower load times.

I tested my website across the globe and here are the results:

Michigan, United States

0.312s TTFB – 2.17s Load Time

Sydney, Australia

0.898s TTFB – 3.98s Load Time

Bejing, China

0.988s TTFB – 11.97s Load Time

Toronto, Canada

0.466 TTFB – 3.26 Load Time

5.3 Use A Caching Plugin

Caching plugins speed up WordPress sites by generating static pages of a website. This reduces the data size sent between browsers, databases and the host server.

WordPress caching plugins are found in both premium and paid formats. This website uses free version of W3 Total Cache to improve speed efficiency. My website host , A2 Hosting customized the W3 Total Cache plugin to work specifically with their platform.

Here are the most popular WordPress Caching Plugins

W3 Total Cache – Free
WP Fastest Cache – Free
WP Super Cache – Free
Litespeed Cache – Free
WP Rocket Plugin – Paid

5.4 Update WordPress, Themes, Plugins and Databases

Most updates around WordPress, plugins and themes are heavily weighted to security improvements. Often times authors also include speed optimizations by improving PHP code and database efficiencies alongside security updates. Most efficiency improvements are documented via change logs.

Utilizing fast loading WordPress themes and plugins right from the start is a factor in obtaining a quick TTFB. Certain plugins are well known to be resource hogs and should be avoided at all costs. Themes and plugins are often abandoned by their authors and become a security risk and aren’t compatible with newer versions of PHP.

Finally, optimize your WordPress database with a plugin like WP Optimize. This plugin will clean up old and unnecessary data like spam comments, old revisions, pingbacks and stale data. It can also compact and defragment MySQL tables.

Speed