My Desperate Scramble To < 200ms TTFB

I’m always thinking about how to improve my site loading speed. I made a major breakthrough when I figured out how to defer even inline JavaScript, which allowed me to also defer major libraries like jQuery. But I think I’ve done all I can on this front for now. The real bottleneck is my server response time, or Time to First Byte (TTFB).

Now that Google is placing more focus than ever on the time to render the largest content in the viewport, every few milliseconds count. It doesn’t matter that the JavaScript is deferred – 2.5 seconds to display the most visible content isn’t very long at all. So I’m doing everything I can to get my TTFB down to below 200ms.

Where I Stand Right Now

On my website WP-Tweaks.com, where I promote NameHero, I’ve managed to bring my “Largest Contentful Paint” times into the green for desktop devices:

However, you can see that my mobile performance still needs work. It’s frustrating, because they’re exactly the same site. I’d written earlier about how having a separate site for mobile is a bad idea. But this means that my LCP times on mobile are 2.8s – I still need to shave off 300ms!

How I Optimized (For Desktop at Least)

Here’s a quick rundown of how I improved my TTFB for the desktop.

Why Use Cloudflare

To reduce my TTFB, I’m using Cloudflare. Why? For one thing, their DNS servers are amazingly fast. I’ve tried plenty of others, including those provided by my web host, and they all much slower. So there are easy speed savings when you switch to Cloudflare’s fast DNS.

There are other reasons to use Cloudflare as explained below:

Cloudflare Argo

One of the first things to do is to reduce the routing time it takes for your content to reach Cloudflare’s servers. For this, I use the paid service called “Argo” from Cloudflare. Ryan had written about Argo some time back. It starts at $5 a month, and doesn’t really go beyond that for my traffic levels. With Argo enabled, you can see how big a difference it makes to the server response times as shown here:

So what would have normally been a response time of 893ms, becomes 531ms. That’s a massive difference of 78%.

Cloudflare Workers to Cache Everything

Recently, I’ve been taking another look at Cloudflare’s “Cache Everything” functionality. I had previously been skeptical about its ability to make substantial gains on your site because there were just too many EDGE nodes, and adding/updating content on your site was a problem.

However, I’ve recently started to use Cloudflare workers to cache and purge specific URLs. If you’re on WordPress, I suggest you check out this plugin from none other than Pat Meenan (from webpagetest.org), called “Edge Cache HTML via Cloudflare Workers”. For $5/m you get 10 million free requests, and the workers allow you to:

1. Bypass the cache on cookies (Otherwise costs $200/m on Cloudflare’s Business plan!)
2. Purge specific WordPress URLs on new content or changes

This kind of advanced functionality is unavailable using ordinary “Page Rules”. So $5 here and $5 for the workers, means that I pay $10/m just for optimization. Expensive? Not if you compare it to the hefty fees others charge. Fastly is $50/m, and other high-end services like Akamai are just not retail friendly.

Railgun? I REALLY Want to Like it But…

Cloudflare’s Railgun is such a cool concept. It’s supposed to create high speed connections between your origin server and the EDGE nodes. But in practical use I’ve found it to be not that great. In fact, it’s occasionally buggy and actually worsens the site performance.

I keep going back to test Railgun in case they sort out their issues. But so far, it hasn’t really helped me 🙁

Going Forward

The problem with Cloudflare’s cache is that it’s not guaranteed. Often it’ll drop items from cache in a few hours. There’s some algorithm that determines which assets are worth caching and which ones aren’t. Ideally, I wouldn’t mind paying extra for the ability to guarantee cache availability. To that end, I’ve tried services like StackPath, but while it seemed promising, it was buggy and I often couldn’t even access my site.

It has a lot of promise. When I let it run overnight, I got amazing TTFBs of 42ms. But then suddenly my site would be unreachable! I can’t live with that kind of uncertainty. So unless they fix their bugs, I won’t be able to rely on them for a production site.

Mobile LCP < 2.5 Seconds is the Dream

I’ve gotten the desktop figured out. But will I be able to shave off that crucial 300ms on mobile? I have no idea. The only thing that can save me is Cloudflare’s page cache. Without that, I’m not sure what else I can do to improve my site performance on mobile…