Cloudflare for PrestaShop — real benefits and limits

Cloudflare works as a reverse proxy and CDN placed in front of the store's server. All traffic reaches the Cloudflare network first and only then, if needed, goes on to your origin. Static assets — images, CSS, JavaScript, fonts — can be served from a node close to the user, without involving the server. Dynamic requests, meaning everything PrestaShop generates per user, still go back to the origin.

Let's set the proportions straight up front: this is not a “for PrestaShop” integration. Cloudflare sits the same way in front of WordPress, Laravel, or any other PHP application. So most of what we describe applies to any store behind such a proxy, and what makes PrestaShop stand out comes from the nature of the store itself, not from special support on Cloudflare's side.

How much Cloudflare helps is decided by a given store's traffic profile. A typical PrestaShop means lots of product photos, each in several size variants, plus the theme's CSS, JavaScript and fonts, crawler traffic indexing the catalog, expensive dynamic PHP and MySQL requests, periodic traffic spikes during promotions, and plenty of modules and endpoints.

From that setup comes a simple relationship worth keeping in mind behind every promise of a speed-up:

The benefits of Cloudflare in front of a store are concrete, but each has its boundary condition. Here's what you usually see in practice — without promises this layer can't keep.

Less traffic and transfer on the origin. Caching static files reduces the number of requests and the volume of data the server has to handle itself. The biggest effect shows up on images and other static assets, and on traffic Cloudflare stops before the server. Don't assume an automatic CPU drop, though: simply sending a static file rarely loads PHP or MySQL, so you mainly save on connections, transfer, and web-server work.

Faster assets for users in distant regions. Images, CSS files, JavaScript and fonts can be fetched from a Cloudflare point closer to the user rather than from the origin every time. That shortens the load time of those assets, but not the time to generate the dynamic page — that still depends on your server.

More resilience to some traffic spikes. When traffic grows on what can be served or rejected at the edge, the origin takes a smaller hit. The caveat matters: a sudden surge of non-cacheable requests such as the cart, API, or search can still overload the backend, because those go straight to PHP and the database.

Filtering out some bots and attacks. Caching limits repeat fetches of static assets, and bot-protection mechanisms stop some unwanted traffic before the server. Just be careful not to block legitimate crawlers without analysis — Googlebot fetches dynamic HTML anyway, so the claim that “the crawler loads the origin less” is not unconditional.

A security layer in front of the server. Cloudflare can stop part of the scanning, automated attacks, abuse attempts and overloads before they reach PrestaShop. It does not, however, fix a vulnerability in a module or replace updating the store and server; a flaw in the code still has to be closed on your side.

Images: transformations at the edge. Cloudflare can process images on the fly — resize, crop, optimize and deliver a modern format — without keeping every variant on the server. As of this article's last update, the Free plan includes up to 5,000 unique transformations per month, where “unique” means a combination of the source image and its parameters, not every view. Once you exceed the limit on Free, previously made transformations keep being served from cache and only new ones are rejected. It's a practical alternative to generating all thumbnails on the store side.

PrestaShop can generate optimized formats itself, while Image Transformations create size and format variants at the edge without storing every version on the origin. Which to choose depends on the number of photos and variants, available space, CPU cost, and how images are managed in the store — neither option wins every time.

Extra data and observability. You also get insight into traffic: statistics, security events, and information on what is being rejected and cached. That's the material that later lets you judge whether the deployment actually did anything — which we come back to at the end.

One note on the stack: Cloudflare sits in front of nginx, Apache and LiteSpeed the same way. HTTP/3 here concerns the connection between the user and the Cloudflare network, and does not automatically mean the origin also speaks HTTP/3.

Cloudflare is a layer in front of the server, so everything that happens on the server itself stays on your side. It won't speed up slow controllers, unindexed queries, bloated modules, or an overloaded PHP-FPM and MySQL. It won't help when a page is slowed by an external API blocking its generation, excess JavaScript in the theme, weak hosting, a slow checkout, poorly prepared source images, or Core Web Vitals problems (the metrics for how well a page loads) arising from rendering and interaction.

That's why Cloudflare doesn't replace optimization on the store side. Redis, PrestaShop's cache, OPcache, database indexes, order in the modules, and correct PHP configuration are still needed. Those things solve problems on a different layer than a CDN, and one without the other isn't enough.

Don't count on caching the whole HTML “out of the box” either. Automatic Platform Optimization, which does this for WordPress, has no ready integration with PrestaShop; a similar effect has to be built yourself, together with correct cache invalidation. The simplest rule to remember: if an anonymous page is slow because the origin takes long to generate it, the edge layer won't shorten that. Measure first where you're losing time — if the bottleneck is the backend, Cloudflare isn't the answer.

For many stores the Free plan is a good starting point. You get a CDN and static caching, basic security mechanisms, HTTP/3, the ability to build your own rules, and — less obviously — the 5,000 unique image transformations per month mentioned above. That's usually enough to get going and see how much you gain in practice.

You reach for a paid plan in response to a concrete need, not “on principle.” It's usually one of these situations:

Most problems with Cloudflare in front of PrestaShop don't come from Cloudflare itself, but from a deployment stopped halfway. Two of these mistakes show up most often and bite hardest in production, so we'll start with them.

An exposed origin. Setting the “orange cloud” in DNS does not stop the server from accepting connections directly. The origin address is often known from DNS history, mail headers, old “DNS only” records, or other services on the same server — and anyone who knows it can send requests that bypass Cloudflare, and with it the cache, WAF, and rate limiting. On your own VPS or dedicated server, HTTP and HTTPS traffic should be accepted only from Cloudflare's ranges and from the integrations you actually rely on; account for both IPv4 and IPv6, and prepare separate exceptions for monitoring or callbacks. The allowlist alone is a useful layer, but Cloudflare classifies it as “moderately secure”; a stronger option is Authenticated Origin Pulls, which let the origin verify that a request came from the Cloudflare network, or Cloudflare Tunnel. The key takeaway: simply connecting your domain to Cloudflare does not protect the server from direct traffic.

An unrestored real visitor IP and a stale fail2ban. Behind a reverse proxy the server sees connections from Cloudflare addresses, and receives the real client address in a header (among others, CF-Connecting-IP). If you don't restore it, logs, geolocation, anti-fraud rules, server-side rate limiting, and maintenance mode will see Cloudflare addresses instead of clients. On Apache this is done with mod_remoteip, on nginx with the Real IP module and a list of trusted Cloudflare ranges — and that header may be trusted only when the connection originated from a trusted Cloudflare address, otherwise it can be forged. The same applies to fail2ban. It's not that it needs “updating because Cloudflare arrived”; after deployment you have to review how it reads the client address from logs, which trusted ranges it knows, and how it enforces bans. The key nuance: a ban on the origin firewall may stop working, because the connection to the server is made by Cloudflare, not the user — so bans have to happen either at the application and web-server level after the address is restored, or be pushed to Cloudflare via the API as rules acting at the edge. Cloudflare explicitly warns, in fact, that without the restored address fail2ban can accidentally block Cloudflare's own addresses and cause errors for many users at once.

The remaining mistakes are less spectacular but just as costly:

Since we're talking about benefits, it's fair to show how to confirm they actually happened. You don't need benchmarks or impressive percentages in a slide deck — it's enough to watch a few metrics before and after deployment: