How Page Cache Handles Cart, Customer Data and Dynamic Content in PrestaShop

Why Dynamic Content Complicates Page Caching

A PrestaShop product or category page often contains both reusable and dynamic information.

The product name, description and much of the page layout may be identical for many visitors. Other data can change according to:

• language;
• currency;
• country;
• customer group;
• login state;
• current cart;
• pricing rules;
• dynamic module output.

The challenge is therefore not simply deciding whether a page should be cached.

The more useful question is: Can this request safely reuse an existing cached page, or does some part of the response need different treatment?

Page caching handles these differences through several mechanisms, depending on what changes and how that content needs to stay current.

How Page Cache Handles Dynamic Content

Page caching is more complicated on an ecommerce store than on a static website because the same URL does not always produce the same content.

Two visitors can open the same product page but need to see different currencies, prices, customer information or cart states. A safe cache system therefore cannot simply save one HTML response and serve it to everyone.

The key is to separate reusable page content from visitor-specific or frequently changing content.

In practice, this is handled through three main mechanisms:

• cache variants;
• dynamic content loading;
• cache invalidation and exclusions.

If you first need the basics of how full-page caching works, see What Is Full-Page Cache in PrestaShop and How Does It Improve Performance?.

1. Use Cache Variants When the Whole Page Depends on Visitor Context

A cache variant is a separate cached version of the same URL for a different storefront context.

For example, if the same product page displays EUR for one visitor and USD for another, both requests should not automatically share the same cached HTML.

The same principle can apply to:

• language;
• currency;
• country;
• customer group;
• cart state;
• shop;
• device-specific output.

The cache uses these relevant differences to decide whether an existing page can be reused or a separate version is required.

This prevents one storefront context from receiving cached content generated for another.

The trade-off of cache variants

More cache variants improve content separation, but they also reduce how often each cached version can be reused.

A page with several languages, currencies and customer groups may need many possible cache versions.

The relationship is simple:

More context separation → safer cached output → more cache variants → lower cache reuse per variant

The goal is therefore not to create a unique cache for every visitor. Variants should only be created for contexts that can actually change the rendered page.

In practice, a caching solution can apply this principle by separating cache versions only when relevant storefront context changes. For example, Super Speed creates separate cached page versions based on relevant storefront context, such as language, currency, country, customer group, cart, shop, and device context.

2. Load Small Dynamic Areas Separately

A page does not need to become completely uncached just because one part of it changes for each visitor.

For example, a product page may be mostly reusable while its header contains:

• cart quantity;
• login status;
• customer information;
• a personalized module block.

Regenerating the entire page just to update these small areas would remove much of the benefit of full-page caching.

A more efficient pattern is:

Serve cached page HTML → request current dynamic data → update the affected area

This allows the expensive, reusable part of the page to remain cached while visitor-specific content stays current.

The same approach can be useful for product prices when pricing changes frequently or depends on customer context.

When dynamic loading makes sense

Dynamic loading is most useful when:

• most of the page is reusable;
• only a small area changes per visitor;
• that information must remain current.

It is less useful when large portions of the page are dynamic, because every additional AJAX request adds its own browser and server work.

For stores that need this type of cache handling, Super Speed loads selected dynamic content separately from the cached page, including dynamic hooks and module content. It can also reload cart and customer information dynamically and optionally retrieve prices through AJAX when those values should not rely on the static cached page.

3. Invalidate or Exclude Cache When Reuse Is No Longer Safe

Not every dynamic-content problem is visitor-specific.

Sometimes the cached page itself becomes outdated because the underlying store data changes.

For example:

• a product is edited;
• category content changes;
• CMS content is updated;
• stock-sensitive information changes;
• a module begins returning different output.

In these cases, the existing cached HTML may no longer be valid.

There are two main ways to handle this.

Cache invalidation

Cache invalidation removes an existing cached page after relevant content changes.

The next visitor then generates a fresh version instead of receiving outdated HTML.

