Slow PrestaShop store: find the cause and speed up the front and back office
A slow PrestaShop store directly hurts revenue: product pages that take a long time to display, a cart that is slow to update, an abandoned checkout. On the back office side, a heavy catalogue makes managing products, orders and stock painful for your teams.
PrestaShop is more demanding than the average CMS: every front page combines dozens of module hooks, SQL queries on the product, combination, specific price and stock tables, and Smarty rendering. An undersized server, badly written modules, disabled caching or an unmaintained database quickly show.
This page describes the most frequent causes of slowness on PrestaShop 1.6, 1.7 and 8, the checks you can run in the back office and on the server, and the fixes to apply, from cache settings to database optimisation.
Typical symptoms
- Category pages and product pages take several seconds to display, especially with faceted filters.
- Adding to cart, updating quantities or moving to the shipping step is slow.
- The back office is slow to open the product or order list or to save a product sheet.
- Slowness gets worse with the number of products, combinations or price rules.
- The server shows high CPU or MySQL load as soon as there is some traffic.
- Response times measured by PageSpeed Insights or WebPageTest are high from the first byte (TTFB).
Possible causes
Slow or too many modules
Every module hooked on the page runs code and queries. Faceted navigation, statistics, product block modules (new products, best sellers) and some third-party modules are the most expensive.
Misconfigured Smarty and application cache
Smarty compilation forced on every call, caching disabled, or performance features (CCC, file combination and compression) not enabled multiply the work on every page.
Large, unmaintained database
ps_connections, ps_connections_source, ps_guest, ps_cart, ps_log and ps_statssearch tables growing without purge, missing indexes on large product tables, tables never optimised.
Complex catalogue
Thousands of combinations, specific prices per group and country, numerous cart rules and abundant features multiply the SQL queries needed to compute a price or a stock level.
Unoptimised images
Product images in very high resolution, no WebP, missing thumbnail regeneration or too many generated image formats.
Unsuitable server or PHP version
Shared hosting, unsupported PHP, no OPcache, MySQL with default settings (innodb_buffer_pool_size too low) and no in-memory cache.
Blocking external calls
Modules that query third-party services (carriers, marketplaces, customer reviews, ERP) synchronously on every page display.
Checks to perform
- 1
Enable PrestaShop profiling
In config/defines.inc.php, set _PS_DEBUG_PROFILING_ to true on a copy or outside traffic hours: a report at the bottom of the page details time per hook, per module and per SQL query, as well as memory used.
- 2
Check the performance settings
Advanced Parameters > Performance: Smarty cache set to "Never recompile template files", cache enabled, CCC enabled, debug mode disabled in production.
- 3
Measure the database size
In phpMyAdmin, sort tables by size. ps_connections, ps_guest or ps_log tables of several hundred megabytes are a clear sign that a clean-up is needed.
- 4
Enable the MySQL slow query log
With slow_query_log enabled and long_query_time set low, the log file lists the longest queries; EXPLAIN on those queries reveals missing indexes.
- 5
Disable non-essential modules
On a test copy, disable modules one by one while watching the profiling to identify those that cost the most.
- 6
Check the server
top or htop for load, free -m for memory, df -h for disk space, and the PHP version with php -v. Verify that OPcache is enabled via a temporary phpinfo() file.
- 7
Test with and without cache
Compare the response time of the same page cold and then warm in the browser Network tab. If the time stays the same, caching is not working.
Solutions
Configure the caches properly
Smarty recompilation disabled, application cache enabled, OPcache configured with enough memory, and an in-memory cache (Redis, Memcached) for high-traffic stores.
Clean and index the database
Regular purge of connection, guest, old abandoned cart and log tables, indexes added for the slow queries identified, OPTIMIZE TABLE, and InnoDB tuning.
Rationalise modules
Remove unused modules (not just disable them), replace heavy ones, disable native statistics modules if an external tool is used.
Optimise images
Compression and WebP, thumbnail regeneration in the right formats, removal of unused formats and lazy loading.
Make external calls asynchronous
ERP synchronisations, customer reviews and marketplace feeds moved to cron jobs rather than executed on every page view.
Upgrade the infrastructure
Supported PHP, tuned MySQL or MariaDB (innodb_buffer_pool_size sized to the data), Nginx with PHP-FPM, CDN for static files, and migration to a properly sized server if necessary.
When should you call a professional?
- Profiling shows slow SQL queries coming from the core or from modules you cannot modify.
- Slowness affects the checkout and translates into measurable cart abandonment.
- Your catalogue has thousands of references or combinations and standard optimisations are no longer enough.
- You have no test environment or server access to make the changes safely.
- You are preparing for a traffic peak (campaign, sales, marketplace) and want to secure the store beforehand.
How Agencei can help
- 1
Performance audit
PrestaShop profiling, slow query log, analysis of modules and server configuration, external measurements.
- 2
Application optimisation
Cache tuning, module triage and replacement, targeted fixes in overrides and custom modules, external calls made asynchronous.
- 3
Database optimisation
Clean-up, indexes, InnoDB tuning, automated purges.
- 4
Server optimisation
PHP-FPM, OPcache, Nginx, Redis, CDN, sizing and, if needed, migration to suitable hosting.
- 5
Measurements and report
Before and after comparison on key pages (home, category, product, cart, checkout) and recommendations for the next steps.
- 6
Maintenance
Regular follow-up with tested updates, monitoring and periodic clean-up to keep the gains.
Frequently asked questions
Why is the back office so slow while the front is fine?
The front benefits from caching, the back office does not. Product and order lists run heavy queries on large tables; modules loaded on every admin page and an uncleaned database make it worse.
Is a caching module enough?
It helps for static pages but not for the cart, customer account or checkout, which are dynamic. The database, modules and server must be optimised too.
Do I need to upgrade PrestaShop to gain performance?
Recent versions bring improvements, but migration is a project in its own right. A well-optimised 1.6 or 1.7 store can be fast; upgrading is decided on other criteria (security, module compatibility, features).
How long does an optimisation take?
The diagnosis often takes a few hours. Fixes range from a few hours for caches and database to several days if modules must be replaced or the server migrated.
Is cleaning the database risky?
Not if it is done with a prior backup and targets the technical tables (connections, guests, logs, old carts). Order and customer data are never affected.
Related services
Performance Optimization
Profiling-based diagnosis and targeted fixes: Core Web Vitals, SQL queries, caching, CDN.
See this servicePrestaShop Maintenance
Tested updates, backups, monitoring and security for a PrestaShop store that stays open.
See this servicePrestaShop Agency
Custom PrestaShop modules and themes, takeover of 1.6, 1.7 and 8 stores, performance and integrations.
See this serviceTechnical Audit
Independent review of code, architecture and infrastructure, with a prioritised report.
See this serviceTell us about your project
Describe your need in a few lines: we come back to you with a first analysis and the next steps.