Full-page caching a Hyvä store with Cloudflare, safely

A fast theme helps, but a cached page helps more. The quickest server response is the one that never reaches PHP.

Hyvä stores are well suited to caching, because the HTML is lean and personal data is loaded separately. That does not make every caching rule safe.

This post explains how we think about full-page caching on Hyvä with Cloudflare in front, and the mistakes we have seen.

Two cache layers, two jobs

There are usually two layers between the visitor and PHP:

• Magento’s full-page cache. Magento stores rendered pages and serves them without running the full application. We use Redis or Valkey as the cache backend. Varnish is another common option.
• The CDN. Cloudflare sits in front of the server, terminates TLS close to the visitor and caches static files.

Magento’s cache knows about store views, currencies and customer groups. Cloudflare does not, unless you tell it.

That is why Magento’s full-page cache is the base layer, and edge caching of HTML is an optional step on top.

Why Hyvä makes caching easier

A cached page must look the same for everyone who receives it. Anything personal, such as the mini cart or the customer’s name, has to be added afterwards.

Magento solves this with private content, also called customer sections. Luma loads them through Knockout and RequireJS.

Hyvä loads the same section data with a small amount of its own JavaScript and then dispatches a private-content-loaded event. Alpine.js components listen for it and fill in the personal parts.

<div x-data="{ count: 0 }"
     @private-content-loaded.window="count = $event.detail.data.cart?.summary_count || 0">
    <span x-text="count"></span>
</div>

The result is a page that can be cached as a whole, with a light request afterwards for the personal parts.

Custom templates must follow this pattern. If a developer prints customer data straight into a PHTML template, that block breaks caching or, worse, shows one customer’s data to another.

What Cloudflare should always cache

Static files and media are the easy part and give the biggest gain for the least risk.

• Static content under pub/static. In production mode the URLs contain a deployed version, so you can use long cache lifetimes.
• Product and theme images under pub/media. Cache them long, and purge after a full image resize.
• Fonts. Self-hosted fonts belong in the static content and are cached with it.

On a Hyvä store, this covers most of the requests a page makes, because a Hyvä page makes relatively few requests to begin with.

Caching HTML at the edge, safely

Cloudflare does not cache HTML by default. You can enable it with cache rules, but then you take over responsibilities that Magento normally handles.

If you go down this route, these rules are the minimum:

• Bypass for anything personal or transactional. Cart, checkout, customer account, wishlist, admin, the REST and GraphQL endpoints and the customer section requests must never be served from the edge.
• Bypass when the visitor has a different context. Magento sets the X-Magento-Vary cookie when the context differs from the default, for example when logged in or using another currency. Requests with that cookie should go to the origin.
• Only cache GET requests with a successful response.
• Keep store views apart. If languages share a domain, the URL must make the store view clear, or pages in one language will be served to another.
• Short lifetimes for HTML. Prices and stock change. A short edge lifetime limits the damage if a purge is missed.

If these rules feel like too much to maintain, keep HTML out of the edge cache. Magento’s own cache on a well-tuned server is already quick, and static files at the edge do most of the work.

Purging: the part people forget

Magento does not purge Cloudflare by itself. Every cache you add needs a matching purge routine.

• After a deploy, flush Magento’s cache and purge Cloudflare, then warm the key pages.
• After a full image resize, purge by hostname. We once had images cached at the CDN before the resize cache existed, and the CDN kept serving the old response until we purged.
• After price or stock changes, make sure the affected HTML expires, either through short lifetimes or a targeted purge.

We describe our deploy steps in production mode and deploys for Hyvä stores.

A sensible default setup

For most Hyvä stores, we start with a setup that is fast and hard to get wrong, and only add edge caching of HTML when there is a clear reason.

• Magento full-page cache enabled, with Redis or Valkey as the backend and enough memory for the whole catalogue.
• Static content and media cached at the edge with long lifetimes.
• HTML passed through Cloudflare to Magento’s cache, so store views, currencies and customer groups are handled by Magento.
• A warm-up after every purge for the home page, main categories and best-selling products.
• Monitoring of cache hit rates in Magento and in Cloudflare, so a broken rule shows up quickly.

This keeps time to first byte low for most visitors, without the risk of serving the wrong page from the edge.

Custom extensions deserve a check as well. A module that disables caching on a common block, or adds a cookie to every response, can quietly turn a cached store into an uncached one.

Pitfalls we hit

• Header-based logic ignored at the edge. Cloudflare’s entry-level plan did not vary its image cache on the Accept header, so our WebP negotiation in nginx had no effect. We moved the logic into Magento instead, as described in serving WebP images behind Cloudflare.
• Security rules affecting tests. Our nginx blocks bot user agents. Lab tools that announce themselves get a 403, which looks like a fast page but is not a real result.
• Testing the origin instead of the real URL. Always test the public URL behind the CDN, after purging and warming the cache.

FAQ

Do I need Varnish for a Hyvä store?

Not necessarily. Magento’s built-in full-page cache with Redis or Valkey works well on a properly sized server. Varnish is a valid choice, especially at higher traffic.

Is it safe to cache all HTML in Cloudflare?

Only with strict bypass rules for personal pages, logged-in visitors and other contexts, plus a reliable purge routine. Without those, keep HTML caching in Magento.

Why does the mini cart still make a request on a cached page?

That is by design. Hyvä loads customer sections after the page so the HTML can be cached for everyone, and only the personal parts are fetched per visitor.

We set up Hyvä-optimised servers with caching, CDN and purge routines as part of our Hyvä packages. For hosting on its own, see Magento hosting.