A Hyvä-themed Adobe Commerce store will outperform a default Luma store on almost every Core Web Vitals dimension. Put that same store behind a properly configured Cloudflare deployment and you can pull another 200 to 400 milliseconds out of Largest Contentful Paint on the long tail of geographies. The combination is genuinely best-in-class for mid-market eCommerce performance, but the configuration matters. A default Cloudflare setup in front of Adobe Commerce will help. A purposeful one will transform.
The most common mistake we see is treating Cloudflare like a checkbox. Teams flip on the proxy, leave the default rules, and call the work done. Cloudflare’s real value on Adobe Commerce comes from the rules you configure, not the proxy you switched on. Image resizing, page rules, cache rules, and security settings all interact with how Magento generates responses, and each one has a Magento-specific gotcha that can either accelerate the site or break it.
Bemeir has rolled Cloudflare in front of dozens of Hyvä storefronts. The patterns below are the ones we use as a baseline, adjusted per client based on traffic profile and business rules.
Layer the architecture explicitly
Before you touch the Cloudflare configuration, draw the architecture. Most teams skip this step and then get confused about why a cache invalidation behaves the way it does. The drawing matters because there are three caches in the path, and they have to cooperate.
The first cache is Cloudflare itself, operating at the edge. The second is Varnish, operating in front of Magento. The third is Magento’s full-page cache, which can be either Varnish or Redis depending on configuration. The TTL and invalidation rules at each layer have to be consistent. If Cloudflare caches for one hour, Varnish caches for four, and Magento clears full-page cache on every product save, you will see stale content in the wild and not understand why.
A sensible default is Cloudflare at one hour on cacheable assets, Varnish at four hours, and Magento’s FPC tied to product and category save events. Cloudflare invalidation should be wired to fire when Magento clears its own FPC, either via Cloudflare’s API from a Magento observer or via a webhook the deployment pipeline runs. The Cloudflare cache purge documentation explains the API mechanics.
Cache rules that work on Adobe Commerce
The single largest win on Cloudflare for a Hyvä store is correct cache rules. The default behavior caches static assets and bypasses everything dynamic. That is the right starting point but it misses a meaningful amount of traffic that is functionally cacheable.
Three cache rules pay for themselves on most Magento stores. The first caches category and product page HTML at the edge for logged-out users, with a key that includes the country code if you do multi-country selling. The second caches the GraphQL endpoint for catalog queries that do not involve user-specific data, with the user-specific paths excluded by query inspection. The third caches the product media library aggressively, with long TTLs and image resizing applied at the edge.
The table below summarizes the rules we typically end up with on a mid-market Adobe Commerce store. These are starting points, not absolutes.
| Path or rule | Edge TTL | Notes |
|---|---|---|
| /static/ and /media/catalog/ | 30 days | Magento fingerprints these, safe to cache long |
| /pub/static/* | 30 days | Theme assets, safe to cache long |
| /graphql GET requests | 1 hour | Cache only on logged-out, exclude cart and customer queries |
| Category and product HTML for logged-out users | 1 hour | Honor Vary on Country and Currency cookies if multi-country |
| /checkout/, /customer/, /cart/* | Bypass | Never cache these |
| /admin/* | Bypass | Never cache, also restrict by IP |
The hardest part of these rules is correctly identifying logged-out users at the edge. Cloudflare can inspect cookies and bypass cache when a session cookie is present, which is the pattern we use most often. The Cloudflare Workers documentation on cache API shows how to push this logic into Workers if you need more nuanced behavior than page rules allow.
Image optimization is the single biggest LCP lever
Largest Contentful Paint on a product page is almost always an image. The product hero image is usually the LCP element, and how that image is served determines your LCP score more than anything else.
Cloudflare offers two image optimization features that are dramatic on Adobe Commerce. Cloudflare Images stores and serves images through a managed pipeline. Polish and Mirage transform existing images on the fly. For most mid-market stores, the right answer is Polish in lossy or lossless mode, depending on visual sensitivity, combined with Mirage for adaptive resizing on mobile.
The combination, when configured correctly, replaces the entire need for image processing modules in Magento. You upload an original image to the media library, and Cloudflare serves the appropriately sized, appropriately formatted version to each device. WebP and AVIF are negotiated automatically. The format negotiation alone typically reduces image weight by 30 to 50 percent versus the JPEG that Magento served before.
Hyvä cooperates well with this pattern because the theme uses standard responsive image markup. The srcset attributes work with Cloudflare’s resize parameters out of the box. If you are using Hyvä’s image rendering blocks, you can configure the resize URL template to point at Cloudflare’s image transformation endpoints and have the theme do the right thing without per-template edits.
A side benefit of edge image optimization is that you can remove the local image processing pipeline from Magento entirely. The bin/magento catalog:images:resize command can be skipped on deploy, and the resized image storage on the application server stops growing. Storage savings on stores with large catalogs are meaningful. The Adobe Commerce image management documentation covers what the native pipeline does that you would be replacing.
Page Rules to handle the Magento idiosyncrasies
A few Page Rules are specific to Adobe Commerce and worth setting up explicitly.
Magento generates ?___store= query parameters when handling store views in some configurations. These break edge caching if not handled. Set a Page Rule to ignore these parameters in the cache key when the value matches the requesting region. Magento also generates ?___from_store= parameters during store switching, which similarly fragment the cache. Treat them the same.
The cart and checkout flows must bypass cache. Magento exposes a Cookie called PHPSESSID that you can use as a bypass signal, but the better pattern is path-based: explicitly bypass /checkout, /customer, /cart, /onestepcheckout, and /admin. This is more durable across Magento upgrades than cookie-based logic.
Finally, the GraphQL endpoint deserves attention. Magento serves GraphQL on /graphql, and the same endpoint handles both cacheable catalog queries and uncacheable cart queries. Cache rules should distinguish based on the query content, which is non-trivial. The pragmatic pattern is to use Cloudflare Workers to inspect the GraphQL body, hash the query, and cache only queries that match a list of safe patterns. Bemeir’s Magento engineering practice has built this pattern for several mid-market clients and the GraphQL caching alone reduces backend load by 20 to 40 percent.
Security and rate limiting that does not break the site
Cloudflare’s WAF and rate limiting are powerful and will break your site if you turn them on without thought. The Adobe Commerce admin endpoints, the WebAPI for partner integrations, and any custom search functionality have request patterns that look bot-like to default WAF rules.
Three configuration patterns we use consistently. Allowlist the IP ranges of any partner integration, like ERPs, search providers, and review platforms, in the WAF settings. These services make rapid sequential requests that look suspicious without context. Set rate limits at the path level rather than globally, with higher thresholds for the GraphQL endpoint and lower thresholds for the admin and login endpoints. Enable Bot Fight Mode in observe mode for two weeks before flipping it to active, to confirm that no legitimate partner traffic is being blocked.
The Cloudflare WAF managed rules documentation explains the relevant rule sets. The Magento-specific gotcha is that the SQLi and PHP RFI managed rule groups occasionally flag legitimate Magento URL parameters. Test in observe mode before enforcing.
Measuring the impact
Set up a measurement loop before you make any of these changes. The minimum you want is Real User Monitoring data for LCP, TTFB, and CLS on the page types that matter most. Cloudflare provides Web Analytics for free, and the web-vitals JavaScript library plugs into any analytics destination if you prefer to send data into your existing observability tool.
Measure the baseline for two weeks. Then roll changes in sequence: edge cache rules first, image optimization second, GraphQL caching third, security rules fourth. Each change should be measurable in the RUM data within 72 hours. If a change does not produce a visible improvement, revert it and investigate why. Stacking unmeasured changes is how you end up with a configuration nobody understands.
Bemeir’s experience across Hyvä migrations is that a clean Cloudflare layer adds roughly 200 to 400 milliseconds of LCP improvement on top of the Hyvä migration itself, depending on geography and original baseline. The combination puts most mid-market stores comfortably in the green band for Core Web Vitals across every device class. For brands selling internationally, the geographic effect is even larger because Cloudflare’s edge network handles long-tail latency much better than a single-region application server.
The work to set this up properly is one or two sprints of focused engineering. The payoff is durable. Cloudflare’s defaults will not get you there. The Adobe Commerce-aware configuration patterns will. If you are also running Shopify Plus or Shopware stores in parallel, the principles translate cleanly even though some of the specifics differ. Edge first, image optimization second, GraphQL discipline third, security last. That sequence holds across platforms.
