Andrei Baicus

Hello @bobsled,

That behavior is expected if the cache rule is only set for example.com. Since the plugin keeps that rule in sync, changing it manually to cover www wouldn’t be a good long-term fix.

The better approach is to redirect www to the apex so there’s only one canonical hostname in use. That keeps caching consistent, avoids duplicate behavior between www and non-www, and ensures the plugin-managed rule continues to work as intended.

So my personal recommendation is keeping the cache rule as-is and handling www via a redirect instead.

Hey, @glonojake

We don’t recommend editing the cache rule that Super Page Cache creates in Cloudflare, and you don’t need to set an Edge TTL manually. The rule is intentionally set to “Respect Origin TTL”, which means Cloudflare will use the TTL values sent by the plugin in the response headers (via s-maxage). This is the correct behavior and gives the plugin full control over caching duration. You can find the setting for the TTL under “Advanced” in the dashboard. By default is set to 0, which means the TTL is actually 1 year.

As for the 5.57% hit rate – that’s likely not an Edge TTL issue. A few things that commonly affect hit rates:

• Exclusion rules – logged-in users, WooCommerce cart/checkout pages, and certain cookies can cause many requests to bypass cache. It’s worth reviewing your exclusion settings to make sure nothing is being excluded unintentionally.
• Query strings – URLs with query parameters (e.g. UTM tracking, search queries) are often treated as unique cache keys and won’t hit the cache.
• Low traffic / high URL diversity – if your site has many unique URLs and relatively low traffic, the cache simply doesn’t get warmed up enough to show a high hit rate.
• Cache not yet warmed – if the plugin or Cloudflare cache was recently cleared, the hit rate will be low until traffic rebuilds it.
  

I hope this helps! Have a great day ahead!

@mohsinworld,

There’s not much we can help with without any additional details. Could you maybe provide some error logs from the website after enabling the option so we can see if anything is wrong there?

Otherwise, can you check the browser console and the network tab in the inspector when loading the website with that option enabled so we can see if there’s anything we can spot that’s not working as expected?

Thank you!

Hello @kpbryce132,

From a performance perspective, version 5.x introduced several important improvements, not limited to:

• Can work independently of Cloudflare – Caching is no longer Cloudflare-only, and the static cache works by itself if you want to use it, reliably on any hosting environment.
• Improved cache efficiency – Smarter handling of query parameters, cookies, AJAX requests, and purge logic helps increase cache hit rates and reduce server load.
• Smarter lazy loading – We’ve added a system that detects image placement making above-the-fold images load immediately while below-the-fold content loads lazily for faster perceived performance.
• Font optimization – Added some option to combine and locally host Google Fonts to reduce external requests.
• Database optimization tools – Clean up revisions, drafts, spam, and transients to keep the database lean.
• More reliable background processing – Improved scheduling and cache preloading stability.

Overall, versions from 5.0.0 onwards deliver better cache reliability, improved efficiency, and broader compatibility compared to 4. You can see a full changelog here.

The Pro version further enhances performance with advanced CSS and JavaScript optimization, including critical CSS generation for even better Core Web Vitals.

I hope this sheds some light on the differences. Have a great day ahead!

Hey @imtino @cocoa1,

Thank you for reporting this! I’m sorry for the inconvenience. This seems to be a bug on our end. I’ve submitted a fix for it and it will be deployed in the next update.

All the best!

Hey @gaiusjaugustus,

Sorry for the slow follow-up.

We’ve released a patch update that should fix exactly this situation if you didn’t already try fixing it with the suggestion @kushnamdev provided.

Have a great day!

Hello @frenchomatic,

Thank you for your message and for sharing your concerns regarding country-level blocking and the plugin’s behavior. I want to clarify that the plugin does not intentionally break or alter its behavior when Cloudflare security rules, such as country blocking, are active.

It does not contain any code or logic that would detect or respond to the presence of Cloudflare’s security rules, nor does it rely on any outbound requests whose failure would break the plugin’s functionality.

Could you please share more specific details about what’s going wrong? The more information you can provide about the issue, the better we’ll be able to assist you.

Have a great day ahead!

Hey @vellkan!

Thank you for the kind words, and sorry for the confusion!

You are right, both Page Rules and Worker Routes should be empty. The status of the toggle was an oversight from our part when we migrated settings to the new interface. Previously we accounted for the Cache Rule being saved when rendering it as enabled.

We just released an update that should migrate the setting properly from older versions, so the status of the toggle should be enabled now.

But from today, with that new version of plugin – should we turn on that switch? I saw that cache was working in Developer Tools, but before turning it on cache rules were empty for that specific domain, I feel naked without that.

In short, if you enabled the switch and saved settings, the only thing that would have happened is that the plugin would’ve checked if the rule is already set, and updated its own value. Things would have worked the same as they already do, as the rule was properly set up.

In short, this was a rendering logic issue, not a functionality one.

I hope this helps clarify things for you! Please let us know if we can help with anything else.

Have a great day!