PrestaShop Cache: Full Page Cache Modules Explained — Pros, Cons and What They Actually Do

We build Performance Revolution, so we have skin in this game — but we'll be honest with you anyway. A full page cache module can turn a 3-second PrestaShop into a 200ms one in an afternoon. For most shops we audit, that's the right move on day one. Whether it's still the right move on day ninety depends on what's actually causing the slowness, and whether you ever plan to fix it.

What Is Full Page Cache?

Out of the box, every PrestaShop page request boots PHP, loads the framework, runs anywhere from 40 to 400 SQL queries, compiles Smarty templates, and finally returns HTML. On the dev shops we run, that's 200–400ms. On the average shared-hosting PrestaShop we get called in to rescue, it's 2–5 seconds.

A full page cache (FPC) module skips all of that. The first visitor to a page renders it normally; the module grabs the finished HTML and stashes it. Every visitor after that gets the stashed copy — no PHP boot, no database, no Smarty. Just bytes from disk, Redis, or Varnish.

TTFB drops from seconds to tens of milliseconds. There is no faster way to make a slow PrestaShop feel fast without rewriting the slow bits.

How PrestaShop FPC Modules Work

The pattern is the same across every FPC module we've reviewed, ours included:

1. First visit — page renders normally through PrestaShop, module captures the HTML on the way out, writes it to a store (file, Redis, Memcached, or a CDN edge).
2. Subsequent visits — module intercepts the request before PrestaShop boots, checks for a cached copy, serves it, exits. PrestaShop never loads.
3. Session-less HTML — the cached page can't contain "Welcome back, John" or "3 items in cart", because it was captured without a session. Generic by definition.
4. JavaScript hydration — after the static HTML lands, AJAX fetches the per-user pieces: cart count, login state, currency, recently viewed. The browser patches them in.

That last step is the whole trade-off in a sentence. The server gets fast; the browser does more work afterwards.

The Pros — And They Are Real

Instant Time to First Byte

1–5 seconds collapses to 20–100ms. Nothing else you can install on a PrestaShop will move the needle this hard. Google's Core Web Vitals care about it directly, and so does your bounce rate. If your hosting, your database, or your module stack is the bottleneck, FPC walks around the problem instead of solving it — and for a lot of shops, walking around is fine.

A genuine lifesaver for shops in rough shape

We've inherited shops with 47 active modules, a 14GB database, and no developer on retainer. The owner needs the site fast by Black Friday. A weekend of profiling and refactoring isn't on the table. FPC ships, and the shop is competitive again on Monday. That's not a compromise — that's the correct call for that shop on that timeline.

What FPC really does is mask whatever is slow underneath. If you can't afford to fix the underlying thing right now, masking it is exactly the tool you want.

Reduces server load

On shared hosting where you've got 2 PHP workers and a CPU quota, every request that gets served straight from cache is a request that doesn't touch PHP. We've seen the same shop go from collapsing at 30 concurrent users to serving 300 without breaking a sweat after enabling FPC, on identical hardware.

Better Google rankings — but read the next section

Page speed is a confirmed ranking factor, and a 200ms shop will outrank a 4-second one. FPC delivers that with minimal effort. Just note that "faster TTFB" and "better Core Web Vitals" are not the same thing — read on.

The Cons — What to Be Aware Of

The session hydration problem

This is the visible price of every FPC module on the market.

The cached page renders session-less. Cart icon shows 0. Header says "Sign in" even when you're logged in. Recently viewed is empty. Currency is the shop default, not the visitor's choice. A heartbeat later, the AJAX request lands and the JS patches it: cart count appears, name swaps in, currency switches.

On a fast connection with a fast device, that heartbeat is barely perceptible. On a mid-range Android over 4G (which is most of your real traffic) it's a visible flicker. We've watched recording sessions in Microsoft Clarity where users click the cart icon while it still says 0, get the empty cart page, and bounce. Cached pages can do that to you.

CLS (Cumulative Layout Shift)

Those hydration patches move things around. A "Sign in" link is narrower than "Welcome, Jonathan Stevens". A 0 cart count is one character; a hydrated 3 is three with a badge. Each swap shifts neighbouring elements.

