How to Reduce Your TTFB to < 0.5 Seconds

Google has a habit of throwing everyone into a tailspin with their announcements. For years, they’ve played coy with page speed, only hinting that it might be a ranking factor – and not a particularly important one. Last month however, they announced in a blog post that their “Core Web Vitals” will be officially integrated as ranking signals sometime next year. To this effect, I’d written earlier about how I had dropped my Cumulative Layout Shift (CLS) to zero. In this article, I’ll talk about how I dropped my TTFB to below 0.5 seconds on an average.

A Note on Measurement

0.5 seconds might seem a lot to you, but that’s the problem with the arithmetic mean. A single large value can completely screw over your metrics. Which is why it’s better to use the median instead of the mathematical average. Google themselves talk about trying to keep your site speed above 75% of all websites, so it’s obvious that they don’t rely on the mathematical mean as well.

My Results

But first, let me show you what I achieved. Here’s a screenshot of my Google Analytics page showing the server response times on WP-Tweaks.com:

You can see that when I finally figured out the solution, my server response times increased by at least 50%! Ignore the “0.94” seconds average on the bottom since that includes the entire 2 months of data that I’ve included in my Google Analytics report. My current (mathematical) average is now just 0.54 seconds:

The median is even lower than 0.54 seconds as you can see below.

Why TTFB? It’s Not a Ranking Factor!

TTFB isn’t a ranking factor. But the Largest Contentful Paint (LCP) is. And Google says you need to get the LCP down to below 2.5 seconds. That doesn’t leave a whole lot of time to spare, and if you can shave off even half a second from your server response time, that itself goes a long way towards lowering your LCP to below 2.5 seconds to make Google happy.

Using Cloudflare’s “Cache Everything”

I’ve blown hot and cold over Cloudflare’s “Cache Everything” functionality over the years. In an earlier article, I’d called it a waste of time, but I finally decided to use it along with the cool plugin called WP Cloudflare Super Page Cache.

This plugin not only caches your pages, it also clears the specific URL cache on events such as a post updating. It helpfully clears your archive pages only when you add a new post, and so on and so forth. One of the biggest problems with Cloudflare’s Cache Everything is that logged in users couldn’t see the admin version of the page, but also there was a danger that the admin version would be accidentally cached and shown to everyone!

The plugin helpfully solves these problems via API calls and also appends query strings that bypass the cache when you browse it as a logged in user. In short, it makes the behavior as close to “normal” as possible with the Cloudflare URL caching enabled.

Best of all, this is free. Both Cloudflare and the WordPress plugin can be had for no cost at all. It took a little while for the cache to warm up and start delivering from the EDGEs, but it’s made a huge difference to the page response times as you can see. Particularly since a few pages likely make up the bulk of your site’s visitors and those will always be cached due to the heavy traffic. It leaves your origin server free to service the rarer requests, which also speeds things up.

Summary

Hopefully you can achieve the same results that I did with Cloudflare and the WordPress plugin. Reducing your TTFB is absolutely crucial, as the rest depends a lot on the user’s browser, their internet connectivity, and more. The TTFB however is one thing that is completely under your control, and that’s why you should try and maximize it as much as possible.