PrestaShop caching involves more than one switch

When I investigate a slow PrestaShop store, I first establish what the customer is waiting for. A category page that takes too long to respond needs a different fix from oversized product photos that download slowly. A fast homepage does not necessarily mean a fast checkout, either. Caching helps by reusing work that has already been done. The questions that matter are what gets stored, who can receive that stored response, and how the system knows when it is out of date.

A PrestaShop installation can have template caching, data caching, PHP opcode caching, browser caching, and a cache of complete pages. Each handles a different part of the request. Settings and labels also vary between versions and back-office translations. This guide covers current options as well as technologies you may encounter when maintaining an older store. A setting appearing in the back office does not mean your hosting environment can actually support it.

Smarty: template compilation and output caching

I usually start under Advanced Parameters → Performance. Smarty compiles the theme's templates into code that PHP can execute. Forcing compilation on every request is useful during development and troubleshooting, but adds unnecessary work in production. Recompiling when a template file changes is often a sensible starting point. Never checking for changes can work if clearing the relevant cache is a reliable part of deployment. Output caching is a separate mechanism, used by parts of the store and by modules that implement it correctly. Enabling Smarty caching does not automatically create a safe, static copy of every complete page for every customer. Results depend on how each module handles context. After changing these settings, I check prices, availability, language, and behavior for logged-in customers. The main options are described in the PrestaShop performance settings documentation.

File storage, MySQL, and automatic cache clearing

Where the PrestaShop version offers a choice of Smarty cache storage, it is worth distinguishing the file system from MySQL storage. For a typical store running on one server, I generally start with file-based caching on fast local storage. Moving the cache into MySQL may simply give an already busy database more work. Slow network storage or very large numbers of small files, on the other hand, deserve investigation of their own. The rules for clearing the cache after product or theme changes matter just as much. Clear it too often and much of the benefit disappears; fail to invalidate it when necessary and old content stays visible. With several application servers, synchronization needs deliberate planning. Files written locally on one server are not automatically available to the others. The developer guide to optimization covers file caching and the importance of checking module performance.

CCC: smart caching for CSS

CCC stands for Combine, Compress and Cache. For stylesheets, the idea is to prepare and cache processed CSS files so the same work does not have to happen on every request. Depending on the version and theme, this can reduce both download size and the number of files. I always check the result in the actual storefront, particularly the mobile menu, product gallery, filters, and checkout. Processing can expose problems with poorly written CSS or incorrect image paths. There is also little benefit in sending visitors one enormous stylesheet full of rules for features they never use. With HTTP/2 and HTTP/3, reducing request counts alone is no longer a sufficient reason to combine everything. I look at file size, how much of the CSS is used, and its effect on the first render.

CCC: JavaScript caching and web server settings

JavaScript needs a more cautious approach. A module's scripts may depend on a particular loading order or on a library supplied by the theme. After enabling smart caching, I test product combinations, adding items to the cart, signing in, delivery options, and payment methods. Some faults only appear on a particular device or after login. If the installed version offers further HTML or script-loading optimizations, I enable them one at a time and apply the same checks. Processing files through CCC is also different from compressing responses with gzip or Brotli, which is handled by the web server or CDN. The Apache optimization setting applies to a suitable Apache environment; it does not configure Nginx. For the implementation details, the Media class source code provides a useful reference.

Native data caching: Memcache, Memcached, APC, and Xcache

The separate caching-system section selects a backend for data caching. It is not the same setting as Smarty caching, and it does not automatically move every database operation into RAM. Its value depends on which parts of the core and installed modules use it, how frequently they reuse the same data, and the cost of communicating with the cache. You select one backend for this layer, rather than enabling all four together. Before keeping a change, I compare response times with caching enabled and disabled, and with both empty and warm caches. The PrestaShop cache architecture documentation helps explain why the application's different caching mechanisms need to be considered separately.

Memcached through PHP::Memcache