You can win LCP on FPC and lose CLS by exactly the same margin. We've seen Performance Revolution shops post Lighthouse scores in the 90s for LCP and the 60s for CLS purely because of hydration shifts. Reserve space for the dynamic elements in the cached HTML (fixed-width cart badges, skeleton placeholders for the customer name) or you'll watch your gains evaporate in the Vitals report.

Stale content risk

A cached page is a frozen photograph. Update a price, flip a stock status, enable a flash sale, change a category description — the cached copy keeps showing yesterday's reality until the cache invalidates.

This is where FPC modules genuinely differ from each other, and it's worth understanding the choices:

• Hook-based invalidation (what Performance Revolution does, and what most serious modules do) — listens to actionProductUpdate, actionObjectCartRuleUpdateAfter, actionUpdateQuantity, and a dozen others, and purges only the affected pages. Fast, surgical, and correct most of the time.
• TTL-only invalidation — every cache entry expires after N minutes. Simple, dumb, predictable. Wrong for up to N minutes after any change. Fine for content shops, dangerous for stock.
• Manual purge — admin clicks "clear cache" after changes. Don't ship this; merchants forget.

Even hook-based invalidation has holes. ERP imports that write directly to the DB skip every hook PrestaShop fires — the cache never knows the stock changed. Cart rules with complex conditions touch products you didn't expect. Third-party modules that hold their own state break the assumptions. We chase this in support tickets often enough to be cautious about anyone claiming "perfect invalidation."

Debugging gets weirder

The first question on any cached shop is "is this the cache?" You'll find yourself purging cache reflexively at the start of every bug investigation, and you'll learn the hard way that AJAX endpoints behave differently to cached HTML pages, and that "logged-out preview" tools lie when hydration is involved. Worth doing — but worth knowing about going in.

Where each storage backend bites you

Quick honest take from running all three in anger:

• File cache — easiest, no infra, fine on a single-server shop. Falls over under concurrent writes. On a busy product update during an import you can deadlock yourself.
• Redis — what we default to in Performance Revolution. Fast, no file-locking, works across multiple PHP workers. Costs you a Redis instance (we run a shared ps-redis across 20+ shops, no issue). Hard memory ceiling; tune your maxmemory-policy.
• Varnish / reverse proxy FPC — fastest of all because the request never reaches PHP at all. Also the hardest to invalidate cleanly (ESI for the dynamic bits is its own learning curve), and not all hosts let you run it. If your host already has it configured, use it. Otherwise the PHP-level FPC modules will get you 90% of the win with 10% of the operational pain.

Going Deeper: Fixing the Root Causes

Everything above is what FPC masks. If you have the budget and the calendar, fixing the underlying slowness gives you the same speed without the hydration jumps, without the stale-content worry, and without the debugging tax.

This doesn't have to be one giant project. We've watched shops go from 4-second TTFB to 300ms over six months of incremental fixes, one item per week. Treat it as a backlog, not a sprint.

One genuine warning: don't half-finish an optimisation project. A live shop with broken CCC, half-tuned MySQL, and a Redis instance that crashes every Sunday is worse than the same shop with a well-configured FPC and nothing else. Done beats perfect.

1. Identify Slow Modules

This is the number one cause we see, by a wide margin. A single module running an unindexed query inside displayHeader adds 500ms to every page. A stats module logging every view synchronously to the database adds 200ms. Three of those stacked and your shop is at 3 seconds before any rendering work.

How to find them:

• Enable PrestaShop's debug profiler (_PS_DEBUG_PROFILING_ in config/defines.inc.php). It prints time spent per hook per module at the bottom of the page. Read it.
• On PrestaShop 8+, the Symfony toolbar gives you query counts and timings per request. Anything over 100 SQL queries on a product page is suspicious.
• Disable modules one at a time, hit the page with curl, time the TTFB. The before/after delta is exactly how much each module costs you.

Repeat offenders: social feeds fetching live API data, view counters that INSERT on every request, "related products" modules that run cosine-similarity in PHP, SEO modules that regenerate metadata on every page load instead of caching.

2. Fix Smarty Template Compilation

Smarty compiles .tpl files into PHP. In production this should happen once per template and never again.

