How do I clear PrestaShop cache properly?

To clear PrestaShop cache properly, start in the back office: Advanced Parameters > Performance, then click Clear cache. That is enough for most template, translation and configuration changes.Performance page — the Clear cache button and cache controls.When a change still does not appear, clear the deeper layers in the right order: PrestaShop files first, then OPcache, then any CDN, Varnish or full-page cache in front of the shop.# Run from the PrestaShop root. This deletes cache contents, not the cache directories themselves. find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Older PS 1.6-style installs may also use these Smarty paths: find cache/smarty/compile -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find cache/smarty/cache -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Reset web OPcache by reloading the PHP service: sudo systemctl reload php8.2-fpm # Apache/mod_php alternative: sudo systemctl reload apache2Do not rely on a CLI-only opcache_reset() command unless you know CLI and web PHP share the same OPcache pool. On normal PHP-FPM hosting, reloading PHP-FPM is the reliable reset. After a server-level clear, make sure the web-server user can write the cache directories again; wrong ownership after a root-level cleanup is a common cause of new 500 errors.The common mistake is clearing only the back-office cache and assuming OPcache or a reverse proxy followed. They do not. If you want cache warming and CDN purge automation instead of doing this by hand, Performance Revolution includes cache warming and CDN purge logic, and Instant Redis helps manage a Redis cache backend.

How much RAM does PrestaShop need?

There are two separate numbers here and confusing them is the most common mistake.PHP memory_limit (per request) — this is what PrestaShop actually consumes per page load or admin action. The official PrestaShop 9 documentation recommends at least 512 MB. PrestaShop 8 was happy with 256 MB; the bump in PS 9 reflects the heavier Symfony stack in the back office. Import/export, module installs, mass product updates and the migration assistant all need this higher ceiling — set it lower and you will get blank screens or "Allowed memory size exhausted" fatals.Server (host) RAM — this is total memory on the VPS or dedicated box, shared between PHP-FPM workers, MySQL/MariaDB, web server, Redis or Memcached, cron jobs and the OS. Practical baselines:Under 1 000 SKUs, light traffic: 2 GB is the realistic floor.Mid catalog (1 000 to 20 000 SKUs), caching enabled: 4 GB is comfortable.Large catalog (50 000+ SKUs) or multistore: 8 GB+ and a dedicated MariaDB tuning pass.Bulk imports, image regeneration, big migration jobs: add headroom or move heavy tasks to CLI cron.If the shop feels slow, RAM is rarely the first thing to fix — start with full-page cache, Redis, OPcache and a smaller theme. See our PrestaShop performance tuning guide for the actual order of operations.A useful capacity check is not simply memory_limit x max_children, because not every worker reaches the limit at once, but the formula tells you whether the host is impossible on paper:PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroomFor example, ten busy PHP workers with a 512 MB ceiling need more than a 2 GB VPS once MariaDB is included, even if most requests use less than the ceiling. Keep CLI limits high for image regeneration and imports, but avoid letting too many PHP-FPM workers run on a small server. If the Linux OOM killer starts killing PHP or MariaDB, lowering worker count and fixing cache/database pressure is usually better than only raising memory_limit.

What monitoring data can the module store?

