Adobe Commerce (Magento 2) Cloud Flare FPC worker for performance optimization

Let's talk about the Cloudflare FPC Worker.

This is a JavaScript script that runs on the Cloudflare CDN serveless EDGE workers and acts as a full page cache (FPC) and optimizer for Magento. It improves content delivery performance, filters traffic, and supports various advanced optimizations. You can configure it to do almost anything.

It’s an open-source tool, and all you really need is one file — the FPC script. First, you copy this code. You also need to have Cloudflare properly configured for your website.

To set it up, go to Cloudflare, then to the Workers section, and add a new Worker Route for your site. Choose the Worker, open the Code tab, and paste the script. That’s it — nothing more is needed.

Now let’s test how it works. For example, using the React Luma theme, open the Network tab in your browser’s developer tools. You’ll see responses time in very fast — sometimes in 18 milliseconds, sometimes 37 or 22. Overall, response times stay between 50 and 80 milliseconds. In many cases, the response doesn’t even reach your origin server. It’s served directly from the Cloudflare Worker edge cache or R2.

This setup supports private content and has other useful optimizations. The Cloudflare cache status will show “HIT”, meaning it was served from cache. We also use FastCache on the backend (e.g., PHP FastCache), and both systems can work together. You can even add Varnish if you like, though this edge cache might be enough.

Unlike traditional caches, this one doesn’t rely on expiration timeouts. Instead, it revalidates the cache every 30 seconds or based on other criteria. For example, by checking the Age header, you’ll see how long the content has been cached. Once it reaches 3600 seconds, the system performs revalidation. A status like “hit-stale” means it's serving stale content that will be refreshed in the background.

You can also manually invalidate the cache by using the “cf-purge: true” header. This can be password protected. After purging, the page is still quickly returned to the user, while a background request fetches the new version.

In addition, the cache can filter GET requests. For example, a GET request with a Facebook tracking parameter might still result in a cache HIT if it doesn’t affect the content. But another GET request might bypass the cache if it does influence output. These behaviors are fully configurable. You can whitelist specific GET parameters and block others using filters like “filter_get” and “allowed_get”.

All configuration can be done without modifying the code. Go to the Worker settings, then add variables in the Variables section. Set variable names and values accordingly. These variables let you override default settings.

There’s also support for KV storage (key-value storage), where you can store cache versioning. Additionally, you can use R2 storage to keep cached content in Cloudflare’s object storage. This feature costs extra, so check the pricing.

As for pricing, the Worker service allows 100,000 requests per day for free. CPU usage is minimal — in our case, around 3 milliseconds per request. The $5 permonth plan covers 10 million requests, plus $0.30 for each additional million. That’s enough for medium and even large websites. Running Varnish would cost significantly more due to memory and infrastructure requirements, but with Workers, everything is in the cloud.

If you need R2 pricing, note that it comes with additional costs based on usage.

That’s it for today. Use open-source solutions. Don’t fall for overpriced agency offerings that sell you basic tools for huge money. Everything you need is open-source — contribute, open issues, build cool stuff.

By the way, this isn’t a real GitHub issue — it’s just a personal note to myself.

And remember: don’t do business with Russia or Belarus. Support Ukraine.

Видео Adobe Commerce (Magento 2) Cloud Flare FPC worker for performance optimization канала Yegor Shytikov