How to fix the “Reduce initial server response time” warning (TTFB)

The “Reduce initial server response time” warning is triggered by PageSpeed Insights when your time-to-first-byte (TTFB), also referred to as wait time, is higher than 600 ms. TTFB is a metric that measures the time taken to establish a connection to your server and then receive the first byte of page data back.

In terms of load order and or timing, TTFB is the first thing that happens when you load a site. It takes place before anything is visually painted on a page. It is classified as a notable metric. It’s not an official Core Web Vitals metric. However, it has a huge impact on impact on First Contentful Paint (FCP), Largest Contentful Paint (LCP), and perceived performance (how fast a site feels).

Below we’ll take a deep dive into understanding TTFB and how to fix the “Reduce initial server response time” warning, along with some recommendations. 

What is good TTFB?

According to Google, they want you to have your TTFB under 800 ms. However, this can vary slightly between different tools. 

For example, if you’re using Lighthouse in Chrome DevTools, they are looking for 600 ms based on how they measure. The official recommended metric for Core Web Vitals is under 800 ms.

I personally recommend that you aim for well under 300 ms. The reason is that you can always expect spikes with TTFB due to a variety of factors, as well as the big impact on FCP/LCP.

What makes up TTFB

TTFB can be broken up into different parts. It measures the elapsed time between startTime and responseStart. Here are the main factors you want to worry about, or at least have some control over: 

• Redirects
• DNS lookup
• Connection/TLS
• Cache 

How to measure TTFB

There are many different tools you can use to measure TTFB. A few of our favorites that we use on a regular basis are PageSpeed Insights (PSI), GTmetrix, SpeedVitals, KeyCDN, and DebugBear. 

When testing, we always recommend testing at least three times before looking at the data. This is due to any factors that might influence your first test. And this goes for any metric, TTFB, FCP, LCP. Things like cache, network latency, etc., can all influence things. Never just rely on one data point. 

In PSI, you’re looking for both the TTFB metric and the warning regarding “Reduce initial server response time.”

Bad TTFB

Good TTFB

It’s important to understand the difference between lab data and real-user data. Lab data is at the bottom of the report under the “Diagnose performance issues” section. This top section is real-user data. It’s collected over an average of 28 days as users hit your site and are recorded for Core Web Vitals. Or rather, they are the only metrics that really matter. But remember, it’s always delayed.

Also, pay attention to this tab to see if there is enough data for your individual URL. Otherwise, the origin (average) of your site is shown.

Beware of Redirects, DNS, and TLS

When testing, it’s important to consider not just server response time, but also those other parts that make up TTFB, such as redirects, DNS, and TLS.

For example, in GTmetrix, you can hover over the HTML doc request and see DNS lookup time, connection, SSL/TLS, waiting, etc. This is essentially all going to contribute to your TTFB.

Let’s say you add a redirect into the mix. In this test, we are speed testing the HTTP version of the URL instead of the HTTPS version. Now theoretically, Google shouldn’t be indexing this version, but it’s good to understand how things like 301 redirects can influence TTFB. That’s why you might have heard in the past that redirects are bad for performance.

We can see that the first request to the HTTP version has its own performance cost, before then going to the HTTPS version. It doesn’t double the time, but it adds quite a bit.

Invest in fast hosting

One of the most important factors in determining your TTFB and fixing the ““Reduce initial server response time” warning will be your hosting provider. Even Google says the best way to improve TTFB is “hosting, hosting, hosting.”

You get what you pay for when it comes to hosting. Many cheap hosting providers try to get as many customers onto one server as possible. This results in you sharing all of the server’s resources with everyone else, in turn slowing down your site. We always recommend investing in fast WordPress hosting where many of these headaches disappear.

Here are a few hosting providers we personally recommend:

• Kinsta (managed hosting)
• BigScoots (managed hosting)
• Rocket.net (managed hosting)  
• InstaWP Live (managed hosting)
• Cloudways (hybrid approach, but more complex/work)

Another reason this can be important is due to some of those factors that aren’t as easy to control, such as DNS/TLS, etc. Many of the hosting providers above are already using fast DNS servers, CDN providers like Cloudflare, etc. 

You’ll almost always end up saving money and time by investing in a higher-quality hosting provider from the start. Then focus all your time and energy on growing your business.

Install a caching solution or plugin