Performance Revolution stores technical monitoring data about your shop, but not every monitoring table has the same privacy profile. RUM rows are built around timings, URL, device class and shop context rather than customer profile fields; slow-query logging is different because it stores raw SQL text and stack-trace context, so treat it as potentially sensitive diagnostic data if your queries contain customer, cart or order identifiers.Concretely, the module keeps these tables:Performance metrics - timed measurements with a metric type, value and JSON context, used to chart how the shop behaves over time.Aggregated metrics - rolled-up values by hour, day, week and month, including sum, average, min, max and count, so dashboards remain usable on longer date ranges.Slow queries - query hash, SQL text, execution time, controller, stack trace, occurrence count and first/last seen timestamps. The schema may contain extra placeholders, but the profiler path records those fields rather than rows examined or rows sent.Real-user monitoring (RUM) - browser timing data from sampled visits: TTFB, FCP, LCP, CLS, FID and INP, plus DOM timing fields, a resource-timing summary, URL, device type and shop.RUM aggregates - hourly per-URL, per-device sample counts and averages for the RUM metrics. The aggregate schema includes a p75_lcp column, but the current aggregation query does not populate it.Common mistake: treating all monitoring data as equally low-risk. RUM is timing/device diagnostics, but slow-query rows can expose whatever was present in the SQL statement. Restrict access to those diagnostics the same way you would restrict access to database logs.The defaults are deliberately conservative. Fragment cache is enabled with a 3600-second TTL, query cache is enabled, metrics are enabled, the slow-query threshold defaults to 0.1 seconds, metric retention defaults to 30 days, profiling is off by default, and RUM sampling defaults to 0.1, meaning roughly 10 percent of eligible page views are measured. On a low-traffic shop, that sampling rate can make RUM charts look sparse until enough visitors have been measured.The front script collects browser timings with the Performance APIs, then sends them with sendBeacon when available and falls back to XHR. The RUM controller accepts JSON POST data, validates that a URL exists, stores sanitized timing/resource fields, and returns a 204 response with no-store/noindex headers. The controller also removes Set-Cookie headers, so the beacon endpoint itself is not creating customer cookies.For cleanup, the query profiler records slow SQL by hash and updates the occurrence count and last-seen time when the same query recurs. Raw RUM data can be aggregated into hourly summaries and older raw rows are removed after aggregation, keeping long-term dashboards usable without storing every individual beacon forever. The important limitation is that current RUM aggregation stores averages and counts, not a calculated 75th percentile LCP.

How does the module handle Cloudflare edge caching?

Performance Revolution lets Cloudflare cache your full HTML pages for anonymous visitors: once a page has been filled into the edge cache, repeat hits on it can be served straight from Cloudflare. Cache misses — the first request, expired entries, and any logged-in or cart traffic — still reach your origin, so this is an edge layer in front of PHP, not a guarantee that requests never touch it. It is server-side only — no JavaScript tricks.What it actually does on each request:For an anonymous visitor on a cacheable page (home, category, product, CMS, search and similar), it sends the headers that tell Cloudflare to cache the HTML for the TTL you set.Logged-in visitors and anyone with a cart get bypass headers, so personalised pages always come fresh from your origin.It strips Set-Cookie from anonymous responses, because a CDN will refuse to cache a page that sets a cookie.It attaches Cache-Tag / Surrogate-Key headers, so when you edit a product or category it can purge just the affected pages instead of the whole site.Purging adapts to your Cloudflare plan automatically: Business and Enterprise zones purge straight by tag in one call, while free and Pro zones (which only support purge-by-URL) have the tags resolved to exact URLs and cleared in Cloudflare's 30-URL batches. There is also a zone-status check that reads your Cloudflare settings — Rocket Loader, Brotli, HTTP/3, Always Online, SSL mode, browser cache TTL — and flags anything misconfigured.Two honest limits. First, you must supply a Cloudflare zone ID and API token for API purging to work; without them the module still emits cache headers but can't actively purge. Second, edge caching is off by default and applies to anonymous traffic only — that's deliberate, so you never serve one customer's cart to another.

Can performance debugging be limited?

Yes. When you turn on the front-office profiler in MPR Performance Revolution, you decide who can see it: leave the panel off entirely, or show it but restrict it to logged-in employees so customers never see your timings.Debugging can be narrowed from the module configuration instead of enabling broad diagnostics.One of the most useful PrestaShop performance tips is to profile the live store, not a clean test copy — real traffic, real modules, real data. The profiler adds a small bar that shows each page's SQL query count and time, and lists the slowest queries and slowest module hooks, so you can see exactly where a page spends its time before you change anything.The common mistake is leaving a profiler visible to the public: it leaks internal details and adds overhead on every request. Keep it employees-only, switch it off once you've found the bottleneck, and act on what it shows — usually a heavy module hook or an unindexed query. The module also handles Redis object caching, asset deferral and OPcache/Smarty cache warming, so the fixes live in the same place as the diagnosis.The relevant settings are two switches: profiler_panel_enabled turns on the front-office panel, and profiler_employees_only keeps it behind an active back-office employee session. The employee-only setting defaults to on, while the panel itself defaults to off. When profiling starts, the module initializes instrumentation early in the request and then injects the panel before only if the collector is enabled and the employee gate passes.For deeper SQL and hook attribution, the module includes optional overrides that record every database query and per-module hook timing, and the query profiler logs slow queries over the configured threshold, which defaults to 0.1 seconds. Install those only when you need that level of visibility, because they deliberately add instrumentation overhead. A good workflow is: enable employees-only profiler, reproduce one slow URL, capture query/hook totals, disable it, then make the smallest cache, index or module change that addresses the measured bottleneck.

