PrestaShop caching: why it is so delicate, and how to go from 5 seconds to half a second without breaking anything

Open your shop in a private window and count. If the first page takes a while to appear, it is not your connection: it is PrestaShop building it from scratch. On a shop with shared hosting, a large catalogue and a few dozen modules, waiting around 5 seconds for the server to deliver a page is not unusual. With a well-built page cache, that same page can arrive in around half a second.

The catch is that caching PrestaShop is delicate. Done in a hurry, the cure is worse than the disease: customers seeing someone else’s cart, outdated prices, sales that never start. This article explains why it happens, how much you gain when it is done right and what a cache must do before you can switch it on with peace of mind.

What PrestaShop does on every visit

Every time someone opens a page, PrestaShop boots, works out the language, currency and country, loads the controller, runs every hook on the page (each installed module can add its part), fires tens or hundreds of catalogue queries, calculates prices with taxes and discounts, and puts it all together with the theme’s Smarty templates. For most visitors, all of that produces exactly the same page the previous visitor just received.

The options in Advanced Parameters › Performance (Smarty cache, CCC, template compilation) make each step faster, but they do not skip them. PrestaShop has no built-in full-page cache: that is why so many shops turn to modules or their host’s cache, and why so many end up switching it off.

Every second counts for conversion

Speed is not a technical detail: it is money. A 2022 Portent analysis of online shops found that pages loading in 1 second convert far better than pages taking just a few seconds more.

And you do not need to win whole seconds to notice it:

On top of that, the time the server takes to answer is part of what Core Web Vitals and PageSpeed Insights measure: a shop that answers sooner starts ahead.

Why caching PrestaShop is so delicate

A cache stores a page and hands it to the next visitor. Easy, until you remember everything in PrestaShop that changes from one visitor to another, or from one moment to the next:

• Cart and account. The header shows the number of items in the cart and the customer’s name. If a signed-in customer’s page is stored, the next visitor sees “Hello, Marta” and her cart.
• Prices per customer. Customer groups, B2B prices and customer-specific discounts change what the product page shows.
• Currency, country and taxes. PrestaShop can pick the currency and country from the browser or the IP address, and the taxes with them. One page for everyone means wrong prices for someone.
• Prices with dates. Specific prices, catalogue rules and flash sales start and end at a set time. A page stored at 23:59 still shows the old price at 00:01 unless something renews it.
• Stock and catalogue changes. A product that sells out, a new photo or a corrected price must show on the product page, its category and every listing it appears in.
• Modules. Each module can print something different for each visitor: viewed products, form tokens, personalised notices. Some also write settings on every visit, which confuses caches that empty themselves on any change.

That is why caches switched on “the hard way” (some hosts’ caches, an unconfigured Varnish, modules that store everything) end up with the same scares: someone else’s cart, prices that do not match the order, the sale that does not start, an error page stored. And the shop is slow again because someone switches the cache off “just in case”.

What a safe cache must do

Before switching on any page cache in PrestaShop, check that it:

1. Only serves stored pages to visitors with nothing of their own: not signed in, with an empty cart. Everyone else always gets the live page.
2. Only stores pages built for “blank” visitors, without cart, account or history, so nothing personal ever slips in.
3. Never touches the cart, checkout, account or search.
4. Keeps separate pages per currency, country, device and shop, so prices and taxes are always right.
5. Renews a product’s pages as soon as its price or stock changes, without emptying everything else.
6. Expires exactly when a scheduled price or a flash sale starts or ends.
7. Is invalidated when you save any setting in the back office, but not by the modules’ internal bookkeeping.
8. Never stores errors, redirects or half-built pages.

What other cache modules do

PrestaShop has three broad families of solutions, and it helps to know what each one offers:

All of them are valid options, each with its price in configuration, infrastructure or risk.

What makes Page Cache stand out

Page Cache is our full-page cache module for PrestaShop 8.2 and 9.0. It takes a different path: it never stores anything personal, and it gives each visitor their personal parts back separately.

• Safe without configuring anything. Pages are only stored when built for “blank” visitors: even if a module in your shop prints something personal, it never reaches the cache. By default, anyone signed in or with something in the cart gets the live page.
• Faster customers, if you want. With dynamic fragments switched on, signed-in customers and visitors with a cart get the cached page too, and their cart, name and account links appear a moment later. Form tokens are put in the page before it leaves, so “Add to cart” works from the first click. Customers with prices of their own or from other groups keep getting the live page.
• Built for developers. If another module prints something personal, a form with every field explained lets them say which element it is and where its fresh content comes from: a module hook, a PrestaShop event or a page of the shop.
• A check before you switch it on. It opens your pages as two new visitors and shows you any difference between them, so you know whether your shop is ready before turning anything on.
• Prices always up to date. It renews a product’s pages the moment its price, stock, combinations or images change; pages expire exactly when a specific price, a catalogue rule or a Promo Bar message starts or ends; and any setting saved in the back office invalidates everything. Settings that modules write by themselves on every visit do not count: it learns them and ignores them.
• Fast from the first visitor. A warm-up (a button or a cron job) prepares the home page, categories and best sellers before anyone arrives, and the faceted search filters are answered from the cache too.
• Works on any hosting. No override, no .htaccess or server change, no PHP extension. It installs switched off and uninstalls without a trace.
• Transparent. The back office shows how many pages it serves from the cache, the response time with and without it and the waiting saved, and every response carries the X-Ecom-Cache header (HIT, MISS or BYPASS with the reason).

And what it does not do, so you can decide with all the facts: because it answers from PrestaShop (no special server), a cached page still goes through PHP’s start-up, and product pages for signed-in customers are off until the check confirms that no module prints something personal there that is not covered. If you need the absolute maximum with millions of visits, a well-configured server cache may suit you better. For most shops, where nearly all new traffic arrives without a session from Google, ads and newsletters, Page Cache speeds up exactly those visits with no risk.

Want it all in one place? Speed up PrestaShop brings together the page cache, the filters, the search and the checkout, with what we measured and where to start.

Sources

• Portent, Site Speed is (Still) Impacting Your Conversion Rate (2022).
• Deloitte Digital and Google, Milliseconds Make Millions (2020).
• Think with Google, page load time statistics.
• JPresta, Page Cache Ultimate (module description).
• LiteSpeed Technologies, LiteSpeed Cache for PrestaShop.