This option connects to the Memcached service using the PHP extension called Memcache, without a final “d”. Installing the service is only half the job: the extension must also be loaded in the PHP environment serving the store. Checking command-line PHP does not necessarily tell you what is available in the store's PHP-FPM environment. Depending on the interface, you enter a server address, port, and possibly a weight. The service can run locally on a single machine or provide shared storage for several application servers. A remote service introduces network traffic, so any performance gain needs measuring. The administrator must also allocate enough memory and keep the service off the public network. Entries may be evicted when memory fills up; this is not permanent storage for orders. Installation requirements are covered in the Memcache extension manual, while the native PrestaShop adapter shows how the connection is made.

Memcached through PHP::Memcached

The second option uses the same type of server service through a different PHP extension: Memcached, with a final “d”. This extension is built on libmemcached and has its own API and installation dependencies. Memcache and Memcached are not interchangeable; the back-office selection must match the extension actually installed. For a new environment, I would consider this option alongside the hosting provider's support, the PHP version, and test results. It is not automatically faster. I check the hit rate, memory use, evictions, and connection latency. I also verify that separate installations use appropriately isolated cache keys, and that clearing one store's cache will not affect another. A shared service can help multiple application servers access the same data, but does not synchronize every other cache in the application. See the Memcached installation manual and the CacheMemcached adapter for the requirements and implementation.

APC and APCu: local data caching

The APC label needs some historical context. The original APC combined user-data caching with PHP opcode caching. In a modern environment, APCu is the relevant extension for user data, while OPcache usually handles PHP code. That explains why a link next to the APC option may lead to the APCu installation instructions. This is more than a naming detail: support must be checked against the actual PrestaShop version. For example, the CacheApc adapter in the 8.2 branch explicitly supports both APC and APCu. Local shared memory avoids a connection to a remote cache service. Its sharing boundaries depend on the PHP setup, however; it is not a network-wide cache for multiple machines. I check memory allocation and behavior after PHP restarts. One practical trap is clearing APCu from the command line: that may not clear the same memory used by the web processes.

Xcache: an option best understood in its historical context

Xcache legitimately appears in older PrestaShop installations and lists of supported backends. It provided caching for PHP code and user variables, with the PrestaShop adapter using its data-storage functionality. I would not choose it for a new store running current PHP simply because the option remains listed. The project's release history largely concerns the PHP 5 generation, which is a very different environment from a current server. Compatibility and ongoing maintenance need to be established first. When taking over an older store, I would check whether Xcache is actually in use, identify any dependencies, and plan the modernization of the environment. Downgrading to obsolete PHP for the sake of one cache would be a poor trade-off. The original Xcache repository remains a reference, rather than a general installation guide for today's PrestaShop deployments.

OPcache and application caches

PHP OPcache stores precompiled PHP code so the server does not have to compile it again for every request. It is an important part of a PrestaShop hosting environment, but is not another data backend in the list above. I check that it is active for web requests, has enough memory, and can accommodate the number of PHP files. If change detection is disabled, deployments must explicitly refresh the cached code. PrestaShop also maintains internal application caches, including Symfony mechanisms in its modern components. These may need clearing after service configuration changes or module deployments. The “Clear cache” button should not be taken to mean that copies in the browser, every module, and Cloudflare have all disappeared. When old content persists, I identify the layer responsible.

Browser caching and HTTP headers

A properly configured server allows the browser to reuse images, stylesheets, scripts, and fonts instead of downloading them in full again. The main controls are the Cache-Control header and, where applicable, Expires. ETag and Last-Modified can help check whether a resource has changed. Long lifetimes suit static files whose URLs change when a new version is deployed. Without that versioning, customers can keep using old CSS even after the store's own cache has been cleared. Personalized HTML needs different rules from a product photograph. The Apache configuration documentation includes examples for static resources; Nginx needs equivalent server configuration. I inspect the headers actually delivered to the browser, because a proxy can change what the original configuration intended.

Cache modules from addons.prestashop.com