Which cache backends are available in configuration?

You can choose Auto-detect (recommended), Redis, APCu, or File-based caching from the Cache Backend setting.Auto-detect picks the best available option for you in the order Redis → APCu → File, so you don't have to know what your server supports — if Redis and APCu aren't there, it falls back to file caching, which always works. Pick a specific backend only when you want to force one; if it isn't available the module logs a notice and falls back to auto-detect anyway, so you never end up with caching switched off by mistake.When you select Redis, you also get the connection fields you'd expect: host, port, password, database number, and a key prefix (handy when several shops share one Redis instance). Set these to match the Redis service your host provides.This is part of Performance Revolution. If you don't run your own Redis but want it managed from the back office, see Instant Redis.

What database should I use with PrestaShop — MySQL or MariaDB?

PrestaShop uses MySQL or MariaDB as its database engine. As of the current official PrestaShop 8 and PrestaShop 9 system requirements, both list SQL support as MySQL 5.7 minimum or MariaDB 10.2 minimum, with a recent version recommended.For a new or upgraded production store, treat those as minimums, not ideal targets. MySQL 8.0 or a current MariaDB LTS release is a better choice than an old MySQL 5.7 host, especially for larger catalogues, search tables, combinations, carts and order history. Use InnoDB tables, keep enough buffer pool memory available, and make sure backups and restore tests are part of the hosting plan.PrestaShop 9 also has higher platform expectations than older installations; the official requirements recommend more PHP memory per script than PrestaShop 8. Database compatibility alone is not enough: PHP version, extensions, memory limit, filesystem permissions and module compatibility still need to be checked before upgrading.If you are on shared hosting, ask the host for the exact MySQL/MariaDB version and whether you can enable the slow query log or get slow query reports. That matters more in day-to-day PrestaShop performance than the brand name of the database server.On new hosting, ask for the exact engine and version, not just "MySQL compatible". Some managed hosts run MariaDB behind a MySQL label, and that is normally fine, but you still need a version that meets PrestaShop's requirement and a configuration that can handle your catalog. For performance, the important knobs are usually InnoDB buffer pool size, disk latency, indexes, slow query visibility and whether the database is competing with PHP on a tiny shared server.During migration, dump and restore with the correct character set, keep the same table prefix unless you are deliberately changing it, and test search, product save, order creation and back-office grids after import. Old stores can carry MyISAM tables or stale indexes from very old PrestaShop versions; converting to InnoDB and cleaning indexes should be done deliberately with a backup, not as a blind hosting-panel button.

Does cache warming run automatically by default?

No. In Performance Revolution, scheduled origin cache warming is off by default — the cache_warming_enabled flag starts as false, and the cron warmer simply reports 'disabled' and does nothing until you switch it on.So nothing runs the warmer for you out of the box. What you get is the machinery, ready to use:A cron entry that, once enabled, walks your URLs so PHP OPcache, Smarty templates and combined CSS/JS are compiled before real visitors arrive.Manual warm controls in the back office for an on-demand pass.Settings for concurrency and a maximum runtime, so a warm pass can't hammer a cold server.One default is on: cache_warming_post_deploy_enabled is true, which only allows the post-deploy CLI command to run a full warm pass after a release. It permits that command — it doesn't schedule anything by itself. Cloudflare edge warming (cdn_edge_warm_enabled) is likewise off by default.Common mistake: enabling the cron flag but never wiring an actual cron job (or the post-deploy hook) to call it. The toggle says 'allowed'; a scheduler still has to fire it.

Speed up busy PrestaShop stores with Redis, APCu or file caching and asset optimisation

Performance Revolution - PrestaShop performance Redis cache and speed optimization

Performance Revolution - Reduce the sales cost of slow pages

Performance Revolution - Act on cache problems quickly

Performance Revolution — Redis Cache & Speed for PrestaShop - Asset Deferral Settings

Performance Revolution - clear and warm PrestaShop cache in one click

Performance Revolution - optimized storefront HTML with minified and deferred assets

Speed up busy PrestaShop stores with Redis, APCu or file caching and asset optimisation

Performance Revolution