High TTFB typically happens when caching isn’t set up properly, or your website isn’t hitting cache. So the very first thing you should do is check to ensure you have a proper caching solution or plugin in place on your WordPress site. If you aren’t sure, you can use the Site Health tool in your dashboard. If you don’t have cache setup or configured, you’ll probably get a warning that page cache is not detected and the server response time is slow.

If you’re using a managed WordPress hosting provider like Kinsta, BigScoots, Rocket.net, or InstaWP, this should simply work out of the box, as they have server-level caching. There is no configuration or caching plugin needed. That’s the beauty of a managed WordPress host.

If you’re using another type of hosting provider, you will most likely need to install a caching plugin. We recommend the following caching plugins (these all work great alongside Perfmatters): 

• WP Fastest Cache (free)
• Super Page Cache (free)
• WP Rocket (premium)

If you’re hosting provider already has a cache solution (Breeze at Cloudways, Speed Optimizer at SiteGround, LiteSpeed cache, etc.), its usually better to use it over something as, as their developers know their environment better than anyone, and integrations are usually more stable. 

When testing cache, we always recommend running your speed test at least three times. If your site’s cache just expired, you might see a “Reduce initial server response time” warning the first time you run the test. If you do have caching properly set up, this warning will go away with a repeat test.

Here is an example of the impact caching has on your TTFB, along with other Core Web Vitals metrics.

Not cached response

In a response that isn’t cached, we see TTFB of 228 ms.

Cache response

In a response that hits cache, we see TTFB of 122 ms. That’s a decrease in TTFB of 57.64% simply by enabling cache. We also see a FCP decrease of 43.09%, LCP decrease of 20.67%, and total load time decrease of 20.67%.

Decrease the distance of your server

As mentioned above, high TTFB can trigger the “Reduce initial server response time” warning from PageSpeed Insights. If your server is hosted in the United States, and someone is visiting it from Germany, this will result in higher TTFB. And it could put you over the under 600 ms threshold that Google is wanting. 

Why does this happen? It’s mainly due to the physical distance and the network latency involved. Here is example.

TTFB in North America

Here is a test on a server that is located in North America. We can see that the TTFB is 524 ms.

TTFB in Europe

Here is a test on the same site located in North America, but testing from Germany in Europe. You can see that the TTFB increase 90.84% just by changing the physical location (increasing the distance). We also see a FCP increase of 111.04%, LCP increase of 140.1%, and total load time increase of 140.1%. That isn’t good.

However, there is a solution. And that is using edge cache. Unlike a traditional CDN, which speeds up CSS, JS, and images, edge cache serves your entire site (HTML, CSS, JS, and images) from the edge (multiple locations around the globe). This elminates the distance problem altogether and results in really low TTFB. Think of it like a CDN on steroids. When someone hits edge cache, there is no request back to the origin server.

If you’re using one of our recommended hosting providers, edge cache with Cloudflare or a similiar feature is already included for free.

If you’re using a host without this feature, you can achieve the same thing with your own free Cloudflare account and a plugin. I recommend one of the following combinations (both work great alongside Perfmatters):

• Cloudflare with the Automatic Platform Optimization (APO) add-on ($5/month). Also recommended to install the free Cloudflare plugin.
• Cloudflare with the free Super Page Cache plugin.

If you can’t or don’t want to use Cloudflare, sometimes the hosting provider themselves will have a solution that can help with TTFB. For example, at SiteGround, they have a premium CDN option along with dynamic caching that can help. Some LiteSpeed providers also provide edge cache via their QUIC service.

It’s also important to point out that we don’t always recommend using Cloudflare without edge cache, as you will actually have worse TTFB from the overhead of their WAF. Otherwise, it would be better to use a traditional CDN. However, sometimes there are security benefits from Cloudflare you might need too. But it’s important to understand that using Cloudflare without edge cache will hurt your TTFB.

Make sure to also check out our recommended settings for Cloudflare for the best performance.

Edge cache impact

How much does edge cache really impact TTFB across the globe? Here is a great example using the SpeedVitals TTFB tool. We are running a test in North America and Europe. Check out the slow degradation in TTFB as we get further away from the host location.

TTFB in North America (without edge cache)

TTFB in Europe (without edge cache)

Now, let’s look at a WordPress site that has Cloudflare edge cache running on it. You can see that the TTFB is pretty much green across the board, regardless of the location, and a lot more consistent. 

TTFB in North America (with edge cache)

TTFB in Europe (with edge cache)

As you can see, edge cache is incredibly powerful!

Reduce HTML doc size (DOM)

TTFB is primarily about the backend, server resources, cache, distance, etc. However, a larger HTML page size (DOM) means more data that needs to be transferred from the server to the browser. This can potentially slow down server processing time, which can indirectly increase TTFB. You’re probably familiar with that “Avoid an excessive DOM size” warning in PageSpeed Insights. 

For example, here we have two sites.

Site 1

Site one is simply a fresh WordPress install.

Site 2

On site two, we added 600 comments, you can see how this greatly impacted the DOM complexity.

Now, let’s look at how this impacted the total HTML size and TTFB.

Site 1

On site 1, we can see that the fresh install has an HTML doc size of 14.4 KB.

Site 2

On site 2, we can see with the increased DOM count, the total page size increased to 345 KB.

Now let’s look at the difference in TTFB.

Site 1

On site one with the smaller HTML doc size and fewer DOM elements, the TTFB is 571 ms.

Site 2

On site 2 with the increased DOM count and larger HTML doc size, the TTFB is 1.5 seconds. The TTFB increased by 162.7%. As you can see, increasing the number of DOM elements and the increase in page size has a huge impact on your TTFB.

What can you do to decrease the HTML doc size and reduce the number of DOM elements? Here are a few quick pointers. 

• One obvious solution is to consider the length of your pages. Instead of adding 5 rows of products on a WooCommerce site homepage, perhaps cut that back to 2 or 3 rows. That will reduce the DOM/number of elements. 
• Use lightweight WordPress themes and solutions coded with performance in mind. This will automatically result in lower DOM elements/depth, not to mention all the other benefits.
• Don’t just inline everything possible. We see a lot of tendency to just inline all the CSS, and this can easily lead to a really large HTML doc. Using external stylesheets allows them to be cached separately. The same goes for inline SVG code. Remember, with SVGs as an image, you can lazy load them.
• You can utilize the Script Manager in Perfmatters to disable scripts, stylesheets, or entire plugins where they might not be needed or shouldn’t be loaded. MU mode includes inline CSS/JS.
• Pay attention to the number of HTML elements on your pages or posts. For example, we were working with a client who didn’t realize they had thousands of spam comments. This quickly added up to over 60,000 DOM elements on a single post and page size of over 700 KB. And that resulted really high TTFB. 

Increase cache length (TTL)

A great way to reduce the “Reduce initial server response time” warning from showing frequently is to increase the cache expiration time (TTL) on your site. Longer cache times lead to improved site performance, and better cache HIT ratios. It can also fix the warning from Google to “serve static assets with an efficient cache policy.”

If you’re hosting with Kinsta, the following cache length times are available right from the MyKinsta dashboard: 

If you’re using a different hosting provider or caching plugin, check their documentation or ask their support to see how to increase your WordPress site’s expiration time. 

If you’re using full-page caching with Cloudflare, you can also change this from their dashboard. Under the “Caching” tab, click on the “Configuration” tab. Set your “Browser Cache TTL” to something higher. We recommend at least 7 days or a month.

Preload cache

Another thing you can do to improve TTFB is to preload your cache, also referred to as “warm up.” For example, say you do an entire site cache purge. The site starts rebuilding cache as visitors hit those pages again. However, those first visits are uncached, resulting in higher TTFB.

Preloading cache essentially means that once the cache is purge, there is an automated process to build back the cache without requiring a visitor. This can be done in a few different ways, such as a process that scans your WordPress sitemap file and rebuilds the cache from that.

The one downfall to preloading cache is that it obviously will have additional server overhead, as it’s one more process running.

Cache plugins like WP Fastest Cache, WP Rocket, and the Super Page Cache plugin all have preload options.

Also, one cool thing about using edge cache with a service like Cloudflare APO is that it instantly pushes cache to all edge locations on the first visit from any location. It doesn’t require someone to hit each separate edge location. Although this is just at the edge layer.

Clear cache less often

This might seem obvious, but once you’re done optimizing, it’s recommended that you don’t clear your entire site cache too often. The more uncached crawls or hits to your site can actually hurt your Core Web Vitals scores over time. You want your site to hit cache as much a possible.

If you’re curious, we have a regular plugin update schedule every two weeks, where we back up sites, update plugins (test them), etc. We then do a full site cache clear. So on our sites, we’re never clearing the cache more than twice per month (unless something goes wrong). The longer things are cached, the faster they will be for users and Google when they crawl your site.