Another TTFB thread

From searching around, it looks as though issues with Time To First Byte (TTFB) when using Cloudflare have been discussed at great length.

Despite my reading on the subject, I just wanted to canvas some thoughts on my situation.

A few years ago on Google PageSpeed we used to get the warning, “Reduce initial server response time” which I believe is PageSpeed’s TTFB metric. We used to get this warning mostly on WordPress websites which are notorious for running dozens of SQL queries per page view. We started using a caching plugin for most WordPress installs which got rid of this warning and to the keen eye speeded up page views by a fraction of a second.

Now we’ve implemented Cloudflare, and this dreaded warning is back. Depending on the time of day, sometimes it goes away, sometimes it registers as over 1 second. We don’t ever get this warning on a WordPress site that is cached at the origin and NOT using CloudFlare.

Using yields similar results - a non-Cloudflare site scores an “A” on TTFB, and a site on Cloudflare tends to score a “C”. These sites are all hosted on the same origin.

As an experiment, I set a site to “cache everything” at CloudFlare. The TTFB warning remained the same on Google PageSpeed, and bizzarely scored worse via compared to when HTML is not cached. In any case, we need to utilise the WordPress admin bar for logged in users, as well as a bunch of other things that will cause disruption by caching HTML at Cloudflare.

Our sites are hosted in the Netherlands, and I checked the IP address used by Google PageSpeed which revealed its location was also in Europe, so it’s not that Google PageSpeed is connecting via a Cloudflare server far away in the USA.

Finally, using Chrome Lighthouse tools on my local PC, there is no complaint about TTFB - in fact it is typically around 90ms. The actual loading of the sites themselves are fast - from my location at least. The entire page seems to load and render in less than half a second. The Cloudflare server responding to my requests is in the UK (which is where I’m based).

It seems as though if we’re going to reap the benefits that Cloudflare offers, this warning is a side effect we have to put up with. I’m guessing it’s simply the time it takes to fetch non-cached HTML from the origin, to Cloudflare, back to whever the test is being run from.

I guess the question is, should I just forget about this now, and move on, or is there anything else we can do?


Hi Gareth, thanks for your post! I’m a member of the Infrastructure team and might be able to add some color.

TTFB is actually a topic with some debate, which different people internally have argued for and against as a useful measure. I’d give the things in the first post (by Pat Meenan, the founder/host of WebPageTest!) a read for some optimization techniques and see how much positive impact they have.

A TL;DR: we’re conservative about caching in order to avoid breaking things, because Cloudflare supports… well, every site on the Internet and try not to break any of them. For the reasons Pat mentions, it’s dangerous to cache more than we’re absolutely sure won’t break things, so we don’t. You can tweak around and almost definitely get rid of those warnings.

Oooor, if you’re (like me) kind of lazy and willing to pay a few bucks for one of our paid plans or the Free add-on, we actually released a new shiny WordPress tool for doing this stuff automatically; check the details out here.

For my broader $.02, synthetic benchmarks are great. We use a ton of them internally! But they’re called “synthetic” for a reason: they aren’t the real world, which is full of conflating factors. The fact that you’re having a good UX (and low TTFB to boot) in your personal tests is pretty encouraging, at least if you’re using the site as one of your users would.

WPT/PageSpeed/etc. are fundamentally designed to point webmasters towards perceived problems rather than replicate the actual user experience like a user or end-to-end browser automation like Selenium. My understanding of these tools is that they load pages from datacenters somewhere in the world (probably not where your users are based, i.e., the cache is cold) and try that again a few times. An actual user clicks on a link that leads to your site that perhaps their browser precached when they were about to click; things were already cached at the edge because they’re loading the site from the same places as other users and on connections that real users use, and so forth and so on.

If you don’t want to go down the rabbit hole and you and your users are happy with the performance, it’s A-OK to just… leave it as-is. That’s what has made Cloudflare so successful - by far and large, It Just Works pretty darn well and users are much happier with its performance vs. going to-origin.

This has been a very long-winded way of answering your question, so to sum up: it’s ultimately your choice, you can absolutely improve your TTFB using cache tricks, automatic optimization, and so on—but if you’re happy with the actual performance, which it sounds like you are, I wouldn’t feel bad about letting sleeping dogs lie. Totally cool to let the nerds o’er at Cloudflare’s virtual HQ to work our magic on increasing performance without your intervention; that’s what we’re here for.

Hope this helps!


Hi Jon from Cloudflare!

Thanks so much for taking the time to reply, and for your detailed answers.

The two main issues with “caching everything” on a WordPress install were the caching of the admin bar, and how to purge the cache when new pages/posts are created. I installed the Cloudflare WordPress plugin and set everything to cache, and see that this mostly resolves those issues. Other than the ability to purge the cache, I set the other permissions on the API token to “read only” which I’m more comfortable with from a security point of view (I’m not concerned with changing Cloudflare settings within WordPress itself).

It works great, with one exception, which is that whilst the admin bar doesn’t get cached, often an admin user cannot see the bar (since on the front-end they see a cached version of the page that doesn’t include the bar). I only wish we could bypass the cache based on a cookie without spending $200 :slight_smile:

After setting up the above the TTFB was good, but then I tested another WordPress install which wasn’t set to “cache everything” and the TTFB was equally as good. It probably needs more testing over a longer period of time.

The conclusions I’ve come to:

  1. Our TTFB is consistently good when NOT using Cloudflare.

  2. Our TTFB is periodically good, and periodically not so good (although not terrible) when using Cloudflare and “cache everything” is OFF.

  3. Haven’t yet tested over a longer period of time with “cache everything” ON.