Name: Performance Revolution
Brand: mypresta.rocks
SKU: mprperformancerevolution
Price: 299.00 EUR
Availability: InStock

Performance & Cache Module - Redis, CSS/JS Minification, WebP Images, Lazy Load + CDN

No reviews

PrestaShop 1.6 – 9.0PHP 7.1+Version 1.5.8

€299.00

Tax excluded

PrestaShop performance Redis cache management helps your store make speed work visible and manageable, from cache layers to real-user measurements. Slow pages can waste paid traffic and make shoppers abandon before they reach checkout; this module gives your team practical controls for caching, warming, asset handling and bottleneck analysis in one back-office area.

Configuration supports auto-detect, Redis, APCu and file cache backends, plus TTL, Redis connection settings, reusable page-section caching, query caching and slow-query thresholds. Asset and delivery controls include minification, bundling, smart module-asset deferral, CSS combining, unused CSS removal, critical CSS, resource hints, idle JS deferral, native lazy loading and WebP or AVIF conversion flags.

The module stores real-user monitoring samples and hourly aggregates for metrics such as TTFB, FCP, LCP, CLS, FID, INP, page rendering timings, device and URL. Cache warming, Cloudflare page-cache settings, purge behavior and temporary dev-mode snapshots help performance work fit normal store maintenance.

Instant download after purchase

Instant Live Demo Real store, ready in ~1 min

5 demo installs ready · refills every 48h

Request Quote

Lifetime license per domain — yours forever. Includes 3 months support & updates. Learn more

The demo is the complete module — buy anytime and activate the same installation, nothing to reinstall and nothing lost. Open the module's License tab and click "Activate from mypresta.rocks" (or paste your key); your settings and data stay exactly as they are. Updates install in one click from the Update tab.

Support & Updates

3 months Free 6 months +€39.00 9 months +€65.00 12 months +€89.00

Auto-renew support

+€29.90/mo

Additional Services

Professional Setup We fully configure the module to your needs — all options set, tested & verified within 1 business day. +€29.00

Visual Integration CSS & template adjustments to match your theme — includes cross-device verification and screenshot review. +€49.00

Options total: €0.00

Selected total: €299.00

Multiple cache backends. Configuration supports auto-detect, Redis, APCu, and file-based caching with lifetime, Redis connection, password, and key prefix settings.
Reusable content and query caching controls. Settings cover page-section caching, query caching, cache lifetime, and a slow-query log with a configurable threshold.
Asset optimization switches. Staff can control minification, bundling, smart module-asset deferral, CSS combining, unused CSS removal, critical CSS, resource hints, and idle JS deferral.
Image delivery options. The module exposes native lazy loading plus WebP and AVIF conversion flags, including listing image type filtering controls.
Live visitor timing data. Storefront beacons record load timings, stability signals, device, URL, and shop, with hourly rollups for comparison.
Origin and edge warming. Cache warming settings control URL source, concurrency, max runtime, local resolve IP, recent-warm limits, post-deploy full warm, and Cloudflare edge warm interval.
Cloudflare page cache management. CDN settings cover page-cache enablement, lifetime, zone ID, Cloudflare connection credentials, shop URL, and auto-purge when products, categories, or CMS pages are saved.
Temporary dev mode is modeled. The config can snapshot cache settings, disable cache-related features, and store dev-mode expiry and saved settings.

PrestaShop performance Redis cache and speed optimization

PrestaShop Speed & Redis Cache - Performance helps store owners identify and reduce the speed problems that cost conversions: uncached pages, heavy assets, slow queries and poor real-user performance. Slow pages make shoppers wait, and waiting hurts revenue, ad efficiency and customer trust. This module combines cache dashboards, Redis-backed cache layers, cache clearing and warming, slow-query analysis, real-user speed measurement, asset deferral and image/content optimization settings so performance work becomes visible and manageable.

Reduce the sales cost of slow pages

Page speed affects whether visitors stay long enough to see products and complete checkout. A slow catalogue or product page can waste paid traffic because customers leave before the store has a chance to convert them. Performance Revolution gives you cache health, hit ratios and quick actions, so you can see whether performance tools are actually helping the buying journey.

Act on cache problems quickly

Cache issues often appear at the worst moment: after a campaign launch, product update or traffic spike. If the first visitor after a change pays the cost of rebuilding everything, the store feels slower exactly when customers matter most. The module lets you clear and warm caches on demand, with scheduled warming available, helping pages stay ready instead of reactive.

