What Is Full-Page Cache in PrestaShop and How Does It Improve Performance?
Full-page cache stores the generated HTML of a PrestaShop page so that compatible future requests can reuse it instead of rebuilding the page from scratch.
The main benefit is simple: PrestaShop has less work to do before sending the page to the visitor. When a cached page can be served directly, much of the repeated PHP execution, database processing, module hooks, and template rendering can be skipped. This can reduce server response time, especially TTFB, and lower server workload on frequently visited pages.
However, an ecommerce store cannot cache every request in exactly the same way. Cart data, customer state, currency, prices, language, and other dynamic information may vary between visitors. Effective full-page caching therefore depends on more than simply saving HTML: it must also handle cache variations, dynamic content, lifetime, invalidation, and exclusions correctly.
How Full-Page Cache Changes a PrestaShop Request
Without full-page cache, PrestaShop normally has to process a request before it can return the final HTML.
For a product or category page, this may involve PHP application logic, database queries, modules and hooks, product and pricing data, Smarty template processing, and finally HTML generation. If the next visitor requests essentially the same page, much of that work may be repeated.
Full-page cache changes this process by reusing the final output.
On the first eligible request, there is no reusable cached version yet. This is a cache miss. PrestaShop generates the page normally, and the resulting HTML can then be stored.
On a later compatible request, the caching system finds the stored HTML. This is a cache hit. Instead of rebuilding the page through the normal PrestaShop rendering process, the server can return the cached HTML directly.
See the infographic below for a clear comparison of how a PrestaShop request is processed without full-page cache versus with a cache hit.
The performance gain comes from avoiding server-side work that has already been completed, not from making the HTML itself faster.
What Does Full-Page Cache Store?
Full-page cache primarily stores the generated HTML response.
Images, CSS, JavaScript, fonts, and other static resources are separate assets. They are handled by other optimization layers. For example, browser caching reduces repeated downloads of those resources rather than avoiding PrestaShop page generation. If you need to optimize that layer, see How To Optimize Browser Cache for Performance in Super Speed.
Why Full-Page Cache Can Improve PrestaShop Performance
Full-page cache is most useful when generating the HTML itself is a meaningful part of the delay.
Without reusable cache, similar product or category requests may repeatedly trigger PHP execution, database queries, modules, hooks, and template rendering. With a cache hit, much of this work can be bypassed.
The relationship is:
Repeated page rendering → repeated PHP/SQL/module processing → longer server processing → cached HTML reuse → less repeated processing → faster server response
This can improve performance in two important ways.
First, a cache hit can reduce TTFB because the server can begin returning an existing response without completing the normal page-generation process.
Second, it can reduce server workload, especially when many visitors request the same catalog pages.
Full-page cache will not solve every type of slowdown. If the main bottleneck is images, JavaScript, hosting, a slow module, or another part of the stack, that problem needs to be addressed separately. If you are not yet sure where the delay comes from, use Why Is My PrestaShop Store Slow? Causes & How to Diagnose before focusing on page cache.
Why Ecommerce Full-Page Caching Needs Special Handling
A PrestaShop page is not always identical for every visitor.
The same product URL may need to display different information depending on language, currency, country, customer group, cart state, prices, promotions, or visitor-specific module content.
A cache system therefore cannot safely assume that every request for the same URL should receive exactly the same stored HTML.
There are two main ways to deal with this.
Create Separate Cache Variants When the Page Differs
The caching system can include relevant storefront context when determining whether an existing response can be reused.
For example, different currencies or customer groups may require different cached versions of the same page. This keeps the cached content accurate, although creating more variations also means fewer requests can share each individual cache.
With Super Speed, separate cache versions can be created based on storefront context such as language, currency, country, customer group, cart state, shop, and device type, helping ensure that visitors receive the appropriate cached version of the page.
Keep Selected Content Dynamic
Some parts of a page can remain dynamic while the reusable part of the page stays cached.
For example, a product page may be suitable for caching while its cart counter or customer-specific block still needs to show current information. Those areas can be refreshed separately instead of forcing the entire page to be regenerated.
The goal is therefore not to cache everything. It is to cache reusable content while keeping visitor-specific information accurate.
When a custom module or feature should not use the normal cached output, Super Speed provides exception controls for pages, modules, and hooks. The practical setup is covered in How To Disable Cache for Specific Pages/Features with Super Speed.
How Cache Lifetime and Invalidation Keep Content Fresh
Cached HTML is useful only while it still represents the current store.
A cache lifetime determines how long a cached response remains valid. Once it expires, a fresh version must be generated before that page can be cached again.
The appropriate lifetime depends on how often the page changes. A relatively static CMS page can usually be cached longer than content that changes frequently.
Cache invalidation solves a related problem. Instead of waiting for the lifetime to expire, an affected cache can be cleared when relevant content changes. For example, updating a product can invalidate its old cached output so visitors do not have to wait for the normal expiration time before seeing the new information.
The objective is to balance:
More cache reuse for better performance ↔ timely refreshes for accurate content
There is no need to choose cache lifetimes blindly. Super Speed allows different page types to use different lifetimes and provides several automatic cache-clearing options. The available settings and recommended lifetimes are explained in How to Configure Page Cache in Super Speed module.
For stores that need to tune these settings around inventory changes, dynamic prices, traffic, or other business requirements, use the more detailed Super Speed - Optimal Page Cache Configuration Guide.
How Super Speed Implements Full-Page Cache in PrestaShop
Super Speed includes a full-page HTML cache designed around the PrestaShop request lifecycle.
For an eligible request, Super Speed checks for a matching cache before normal page dispatch continues. If a valid cache exists, the stored HTML can be returned immediately. If not, PrestaShop renders the page normally and the resulting HTML can be cached for later use.
This directly addresses repeated page generation:
PrestaShop generates the page → Super Speed stores the HTML → compatible future requests reuse it → repeated PHP, SQL, hooks, and template processing can be reduced.
Handling Different Storefront Contexts
Super Speed does not rely on the URL alone when creating cache variations. Its cache logic can distinguish relevant contexts including shop, language, currency, country, customer groups, cart presence, and user-agent differences when configured.
This reduces the risk of a cached response from one storefront context being incorrectly reused in another.
Handling Dynamic Content
Super Speed can also keep selected parts of a cached page dynamic. Supported module hooks can be reloaded through AJAX, while cart/customer information and prices have additional dynamic-loading options when required.
This allows the reusable HTML to benefit from full-page caching without requiring every part of the storefront to become static.
The module also allows merchants to choose which page types are cached, define exceptions, configure cache lifetimes, and automatically invalidate supported caches after relevant changes. Detailed configuration belongs in the dedicated Page Cache guides above rather than being repeated here.
How to Check Whether Full-Page Cache Is Working
Enabling page cache does not automatically mean visitors are receiving cache hits.
A simple test is to open an eligible page several times under the same visitor context. The first request may be a cache miss because PrestaShop still needs to generate the page. A subsequent compatible request should be able to reuse that cached response. To confirm whether a request is actually being served from page cache, follow this step-by-step guide to checking Cache HITs in PrestaShop.
With Super Speed, you can inspect generated cached URLs, cache-hit information, failed cache creation, and cache-clear history. The Cache History guide in Super Speed module explains where to find and interpret this information.
When testing, verify two things:
- Performance: Do confirmed cache hits reduce server response time compared with uncached requests?
- Accuracy: Do prices, cart state, language, currency, customer-specific information, and recently updated content remain correct?
A fast cached response is not enough if it displays stale or incorrect storefront data.
Full-Page Cache Is About Avoiding the Right Work
Full-page cache does not make a PrestaShop store completely static. It prevents PrestaShop from rebuilding a page when an existing HTML response can safely be reused.
A cache miss still goes through normal page generation. A cache hit can bypass much of that repeated PHP, SQL, module, hook, and template work. Cache variations and dynamic-content handling protect visitor-specific information, while lifetime and invalidation rules keep cached content fresh.
When repeated server-side page generation is a significant part of a store's response time, full-page cache can therefore reduce both TTFB and server workload.
Super Speed applies this mechanism directly within PrestaShop. Once you understand how the cache works, the next step is to configure Page Cache in Super Speed for your store, then verify that eligible requests produce cache hits without affecting storefront accuracy.