Site is slower after enabling HTML edge caching

Last week we enabled edge caching of our static HTML pages, with a 7-day TTL, using Page Rules. Things appear good in the Cache Analytics - about 30% of requests to HTML pages are getting a “HIT” so far.

However, our average page download times, as measured by Google Analytics, are significantly worse, up by nearly 40%. How can this be?

Using Chrome dev tools from my local computer, I can see that our TTFB is clearly better with a HIT (40ms) vs a MISS (300ms). Why isn’t this the case for our broader audience? Does enabling edge caching mean MISSes actually take longer to process than a Standard or Bypass cache setting?

Thanks for any advice.

May I ask does it contain Cache Level: Cache Everything option using a Page Rule or you mean just on Edge Cache TTL option?

Furthermore, static HTML webpages aren’t cached by default → Cache Level: Standard as follows in the Cloudflare docs for “Default cached file extensions”:

Rocket Loader could help a bit too, if not in some conflict with other scripts at your website. Try and test it out for sure.

Can you provide us with some URL address of your domain name for example so we could check this too?

Thank you. Yes, it is set to Cache Everything. Here’s the page rule:

Cache Level: Cache Everything, Edge Cache TTL: 7 days

May I ask, how about the Browser Cache TTL option?
Have you enabled it and set to some value?

Browser Cache is set to Respect Existing Headers. We’ve been using Cloudflare, with this Browser Cache setting for a couple months now, successfully. Only last week did we add the Cache Everything and Edge Cache TTL rules, and our page download times have been negatively impacted.

Example URLs:

And here’s one I have set to the cache to Standard (with a more specific Page Rule), for comparison purposes:

May I ask how did you test this?

I used online tools + my Web browser (mobile and desktop, 4G LTE + fibre / Wifi):

It is amazingly fast!
Only what I see are the 3rd-party resources like Google Adsense / Amazon which I assume could be the thing about slowness, but you cannot affect a lot on that.

For all theree, very fast.
Less than a second.
I see cf-cache-status: HIT, incicates it’s using Cache Everything and cache-control: max-age=3600 (set to 1 hour).

Loads in approx. 1 second.
True, using Page Rule “Standard” as far as HTML webpage not being cached and I see cf-cache-status: DYNAMIC.

Despite using Cache Everything in a page Rule, may I suggest enabling options (features) in Cloudflare dashboard in general for your domain name - I do not know which plan are you using, but:

  • Auto Minify (HTML, CSS, JavaScript), Brotli, Rocket Loader
  • HTTP/2, HTTP/3, 0-RTT
  • Polish & Mirage (if using Pro plan)

Nevertheless, once someone visits your URL addres, the first one will have to “wait” a second or so longer (MISS or REVALIDATE). But, each other visitor who visits the same URL later will have it faster (HIT) as long for 3600s (1 hour) until the cache will be re-generated again.

1 Like

I very much appreciate you digging into this. Agreed, I see very fast times when testing on my local machine or doing one-off tests with tools such as the ones you listed.

The tool I’m using to conclude that the site is slower overall, on average, is page timing reports in Google Analytics, which takes a sample of real-world download times from our actual users.

Yes, we have a lot of the other settings you recommended enabled. Our sites have sped up quite a bit since turning them on in November (again, according to Google Analytics, as well as Core Web Vital reports in Google Search Console).

Since making the one change last week to enable edge caching of HTML, our average page download times are up close to 40%.

I understand that the first time a user visits a given page, in a given part of the world closest to a Cloudflare CDN node, it will be slower than the subsequent users in the same area. What’s baffling to me is that apparently that first visit (MISS) is far slower that having HTML caching disabled entirely (DYNAMIC), as we had before making this change.

Right, correct.

As far as I remember, they could keep some results in the “cache”, or rather indicate based on last 28 days - which could fluctuate and change.

I too got everyday reports from GSC too about the page speed, as far as some articles and it’s webpage URLs are never visited except the Google Crawler / Indexer - whom visits them 1st time, and of course the result is “bad” as it cannot be cached since before that one visit.

I am using cache-control which is set to 900 seconds (at the origin → Origin Cache Control: On option within Cache Everything in the same Page Rule), which is lower than yours 3600, for my WordPress articles (already generated HTML pages cached at origin + cached at Cloudflare).

  • for images I am using a Page Rule of 1 year, while 1 month for CSS/JS …

Approx. website loads in a second, but depending on the count of the visitors, it’s relatively easy for the origin host/server to re-generate a new set of HTML webpages which visitors open, therefore they “newly generated” are over and over again cached at Cloudflare (Cache Everything). I am also running WordPress (incl. origin cache plugin W3 Total cache and page cache).

About “MISS”, “DYNAMIC”, “HIT”, from my below screenshot, daily I have approx. 35k MISS and approx. 80% cached at Cloudflare :slight_smile:

  • but I know it’s a normal thing so I do not bother too much about this + the reports from GSC as far as I know it fast enough for everyone …

  • Not a small number for a sum of DYNAMIC + BYPASS + MISS + NONE + EMPTY

From above screenshot, if we look closely at “html” - it is a real rainbow of colors :wink:

When I filter by above “MISS”:

  • jpeg 15k, “unknown” approx. 10k, empty 5k, html 5k


Thank you. That is helpful insight.

Maybe I’m misunderstanding how the cache works. To take one of my pages as an example,

The page last was changed/flushed on Monday. Since Tuesday, just in the U.S., it has had 13 HITs and 77 MISSes. If there are around 50 Cloudflare nodes in the U.S., how could there be more than 50 MISSes? Or are there 77+ Cloudflare CDN nodes in the U.S.?

Maybe a better example is a page that hasn’t been updated at all this year. Over the last 7 days, it has 440 HITs and 300 MISSes in the United States.

According to this page, there are 39 nodes in the U.S.

How could there be 300 MISSes on only 39 nodes? Shouldn’t the page be cached after the first MISS?

FYI, Google Analytics Average Page Load Time includes 3rd party requests so ads and other 3rd party can blow out your Average Page Load Time. Averages aren’t as useful without accompanying percentile metrics too i.e. 75, 90, 99% percentile (see below Google Data Studio / Google Anaylytics dashboards).

For Cloudflare Cache Everything page rule for HTML page cache, you should look at Google Analytics Average Server Response Time metric as the measured metric as that roughly translates to Time To First Byte (TTFB) which is what CF Cache Everything page rule is operating on improving and filters out factors that CF Cache Everything page rule has no direct impact on only that 3rd party requests usually only load after the HTML page is loaded.

You can setup a custom Google Analytics dashboard just to monitor Average Server Response Time (TTFB) over time. As GA dashboards are limited, you can also import your GA data into Google Data Studio for more in-depth insights.

Example of my Google Data Studio reports for TTFB using my Google Analytics data

Desktop/Mobile and slowest TTFB by country on right column

Then drilldown to a date’s specific hourly TTFB

Google Data Studio can also create interactive Geo Map charts so clicking on a country or URL can drilldown only on specific metrics for that country or URL :slight_smile:

GIF example


This allows you to narrow down your TTFB and CF cache everything page rule effectiveness by country and URL and time of day to see trending patterns. Why? Because GA metrics are real world users so looking just at averages ignores spikes (99% percentile metrics) for the slowest user request i.e. slow mobile device from far away country.

Example drill down on country/city level Average Server Response Time GA metric (TTFB) sorting URLs by slowest TTFB descending for USA only

Also when looking at cache hit %, make sure you exclude URL requests for patterns which are not meant to be cached in the first place. So you would filter to only HTTP 200 status requests, non cdn-cgi URL requests, any URLs you specifically set to exclude cache so that leaves a more accurate picture of cache effectiveness i.e. filter cache analytics only to HTML requests as well.


Cloudflare caches on a per data center basis usually. So with 250+ datacenters, you can have up to 250 cache misses for a URL - once per datacenter. Now if you enable Tiered Cache, your cache hit rate can go up potentially as a group of Tiered datacenters now site between CF Edge server and your origin to serve a cached version of your page where possible. Now when CF Edge has a cache miss it talks to Tiered cache datacenters first to see if there’s a cached copy there first before going to talk to your origin.

1 Like

I’ve enabled Tiered Caching on most of my free plans and it’s been helping.


Wow, I enabled Tiered Cache last week, and now Cloudflare Analytics reports 95% HITs. :+1:

However, my Google Analytics Site Speed makes it seem like my average Page Loads took a big hit, even though the server response and page download times are clearly improved.

I want to be able to shrug it off, since in theory the only thing this change should impact is the server response time, but it’s still concerning. Does anyone know of a reason why a cached HTML page would load slower than an origin pull?


Great to hear :slight_smile:

As mentioned above average page load time includes 3rd party assets like ads and tracker codes so they can have a varying page speed impact between page loads.

1 Like

Thank you. I understand Analytics Page Load has other factors, and it certainly could be coincidence. My point is that the only variable I changed was the caching. I am comparing the page load times before and after implementing caching. Of course, I have a lot more data “before” so perhaps this will even out in the days ahead.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.