Find the real bottlenecks

Throwing more cache at a slow store can hide problems without solving them. Slow data lookups, heavy generated content or non-essential scripts can still hurt real customers and make technical decisions harder. Performance Revolution includes slow-query logging, summary statistics and real-user speed collection, so merchants and developers can focus on the problems that actually drag the store down.

Make pages feel usable sooner

Some scripts are useful but do not need to block the first customer interaction. If non-critical resources delay the visible page, shoppers experience the store as sluggish even when the page eventually finishes loading. The module can delay non-essential resources and streamline styling, images and generated page content under settings you control, helping the page become usable sooner.

Real-user metrics, asset deferral and cache warming

Performance Revolution centralizes performance controls in the back office: cache layers, cache browser, cache clearing and warming, slow-query analysis, real-user measurement, asset deferral and optimization settings. It is designed for practical store management rather than one-off server tweaks, and it gives visibility into what is cached and how the store performs for real visitors. Its feature set includes Redis-backed object, page and session cache, CSS and JS optimization, AVIF/WebP image generation and Core Web Vitals tracking, but results still depend on hosting, theme, modules and correct configuration.

Reference

mprperformancerevolution
In stock

2147483647 Items
PrestaShop Compatibility

PS 1.7 – 9.x
Pricing Model

One-time Purchase
Module Type

Front & Back-office
GDPR Relevant

No
Business Goal

Streamline Operations
External Account Needed

No
Module Complexity

Complete Solution
Customer Journey Stage

Manage Store
Works With Platform

No External Platform

What customers say about us

Company reviews

5.0 ★ ★ ★ ★ ★ (4 reviews)

Loading customer reviews...

No product reviews yet

Be the first to share your experience with this module.

Write a Review

Your Rating *

★ ★ ★ ★ ★

Rate specific aspects (optional)

Quality

★ ★ ★ ★ ★

Price / Quality

★ ★ ★ ★ ★

Stability

★ ★ ★ ★ ★

Compatibility

★ ★ ★ ★ ★

Support

★ ★ ★ ★ ★

Your Name *

Your Email *

Review Title

Your Review *

Add Photos (max 3)

Click to upload or drag & drop

Performance Revolution gives your PrestaShop store one control center for faster pages: cache backends, fragment caching, query caching, asset and image optimization, CDN page-cache headers, cache warming, and performance monitoring.

Read Full Documentation Download PDF

Have a question about this product? Our experts are here to help. Ask anything about installation, compatibility, or specifications.

1256 questions

9 categories

2014 building modules since

1.7–9 PrestaShop versions

See all questions

v1.5.152026-05-27

AddedFinalize performance endpoint SEO cleanup
AddedRetain generated assets across cache clears
AddedFlip CDN cache from whitelist to blacklist — cache all pages by default

Works Well With Performance Revolution

Modules our team genuinely pairs with this one — and exactly why each belongs in the same setup.

Speed up PrestaShop pages by adding lazy loading and decoding attributes to store images

Automatic SEO Images Lazy Tags

€69.00

★ ★ ★ ★ ★

Complement

Performance Revolution gives your team broad speed controls, caching, warming, asset handling and bottleneck analysis, but front-end image delivery on image-heavy pages is a specific lever that benefits from its own handling rather than general caching alone.

Automatic SEO Images Lazy Tags covers that, adding loading="lazy" and optional decoding="async" to product, listing and editable content images without theme edits. It complements the performance suite: one manages caching and back-end bottlenecks, the other defers offscreen images so the browser prioritises what shoppers see first, each in its own area.

Together you tackle speed from the server and the browser at once. Performance Revolution handles caching and asset bottlenecks while lazy loading lightens image-rich pages on the client side, so a category or product page benefits from both well-managed caching behind it and lighter image loading in front of the shopper, reducing the chance of slow pages losing traffic.

Clean old carts, logs, searches and mail records out of your PrestaShop database

Database Cleanup

€0.00

★ ★ ★ ★ ★

See details

Complement

Performance Revolution focuses on caching, warming, asset handling and bottleneck analysis, the live performance layer of your store. Over time, though, accumulated operational data such as stale carts, old logs and expired records adds weight to daily administration, which sits outside what cache tuning addresses.

