Super Speed - Optimal Page Cache Configuration Guide

The Page Cache feature in the Super Speed module is one of the most powerful tools to accelerate your PrestaShop store. It captures the static HTML code of a webpage and saves it as a file on the server. On subsequent visits, the module serves this static HTML file immediately rather than forcing PrestaShop to fully re-render the database, PHP and hooks, resulting in a significantly faster Time to First Byte (TTFB).

Critical warning before you begin: After enabling Page Cache, always thoroughly test your storefront's interactive, dynamic features. Pay close attention to AJAX-driven and JavaScript elements such as Add to Cart, Checkout forms and Customer Registration/Login. If these elements malfunction, disable Page Cache immediately, resolve the functional conflict via the Exceptions tab, and then re-enable caching.

1. General baseline configuration (What 95% of stores should enable)

This standard configuration serves as the perfect baseline for typical B2C e-commerce websites. It maximizes caching efficiency while maintaining necessary system updates.

Page cache

• What it does: Toggles the entire page caching system on or off. When enabled, the module generates and serves raw static HTML cache files. When disabled, pages render dynamically using the native PrestaShop execution flow.
• Recommendation: ON. Activate this only after verifying that your front-office interactive features (login, checkout) function smoothly without caching conflicts.

Preserve combined CSS/JS filenames after cache reset

• What it does: Retains the identical filenames of compiled, minified CSS and JavaScript assets even after a global cache flush.
• Recommendation: ON. If turned off, browser clients and external CDNs are forced to hard-download entirely new asset files every single time a cache reset occurs, causing temporary performance drops. Keep it enabled to maximize browser-level cache efficiency.
• When to turn OFF: Only turn this off if you have deployed structural stylesheet updates or scripts and need to forcefully break browser caching ("cache-busting") for all visitors.

Generate particular page cache for each user-agent

• What it does: Instructs the module to build separate, distinct static cache files based on the visitor’s device type (Desktop vs. Mobile/Tablet).
• Recommendation: ON. Modern PrestaShop themes (such as Warehouse) alter the structural DOM trees, modules and layouts depending on whether a mobile device or desktop browser is requested. Splitting the cache avoids mobile layout breaking on desktops and vice versa.
• When to turn OFF: Turn this off only if your theme is purely responsive (serving the exact same HTML payload to all devices) to save disk space and accelerate cache generation.

Automatically delete page cache when install/uninstall hook

• What it does: Wipes the page cache automatically whenever a module is installed, uninstalled, or hook position structures are updated in the Back Office.
• Recommendation: ON. Adding or moving modules directly alters your front-office layout. Leaving this on ensures old cached pages do not display broken layouts or ghost modules.

2. Options to turn OFF (Debug, heavy tools, & resource hogs)

These options write data heavily to your storage or clear caches too frequently. They should remain OFF on production sites unless you have a highly specific diagnostic requirement.

Cache hits

• What it does: Increments an internal log counter every time a cached static file is served to a customer, visualizing metrics on your Dashboard and the Cached URLs tab.
• Recommendation: OFF (for high-traffic production sites).
• Why: To log hits, the module must execute a database write command on every single page view. For high-traffic storefronts, this constantly taxes the database server, undermining the performance gained by using a static cache.
• When to use: Turn this on exclusively during testing, staging, or initial development phases to audit whether the cache is functioning as intended, then disable it immediately for live deployment.

Compress cache file

• What it does: Compresses generated HTML static files into .zip archives on your server storage to save disk space.
• Recommendation: OFF (unless your server is strictly limited on storage capacity).
• Why: While it saves minimal disk space, the server CPU must perform real-time extraction and decompression work before sending the payload back to the browser client. This adds an unnecessary server-side processing delay to your TTFB.

Automatically delete page cache when change performance configuration

• What it does: Erases the entire static page cache collection when structural performance settings are modified inside PrestaShop or the module.
• Recommendation: OFF. Modifying backend configurations does not always require destroying your entire cached catalog. It is far safer to keep this disabled and manually click Clear all page caches when you purposefully modify major optimization settings.

3. Specialized business logic settings (Tailoring On/Off switches)

Case A: Inventory control & heavy-editing stores

Automatically delete page cache when editing page data

• Standard rule: ON. This ensures that whenever an admin modifies a product price, description or category structure, the old cache file is targeted and cleared immediately, so front-end shoppers see updated details.
• Special action (Turn OFF if): Your server has weak hardware resources or you regularly perform massive bulk catalog updates (via store ERP integrations, CSV imports). Turning this on during rapid data shifts causes continuous cache clearing and recreation loops, causing high CPU load. Turn it off and rely on a shorter Cache Life Time or execute a manual clear post-import instead.

Automatically delete page cache when adding or deleting a product from cart

• Standard rule: OFF.
• Why: Turning this on creates massive server overhead because the cache file for a product (or its categories) is forcefully wiped and regenerated every single time any shopper adds an item to their cart.
• Special action (Turn ON if): Your shop sells rare, high-value, or unique products (e.g., antiques, one-off artwork, flash-sale items where stock count = 1) and you must display a real-time, ultra-strict "Sold Out" or stock counter badge directly on category/product listings.

Case B: Pricing configurations & B2B/Wholesale stores

Dynamically load product prices via AJAX

• Standard rule: OFF (if every customer sees the exact same retail price across your store).
• Special action (Turn ON if): Your store utilizes complex, dynamic price structures, customer-group specific price tiers, country-dependent tax rules or rapid flash discounts. Turning this on keeps the layout cached but fetches accurate, live pricing via an immediate AJAX request after the page loads.

Use all customer groups for caching

• Standard rule: OFF. The module defaults to generating standard, baseline cache structures.
• Special action (Turn ON if): You manage a dedicated B2B or hybrid wholesale/B2C store where specific logged-in customer groups see completely distinct layout elements, catalog permissions or special structural pricing tiers. This configures the engine to append a customized cache key unique to each customer group ID.

Always reload cart and user information dynamically

• Standard rule: OFF for ultimate speed optimization. The cart module only fires an AJAX request once an active session contains item contents.
• Special action (Turn ON if): You notice user-interface bugs in your theme's header or footer blocks (e.g., cached pages mistakenly display a previous visitor’s name or show an empty cart when items are actually present). Enabling this guarantees that user data blocks are always dynamically fetched on top of the cached layer.

Case C: Ecosystem module interconnectivity

Auto-delete cache via associated PrestaHero modules

(Appears dynamically if modules like Cross Selling PRO, Home Products PRO, Mega Menu PRO, or Custom Fields & Tabs are active).

• Recommendation: ON. Keeps your layouts completely uniform. When you tweak an option inside your Mega Menu or update an extra tab, Super Speed knows exactly which cached pages are impacted and flushes them automatically.

4. Analytical tracking settings

The delay time between page loading time checking

• What it does: Dictates the interval frequency (in seconds) used by background AJAX scripts to gauge frontend performance and populate the Page speed timeline metric chart on your module Dashboard.
• Recommendation: 5 seconds. Do not set this value any lower, as ultra-frequent performance pings can place unneeded, repetitive load onto your server environment. This setting operates strictly behind the scenes and does not impact frontend loading times.

5. Recommended cache life time matrix (Pages to cache)

To achieve the best balance between conserving server disk I/O and keeping content fresh, map your expiration sliders according to this specialized matrix: