Since I made a post a number of years ago, half-jokingly referring to this, my personal blog, as the fastest website in the world, I’ve obviously invited an amount of scrutiny onto the performance of my own pages.
I use this site to test bleeding edge things that clients – frankly – wouldn’t want to test out there in real life, on a domain which has traffic and ranks nicely in search already, but is not directly monetised. Think about it. How many websites rank in search, are really fast, but don’t mind destroying that to participate in an experiment? Not many. This one does.
As I often recommend stacks including Cloudflare for a variety of reasons (let’s not go into all of them here!), not least their DNS Proxy and Firewall is very useful (and easily managed) for eCommerce purposes. The TL;DR is Cloudflare offers an easier access point to most eCommerce managers for a powerful DNS and caching service.
But, you may find on free and business plans, that TTFB is not everything you had hoped for. This is more the case recently than in previous years, too, for a variety of reasons.
One reason it’s important is Google’s increased focus on Core Web Vitals.
The other reason it has cropped up is Cloudflare looks like they maybe “clipped the wings” of what is possible on free plans over the years. For example, certain POPs are only available on paid plans. Additionally, you pay more (via Argo) for faster routing and other “get me a cache from nearer to me” methodology.
In short, the more you pay, the faster it will become… but what to enable to access those faster speeds, in Cloudflare?
That’s the focus of the remainder of this post.
Table of Contents
How to Initially Setup Cloudflare
I’m not going to go into too much detail here – that’s not the purpose of this post – but suffice it to say, you want Cloudflare caching full posts (that is “cache everything”) if your visitor is looking at a page of content with nothing dynamic within.
This blog post, for example… Cloudflare, using PageRules, has been told explicitly, based on the URL, to cache everything here.
Don’t worry – if I change and save the post, I hit Cloudflare with an API request to flush their caches of this URL.
What Next – still high-ish TTFB?
If you’re polling your site using one of the online tools, like PageSpeed insights, you’ll likely find that load number one shows a higher TTFB than if you query your server directly.
This makes a lot of sense if you think about it… rather than going directly to your server, we ask Cloudflare for a cache, which it doesn’t have – MISS – and then CF goes off to your origin server to ask for a copy, before pulling it back.
This extra little loop adds latency to the mix.
This little hunt happens at every Cloudflare POP on the globe – and there’s more than 100 of them.
The Solution – Pay $
Firstly, assuming your traffic is good, you’ll warm up caches more easily. Lower traffic sites will struggle to keep caches loaded.
CloudFlare has a reasonably good solution for this. It is called Argo. Argo sends your traffic down “faster” networks. It also will check for a closer cache at a POP which is quicker to reach than your origin server – remember, we asked Cloudflare to “cache everything” so they can always rely on a copy which is sitting nearby.
Its like this… Imagine I want sugar, and realise I have run out. It will always be faster to get sugar from next door than to go all the way to the shop for it.
Going next door is convenient. Convenience costs. Argo is one of the ways Cloudflare makes its money.
Enabling Argo will often dramatically reduce the recorded TTFB shown in online testing tools – and therefore experienced by real-life end visitors.
Win for you. Win for Cloudflare (you just agreed to pay them $5 a month + $0.10 per GB of transferred data). Now… you just need to keep your data parcels as low as possible 🙂
Other Considerations
Other things you will definitely want to consider include:
- Dynamic elements – like logins and any eCommerce features (cart / basket / checkout / payment processing!!)
- Full page caching on your origin server – in order to serve a fully prepared page instead of adding server side rendering into the mix
- Cache pre-loading – both on your origin server, and also in the Cloudflare POPs where you’re expecting to receive what I could call “money traffic” in the future – consider warming up caches on key pages, in key regions.
