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 Redis Cache Manager & Monitor 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.

PrestaShop cache is causing problems. Should I disable it?

Keep the cache enabled on a production store. Caching is one of the main things keeping PrestaShop fast, and switching it off permanently slows every page for every visitor without fixing the underlying fault. Disabling a cache layer is still a legitimate diagnostic step. Turn one layer off temporarily when you need to confirm whether a symptom is cache-related, typical cases: template or design changes that do not show up on the front office; stale prices, stock or blocks that survive a normal refresh; a module setting that seems to have no effect after saving. Do it in a controlled way: change one layer at a time, prefer a staging copy or a quiet moment, note what you switched, and re-enable it as soon as the test is done. If the symptom disappears with a layer off, you have found where the stale data lives. The fix is to clear or repair that layer, or to correct the module or template that caches wrongly, not to leave caching off. In most cases the problem is simply stale cache, and a proper clear resolves it. Follow the steps in How do I clear PrestaShop cache properly? before considering anything more drastic.

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.

What is the maximum number of products PrestaShop can handle?

There is no single official product limit in PrestaShop, and the platform does not stop you at any fixed catalog size. In practice, capacity is decided by your data and your infrastructure rather than by the product count alone. Combinations and data volume: a catalog with many attributes, combinations and features multiplies rows far beyond the number of products, and that volume is what the database actually has to carry. Database and search work: layered navigation, sorting and the search index grow with the catalog; slow queries and reindexing are usually the first bottleneck. Imports and exports: large feeds need scheduled, batched imports; a full-catalog import is a heavier operation than day-to-day browsing. Hosting and resources: CPU, memory, disk speed and database configuration set the ceiling; a large catalog on undersized hosting will feel slow regardless of the software. Caching, theme and modules: effective caching hides most of the catalog-size effect, while a heavy theme or a poorly written module can undo it. The honest answer for your store comes from measurement: load-test a staging copy with your real catalog and traffic pattern before committing. For concrete tuning steps, see our PrestaShop performance guide.

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 Redis Cache Manager & Monitor.

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

PrestaShop cache module, full-page and Redis caching, Cloudflare edge rules and automatic invalidation

No reviews

PrestaShop 1.7.6PHP 7.2+Version 1.5.8Released 12/24/2025Updated 05/26/2026

€299.00

Tax excluded

MPR Performance Revolution is a performance module for PrestaShop stores that measures how quickly real customers receive each page, identifies the work behind delays and makes the shop faster from one administration area. Installation applies a safe recommended profile, while every stronger option remains available for individual adjustment.

Cloudflare is an optional global page-delivery service with a free plan and paid plans. Its network places eligible public pages nearer to visitors, while the Cloudflare account shows the site zone, selected plan and network activity. The module connects that service to PrestaShop, recognises the available plan, detects conflicting rules and keeps the connection status in the store administration.

The module also prepares reusable copies of public pages on the shop server, separately for the language, currency, country and device that change what a visitor sees. Carts, checkout, customer accounts and signed-in visits always use the live shop, and a change to a product, price, stock, category, currency or tax renews the related pages automatically.

You choose excluded addresses, page-preparation schedules and each image or browser-work improvement separately. Product, category, theme and module images receive local WebP and AVIF versions, real visits reveal slow pages by device, slow database work points to its cause, and maintenance removes abandoned carts, old visit data and unused images after a clear preview.

The result is less waiting during the buying path, current and private shopping data, evidence that directs the next improvement, lighter pages and routine maintenance handled from one place.

Instant download after purchase

Instant Live Demo Real store, ready in ~1 min

Request Quote

Advanced license options require JavaScript. The standard Add to cart button will still add the selected quantity as plain, unconfigured licenses.

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

6 months +€39.00 9 months +€65.00 1 year +€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

How does one module make the whole shop faster?

MPR Performance Revolution measures speed during real customer visits, identifies the database, module and page-layout work behind delays, and applies public-page, image and browser-work improvements from one PrestaShop administration area.