This is different from using short cache lifetimes. A lifetime waits for the cache to expire, while invalidation can remove it immediately after a known change.

Typical content changes that may justify invalidation include:

• product updates;
• category updates;
• CMS updates;
• certain module or hook changes.

Cart activity may also affect shared storefront content in some stores. For example, if visible stock information must change immediately, cache may need to be refreshed more aggressively.

However, clearing shared cache after every cart action can significantly reduce cache effectiveness. This should only be enabled when the store actually requires that level of freshness.

For stores that need more precise control over cache updates, Super Speed can automatically clear page cache when content changes. This includes changes to page data, performance configuration, and installed hooks. It also provides an optional setting to refresh the page cache after cart changes when information such as available product quantity needs to be updated immediately.

If you're using Super Speed, you can check the detailed cache lifetime and invalidation options are covered in How to Configure Page Cache in Super Speed module.

Cache exclusions

Some pages, requests or modules should not be stored in normal page cache at all.

This is appropriate when the content is highly dynamic or cannot be safely represented by a reusable HTML response.

Examples can include:

• search-related requests;
• currency-changing requests;
• highly personalized module output;
• custom features that behave incorrectly when cached.

Instead of disabling page cache for the entire website, the problematic URL, module or hook can be excluded while other eligible content remains cacheable.

Super Speed provides URL, module and hook exceptions for this purpose.

Instead of disabling page cache for the entire website, the problematic URL, module, or hook can be excluded while other eligible content remains cacheable. This keeps caching active where it is safe and useful, while preventing dynamic or incompatible content from being served from cache.

For PrestaShop stores that need this level of control, Super Speed provides URL, module, and hook exclusions.

For configuration steps, see How To Disable Cache for Specific Pages/Features with Super Speed.

How These Caching Approaches Work Together

These caching methods solve different types of dynamic-content problems, and a page may use several of them at the same time.

• When the whole page changes according to a predictable storefront context: A caching system can maintain separate cache variants.
• When most of the page is reusable but one area is visitor-specific: That area can be loaded dynamically while the rest of the page remains cached.
• When shared content changes for everyone: The existing cached version can be invalidated and regenerated.
• When a request or feature cannot be cached reliably: It can be excluded from page cache.

These mechanisms are not mutually exclusive. A product page, for example, might use a separate cache variant for currency, dynamically load cart information, invalidate its cache after a product update, and exclude a highly dynamic module from caching.

In practice, a caching solution can combine these mechanisms rather than relying on a single approach. Super Speed does this by applying different cache-handling methods to different types of storefront content.

How Super Speed Applies These Mechanisms

Super Speed combines these approaches so that eligible PrestaShop pages can remain cacheable without assuming that all visitors should receive identical HTML.

Its page-cache system can:

• maintain separate cache variants for relevant storefront contexts;
• reload selected cart, customer, price or module content dynamically;
• invalidate cached pages after supported content changes;
• exclude URLs, modules or hooks that should not use normal page cache.

The purpose of these mechanisms is not to make the entire storefront static.

It is to reuse expensive page generation wherever it is safe while keeping visitor-specific and changing information accurate.

How to Verify Your Page Cache Is Working Correctly

Page cache is working correctly when cached pages load as expected without showing outdated or incorrect content to different visitors.

After enabling page cache, open the same page under different storefront conditions and check that the information that should change is still correct:

• Logged out vs. logged in: check that login status and customer-specific information are correct.
• Empty cart vs. active cart: add a product and check that cart information updates correctly.
• Different currencies: switch currencies and check that the correct prices and currency are displayed.
• Different customer groups: if your store uses group-specific prices or content, check each relevant group.
• Different countries or languages: switch the relevant context and check that localized content remains correct.
• Dynamic modules: check modules that display visitor-specific or frequently changing information.
• Price and stock changes: update a product and check that the storefront shows the new information when freshness is required.

The goal is not simply to achieve as many cache hits as possible. A good PrestaShop caching setup should reuse cached content whenever possible without serving incorrect or outdated information.