The official marketplace includes products such as Page Cache Pro and Page Cache Ultimate. These are examples worth comparing, rather than universal recommendations. Modules in this category may cache complete pages or substantial portions of the generated output, reducing the work PHP needs to repeat on a cache hit. Public catalog pages are often the most promising use case. Before purchasing, though, I check support for the exact PrestaShop version, PHP version, theme, and essential modules. I also look at dynamic block handling, automatic invalidation after product changes, and cache warming. A marketing score alone says little about compatibility with a store's pricing rules and checkout.

The cache key is crucial. Depending on context, the same URL can show a different language, currency, tax treatment, customer-group price, or shop-specific offer. The cart, customer account, checkout, personalized responses, and payment return routes need appropriate exclusions or a safe dynamic implementation. For anonymous visitors, I also test what happens as soon as they start shopping. A suitable module must let me verify these scenarios and invalidate affected pages without excessive clearing. I test on a copy of the store, checking correctness as well as speed. Running two full-page cache modules together generally makes it harder to determine where outdated content is coming from.

Media servers: connecting PrestaShop to static content

The native Media servers setting can direct supported static assets to another domain or subdomain, for example a content delivery network, or CDN. Entering an address does not copy any files or create a distribution service. The destination must already serve the required images, CSS, and JavaScript. I then check the HTTPS certificate, paths, availability, and any CORS requirements for fonts. A subdomain pointing to the same server can be useful organizationally, but does not add computing power or geographically closer copies of files. Older advice about splitting assets across several domains to allow parallel downloads also needs reassessing for HTTP/2 and HTTP/3. Additional domains can mean additional connections. I therefore use a media server for a defined purpose, usually as part of a real CDN, and measure the outcome.

Cloudflare: start with static assets, then consider HTML

Cloudflare can sit in front of a store as a reverse proxy and CDN. Configured correctly, it serves eligible static resources through its distributed network and reduces repeated transfers from the origin server. It does not cache ordinary HTML or JSON by default. Changing DNS alone does not stop PHP from generating product pages. A basic deployment also usually does not require changes to the Media servers setting: Cloudflare can work directly in front of the main domain. I verify actual cache hits through response headers and the service's reports, rather than assuming it works because it is enabled. The Cloudflare default cache behavior documentation explains the rules and how origin headers are handled.

Caching HTML at the edge needs rules designed for the particular store. A broad “Cache Everything” rule can store customer-dependent content if the exclusions are incomplete. Excluding one cart URL is not enough: routes, parameters, cookies, login state, and pricing contexts all need consideration. Available rule conditions and cache-key features also depend on the service and plan. Bypassing cache based on a cookie is one tool, rather than a complete PrestaShop configuration. Product changes also need to trigger the appropriate cache invalidation. When combining Cloudflare with a cache module, I establish which component clears each layer, and when.

Advanced setups: reverse proxies, Varnish, and Redis

On a server you control, Nginx FastCGI caching or a reverse proxy such as Varnish may be an option. These store HTTP responses and need the same attention to exclusions, customer context, and invalidation. Redis can support a particular cache or session setup through an appropriate module or custom integration; it is not automatically interchangeable with one of the four native options described above. For this kind of deployment, I want clearly defined responsibilities and reliable server administration. Adding technologies simply because they feature in optimization checklists is not a good reason to use them. The store needs to behave predictably after service restarts, catalog imports, and cache clears as well.

How I would approach caching for a real store

I would begin by measuring the existing store: server response times, database queries, module workload, and transfer sizes. Then I would address obvious bottlenecks and check production mode, OPcache, and Smarty. CSS, JavaScript, images, and static-file headers would follow. Only then would the results guide a decision about a data backend, cache module, or CDN. A cached homepage cannot fix a slow database operation during order placement.

I compare every change on first and repeat visits, on mobile devices, and across different customer scenarios. Alongside TTFB, or time to first byte, and the rendering of the main content, I check current prices, stock changes, discount codes, delivery options, and the complete checkout journey. Performance immediately after a cache clear matters too: it reveals the store's underlying workload. A good cache makes shopping faster while keeping the information correct. If you need help choosing an approach, my PrestaShop performance optimization service starts by identifying your store's actual constraints, then uses those findings to decide what to change.