Database Cleanup covers that maintenance, giving a controlled back office screen to remove stale carts, search statistics, expired specific prices, logs, connections, guest records and old mail records, with a preview before deletion. It complements the performance suite by handling data hygiene, a separate concern from runtime caching.

Used together, your store stays fast at runtime and lean in its stored data. Performance Revolution keeps pages quick to serve while Database Cleanup helps keep operational tables from bloating with records you no longer need, so administration stays manageable, with each tool responsible for a different aspect of keeping the store healthy.

Set up Redis cache in PrestaShop from the Back Office and test the connection instantly

Instant Redis

€99.00

★ ★ ★ ★ ★

Complement

Performance Revolution can use Redis among its cache layers and offers warming and bottleneck analysis, but a focused store often wants a dedicated way to verify and maintain the Redis connection itself, separate from the broader performance dashboard.

Instant Redis provides that, a back office panel to configure host, port, password, database and key prefix, test the connection through the PHP redis extension and view live metrics such as version, uptime and memory. It complements Performance Revolution by concentrating on Redis verification and cleanup as its own task.

Together you get broad performance management plus a clear, focused view of your Redis backend. Performance Revolution handles caching strategy and bottlenecks while Instant Redis makes the Redis layer easy to check and clean, so you are less likely to be caught out by a misconfigured cache backend, with each tool covering a different slice of the same speed goal.

Speed up your PrestaShop store with an audit of PHP profiling, queries, caching and Core Web Vitals

PrestaShop Speed & Core Web Vitals Audit

€490.00

★ ★ ★ ★ ★

Measurement

Performance Revolution gives you the controls to act on speed, but knowing which controls matter most for your specific store, and whether the real bottleneck is PHP, queries, assets or hosting, often needs an outside, evidence-based read.

Performance Audit supplies that, profiling your live site across PHP, slow queries, cache and CCC, Core Web Vitals, the image pipeline, theme assets, hosting and CDN, then ranking each bottleneck by its impact on load time and conversions. It complements the module by diagnosing rather than configuring.

The benefit is that your tuning is guided. You keep Performance Revolution to apply caching and asset changes while the audit tells you, in priority order, where the genuine slowdowns are on your real store, so effort goes to the bottleneck with the biggest payoff instead of being spread across every available setting.

View all known issues

14 Implemented

14 requests

Loading feature requests...

View full roadmap

30 days return right
Easy return - no questions asked

Plug & Play Modules
Install, set up and take profit

Dedicated Support First
Priority Help & Satisfaction Over Sales

Help PrestaShop shoppers find products fast with instant AJAX autocomplete search

Smart Search Revolution

€299.00

★ ★ ★ ★ ★

Browse product media with Swiper galleries, videos and a PhotoSwipe lightbox in PrestaShop

Gallery Revolution

€299.00

★ ★ ★ ★ ★

Speed up faceted search on your PrestaShop store with clean filter URLs and SEO pages

Filter Revolution

€299.00

★ ★ ★ ★ ★

Show recent views and sales signals on your PrestaShop product pages

Product Sales & Views Live Stats

€149.00

★ ★ ★ ★ ★

Cookie	Provider	Purpose	Duration
PrestaShop-*	PrestaShop	Session management and cart functionality	Session
PHPSESSID	PHP	PHP session identifier	Session
mprcr_consent	MPR Cookies Revolution	Stores cookie consent preferences	365 day(s)
mprcr_version	MPR Cookies Revolution	Tracks consent configuration version	365 day(s)

Cookie	Provider	Purpose	Duration
TawkConnectionTime	Tawk.to	Tracks chat session connection time	Session
__tawkuuid	Tawk.to	Identifies returning chat visitors across sessions	6 month(s)

Cookie	Provider	Purpose	Duration
_ga	Google Analytics	Distinguishes unique users by assigning a randomly generated number	2 year(s)
_ga_*	Google Analytics	Used to persist session state across page requests	2 year(s)
_gid	Google Analytics	Distinguishes unique users for 24 hours	24 hour(s)

Performance Revolution

Performance & Cache Module - Redis, CSS/JS Minification, WebP Images, Lazy Load + CDN

PrestaShop performance Redis cache and speed optimization

Reduce the sales cost of slow pages

Act on cache problems quickly

Find the real bottlenecks

Make pages feel usable sooner

Real-user metrics, asset deferral and cache warming

What customers say about us

Works Well With Performance Revolution

You might also like