I should also add, we’re on the free plan. Whether the pro plan would help with point #2 above I’m not sure. Either way, I cannot complain when something is free. We would actually like to pay, but we have around 50 WordPress installs so at the moment it’s not viable for us to have all of them on a paid plan.

I’m inclined to remove the Cloudflare plugin and “cache everything” after some testing because our results are really not bad at all, and as they say, “Premature optimisation is the root of all evil”. Really, it’s because I’m a stickler for trying to get a good Google PageSpeed score.

1 Like

Hi Gareth,

One workaround for this might be to setup two separate subdomains for your site which both point to the same origin. One with full cache and one without. (e.g. with cache & without caching)

Your admins can then use the origin url when they need to use admin functions.

NB You’ll want to ensure you have a robots.txt which forbids the origin from being indexed


An alternative to what @nwood said would be, if you want to go down this route, to put a Worker on the domain and emulate the “Bypass Cache with cookie” Page Rule available at the Business and up tiers.


Thanks for all your suggestions. I’ve been measuring our TTFB on 3 sites, one not on Cloudflare, another on Cloudflare without “cache everything” and another on Cloudflare with “cache everything” turned on.

I’m pleased to say that although there is some variation, the difference lately seems fairly negligible. The site with “cache everything” has an improvement of perhaps 50 - 100ms on average. But in all cases the final TTFB figure seems to be 200ms or less.

My tests have not been at all scientific and generally just involve running URL’s through the Google PageSpeed tool one after another, at random intervals. I think a more scientific approach with a lot more tests would be required to see a pattern between the 3 sites.

My original concern was from receiving the warning, “Reduce initial server response time” from Google PageSpeed - a warning I hadn’t seen for a long time, until we started using Cloudflare. This doesn’t seem to be happening any longer, but I guess it could come and go depending on the time of day/week, network activity and a whole bunch of other factors.

Long term I don’t think we will keep “cache everything” on, and will remove the Cloudflare WordPress plugin, because at the moment it’s another complication that isn’t adding very much benefit. But it’s great to know that this option is available, should we need it.

Thanks for the replies and suggestions.

With cache everything page rule for HTML cache, if only a portion of your HTML pages are CF CDN cached, it’s still better than none. So when it comes to synthetic page speed testing where 1st uncached request run is made and you get slow initial server response time, that only happens for the first request. Subsequent requests to same CF datacenter will be served from populated cache. So more traffic you have the more likely your CF datacenter caches are populated.

But to really solve your initial server response time, that is down to your origin server itself and that needs to be optimised where possible - taking into account geographical location/distance of the testing tool and your origin location. So for optimal TTFB speed, you want your origin real web server to be hosted in a location closest to your majority traffic visitors and then put Cloudflare in front. For instance, my forums has 50% US visitors 40% Asian visitors and 10% Oceania. So my optimal geographic location for my origin is US West Coast as it sits in middle of US, Europe and Asian so equal round trip times for majority of visitors.

Might want to read an older thread that covers some of the page speed metrics at Performance Tutorials - Google PageSpeed &

And newer guide I wrote outlined for Google Lighthouse/Pagesped Insight for my Centmin Mod community users which is same engine GTMetrix has switched to at

To fully optimise you need to optimize 3 segments.

  1. segment 1 - connection between visitor and CF edge server i.e. CDN cache, WAF, Firewall, Page Rules, Mirage, Polish webP, HTTP/2, HTTP/3, CF Workers (i.e. custom/advanced caching) etc
  2. segment 2 - connection between CF edge server and your origin i.e. Argo, Railgun & Full SSL/ECDSA SSL certificates, pre-compressed asset served from origin
  3. segment 3 - your origin server’s performance/optimisations i.e. web server, PHP, MySQL server optimisations and server hardware specs.

Cloudflare can only help for segments 1 & 2 for cached guest/non-logged based visitors will easily scale. Now for Cloudflare CDN cache miss/bypass and logged in user for web apps like forums/wordpress, performance will be determined by segment 3. Which is the default with Cloudflare as dynamically generated HTML pages aren’t cached by default so cache miss means, whatever performance you have is measuring your origin server’s response time.


Cloudflare Workers is one way. Cloudflare Wordpress plugin and APO is a CF Worker for guest full HTML page caching in Wordpress that you can try. Though with 50 Wordpress domains, that will add up too. I have my own custom CF Worker for bypass cache on cookie full HTML page caching for Wordpress which does similar and works so far.

@eva2000 sorry I couldn’t see how to quote your post. However I believe our origin is already fairly well optimised. We regularly get 40ms TTFB on non-Cloudflare sites, when using local caching at our origin.

Our audience is in the UK and our origin is in the Netherlands which isn’t too far away. I was surprised, because when I checked, Google PageSpeed was accessing the sites from a location in the Netherlands, or at least from a location in Europe not very far away, and Cloudflare have pop’s nearby. So you would think it would have no complaints about TTFB. However, these warnings have gone away now, so were perhaps just intermittent at the time.

CF routing is dynamic and usually they’d route to the closest location (measured network wise) which may not be case if congestion occurs, you may be routed elsewhere and/or CF plans also factor into it. As you move higher into CF plans from free, pro , biz to enterprise, the more likelihood you’d hit closer data centers. This is very true for some locations which CF doesn’t peer with as much such as Australia and India. Not sure on UK.

But you can try other testing tools I outlined at WebPerf - PageSpeed - Google Page Speed Insights and Google Core Web Vital metrics | Centmin Mod Community Support Forums too.

To quote posts, you can just use mouse to highlight the text you want to quote and a quote popup appears.


Thank you, you learn something new everyday!

1 Like

A post was split to a new topic: APO questions