Full-page cache in PrestaShop: when it helps and what to leave out

Every time someone opens a product page, PrestaShop starts up, queries the database dozens or hundreds of times, builds the template and returns the HTML. For the next visitor who opens the same page, it repeats exactly the same work. A full-page cache stores that HTML the first time and serves it directly on subsequent requests, without running PrestaShop.

The difference in server response time can be huge. But a store is not a blog: it has a cart, a session, customer-specific prices and a cookie banner. Caching what should not be cached is the quickest way to show one customer another customer's cart.

The caches PrestaShop already has (and how this one differs)

• Smarty template cache: stores compiled templates. It speeds up page building, but PrestaShop still runs on every visit.
• Object or query cache (Memcached, Redis, APCu): stores query results. Less load on the database, but PHP still runs.
• OPcache: stores compiled PHP. Essential, and nothing to do with the HTML.
• Full-page cache: stores the final result. It is the only one that avoids running PrestaShop.

They do not compete: they add up. A well-built store always has OPcache, plus query and page caching depending on its traffic and catalogue.

Which pages can be cached

The practical rule: cache for the anonymous visitor with no cart. As soon as there is a customer session or products in the cart, the page is generated normally.

What you need to sort out before enabling it

Dynamic parts inside a cacheable page

The product page is the same for everyone, but the cart counter in the header is not. Nor is «Hello, Marta», nor the prices if you have customer groups with different price lists. There are two ways to handle it: do not cache for anyone with a session or cart, or load those parts afterwards via AJAX. The first is the safest.

Prices by group, country or currency

If a B2B customer sees different prices, they must never receive the anonymous cached version, nor the other way round. The same applies to currencies and countries that change taxes: either a version is stored for each combination, or those visits are not cached.

Mobile and desktop

If your theme generates different HTML for mobile, you need separate versions per device. If it is a purely responsive theme, a single version is enough.

Cookies and consent

This is the one most often overlooked. If your cookie banner decides on the server which scripts are printed, the first cached page «freezes» the decision of whoever generated it. A visitor who accepted everything generates the page with the pixels active, and the next visitor, who has not decided yet, receives them anyway.

The usual solutions: have the banner apply blocking in the browser, on a page that is the same for everyone, or have the cache store separate versions according to consent status.

Invalidation: the real problem

Caching is easy. The hard part is knowing when a stored page is no longer accurate. In a store it happens all the time:

• You change a price or a description.
• You enable a cart rule or a specific price.
• A product sells out with an order.
• You edit a category, a brand or a CMS page.

If the cache does not find out, customers see the old price or a product shown as «in stock» that no longer is. There are two strategies: time-based expiry (the page is valid for an hour and is then regenerated) and event-based purging (saving a product clears whatever it affects). The right approach is to combine them: purge when you change something, with expiry as a safety net.

And something worth knowing: changes that do not go through the back office —an import via direct SQL, an ERP that writes to the database without using the API— do not trigger any event. If your stock comes in that way, you need to clear the cache at the end of each sync.

When it is not worth it

• Stores where almost all traffic is logged in, such as a B2B store where everyone signs in: the hit rate will be low.
• Catalogues that change every few minutes through supplier syncs: the cache is purged before it serves anything.
• A server that is slow for another reason: a badly indexed query or a module that calls an external API on every page. The cache hides it for anonymous visitors, but the customer who buys still suffers it in checkout, which is where it matters.

First, an up-to-date foundation

A page cache on PHP 7.x and PrestaShop 1.6 still serves anonymous visitors quickly, but the cart and payment, which are never cached, stay just as slow. With PHP 8 and a well-configured OPcache, and PrestaShop up to date, the part that cannot be cached is already much faster. That is why, in a store that is far behind, updating is usually the first performance step and caching the second.

Checklist before enabling it

• OPcache enabled and with enough memory.
• Cart, order, payment, account and module controllers excluded.
• No caching for visitors with a session or cart, or dynamic parts loaded via AJAX.
• Consent test in two private windows.
• Price test: change one and check the product page reflects it.
• Stock test: order the last unit left and look at the product page.
• Cache cleared at the end of each external sync.

How to solve it in PrestaShop

All In One Cache manages three caches from one panel: full-page cache on disk, SQL query cache in Redis (PrestaShop 8 or later, with the orders, carts, sessions and stock tables blocked by default) and OPcache. For the page cache you decide what is left out, including URLs by regular expression, you can keep separate versions per device and purging is hooked into PrestaShop: saving a product, a category, a specific price, a cart rule or a CMS page clears it, and validating an order or changing stock purges the stock-related cache. You can also clear a specific URL or everything from the panel, and you can see hits and misses. If you would rather we set it up and tested it on your store for you, there is the All In One Cache service.