Real visits: results are grouped by page, device and period, so a broad speed concern becomes a precise place to act.
Safe public pages: eligible pages are prepared on the shop server and through Cloudflare, while private shopping state remains live.
Current information: catalogue, price, stock, currency and tax changes renew only the related public pages.
Lighter delivery: storefront files, below-the-fold images and local WebP and AVIF versions reduce the work reaching the browser.
Diagnosis and maintenance: slow database operations, page-building time, old records and unused images appear as concrete tasks.
Small start, deep control: a recommended profile works after installation and every important choice remains adjustable.

real-visitor speed trends by page and device

Which pages keep real customers waiting?

The module records how long the first response takes, when the main content becomes visible, how readily the page reacts and whether its layout moves during real visits. Results stay in the shop and are arranged by page, phone, tablet or computer and selected period.

A slow product page on phones therefore appears as that exact page and device group. The current period sits beside the previous one, so the merchant sees whether a theme change, image pass or delivery setting improved later visits instead of relying on one ideal laboratory run.

Performance Revolution - Real-user metrics, asset deferral and cache warming

How do prepared public pages stay fast without sharing a cart?

Eligible public pages are prepared on the shop server before the complete storefront process begins. Separate copies preserve the right shop, language, currency, country and device where those details change the page. Carts, checkout, accounts, signed-in customers, private cookies and uncertain requests always go directly through the live shop.

Cloudflare supplies the worldwide network and offers a free plan as well as paid plans. MPR Performance Revolution recognises the selected plan, creates suitable rules, removes conflicts and keeps previously validated public pages available during a temporary server problem. You choose additional address exclusions and preparation schedules, while the built-in private-page rules always remain in force.

Changes to products, categories, content pages, manufacturers, suppliers, stock, prices, combinations, currencies and taxes renew the related public copies and leave unaffected pages ready.

The Performance Revolution configuration screen

What becomes lighter before it reaches the shopper?

Product, category, manufacturer, supplier, active-theme and installed-module images receive WebP and AVIF versions inside the shop when the server supports those formats. Originals remain available, new shop images are handled automatically and existing images are processed together without sending the catalogue to an outside image service.

You choose file reduction, grouping, delayed secondary work, removal of unused style rules and delayed image loading separately. The screen records the original and reduced size, so a merchant starts with the low-risk choices and tests more intensive options one at a time.

Back Office asset deferral settings with CSS and JavaScript optimization switches

Which slow jobs and old data need attention?

Slow database operations are recorded with duration, frequency and the part of the shop that called them. Detailed analysis identifies full-table work, ignored indexes and unnecessary sorting, while the protected page profiler attributes building time to modules and page layouts. An agency receives a cause and a location rather than a general complaint.

The maintenance view counts abandoned carts, guest sessions, connection history and old statistics before removal, then handles selected groups immediately or on a schedule. It also maintains the selected tables and identifies unreferenced images for guarded removal, with the expected record and storage reduction shown first.

How quickly does optimization start, and how deep is the control?

Installation applies a recommended profile for measurement, safe repeated work, lighter storefront files and delayed images. Public-page delivery and the strongest browser changes remain controlled choices, so the store gains useful improvements immediately without turning every switch on at once.

You choose the public addresses, excluded patterns, preparation breadth and timing, image formats, database-retention periods, slow-operation threshold and each browser-work option. A temporary maintenance mode saves the active choices, pauses them while technical work is in progress and restores the saved state afterward.

The Performance Revolution settings screen

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.

1301 questions

9 categories

2013 building modules since

1.6–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

Redis Cache Manager & Monitor

€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.

Redis Dashboard & Key Manager 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 Redis Dashboard & Key Manager 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

Send Pinterest Ads real shopping signals from your PrestaShop visits, carts and purchases

Pinterest Tag

€69.00

★ ★ ★ ★ ★

Content Variables

€49.00

★ ★ ★ ★ ★

Returns and Right of Withdrawal PrestaShop module box

Returns Manager

€149.00

★ ★ ★ ★ ★

Duplicate customer groups found by the scan, with confidence and matched signals

Customer Merge

€99.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

PrestaShop cache module, full-page and Redis caching, Cloudflare edge rules and automatic invalidation

How does one module make the whole shop faster?

Which pages keep real customers waiting?

How do prepared public pages stay fast without sharing a cart?

What becomes lighter before it reaches the shopper?

Which slow jobs and old data need attention?

How quickly does optimization start, and how deep is the control?

What customers say about us

Works Well With Performance Revolution

You might also like