• force_compile = off. If it's on, every template recompiles on every request — that's 200–500ms of wasted CPU per page.
• caching = on.
• After deployments, clear the compile cache once. Don't leave force_compile on as a "temporary" workaround.

The number of shops we've inherited where someone left force_compile on six months ago after a debugging session is depressingly high. Check yours.

3. MySQL Configuration

The default MySQL config is for a generic server, not your PrestaShop. The settings that matter:

• innodb_buffer_pool_size — the one that actually matters. 50–70% of available RAM. A 2GB database with a 128MB buffer pool is hitting disk constantly.
• innodb_log_file_size — at least 256MB on write-heavy shops.
• slow_query_log = 1 with long_query_time = 1 — flip on for a week, read the log, you'll find the queries that need killing.
• Clean up ps_connections, ps_log, ps_mail. These grow to millions of rows on long-lived shops and slow down every SELECT that joins them.
• Add the missing indexes on your custom module tables. They're probably there.

4. Use Redis for Cache and Sessions

PrestaShop's default file cache uses filesystem locking under the hood, which serialises concurrent requests. Switch to Redis and three things move to RAM:

• Smarty cache — template output goes from disk reads to memory reads.
• Symfony cache (PrestaShop 8+) — routes, containers, annotations.
• PHP sessions — the file-locking problem that causes requests to queue under load disappears.

One 256MB Redis instance handles all three for most shops. The improvement is largest under concurrent load, smallest on a single-visitor dev shop — measure where it matters.

5. PHP and OPcache Tuning

• PHP 8.1+ — 20–40% faster than 7.4. If you're still on 7.4, this is the cheapest performance gain you'll ever buy.
• OPcache — must be on. Set opcache.validate_timestamps=0 in production and reset it manually after deployments. We get the cPanel-style remote reset wrong often enough to have written it down — see our notes on OPcache for the gotchas.
• Realpath cache — bump realpath_cache_size to 4096K. PrestaShop opens hundreds of files per request and pays the stat() cost on each one otherwise.

6. Front-End Optimization

• CCC (Combine, Compress, Cache) — bundles CSS and JS, cuts HTTP requests. Built into PrestaShop. Turn it on, watch for modules that ship broken CSS that breaks the combined bundle.
• Critical CSS — inline the above-the-fold styles, defer the rest. Eliminates render-blocking CSS. We automate this in Performance Revolution with Critters, because doing it by hand per template is a nightmare.
• JavaScript deferral — analytics, chat widgets, social embeds go behind defer or requestIdleCallback. They don't need to block your LCP.
• Image optimisation — WebP/AVIF (25–50% smaller than JPEG), responsive srcset, explicit width/height on every <img> to prevent CLS.
• CDN — edge-cache static assets. Complementary to server-side caching, not a replacement.

The combined effect

These stack. Killing slow modules saves 500ms–2s. MySQL tuning saves 100–300ms. Redis saves 50–200ms. PHP 8 + OPcache saves 100–300ms. Critical CSS shifts perceived load by 500ms–1s. A 4-second shop can realistically reach sub-200ms rendering fresh on every request — fresh stock, fresh cart, no hydration, no stale content.

This takes time and expertise. If you don't have either right now, a properly configured FPC module is the better answer.

Bottom Line

Full page cache modules work. They serve static HTML and patch in the session bits with JavaScript, which costs you visible hydration jumps, some CLS, and a slightly trickier debugging experience. In exchange you get the largest single performance win available in PrestaShop without touching anything else.

For shops that need speed today and can't afford a deep optimisation project, that trade is correct. For shops with the resources to fix the slow modules, tune the database, install Redis, and ship critical CSS, FPC isn't doing anything you can't beat with a healthier stack underneath.

The pragmatic path most of our clients take: install a good FPC module now, keep the deeper work on the roadmap, knock items off it as time allows. Eventually you can retire the cache — or keep it as a belt-and-braces second line. Either way, your shop ends up fast, and you get there without breaking it on the way.

Related reading

• Performance Revolution — our take on PrestaShop FPC plus critical CSS, CCC, and image optimisation in one module
• Instant Redis — drop-in Redis configuration for PrestaShop's cache and sessions
• Performance tuning PrestaShop database queries — what to fix when you decide to go deeper than FPC