A slow store loses sales at every step: a category page that takes its time, a product page that loads in pieces, a cart that needs several seconds to update. To speed up a PrestaShop store, installing yet another “performance” module is not enough: you first need to find out what is really slowing it down. Here are the levers I check, starting with those that pay off the most.
Speeding up PrestaShop starts with measuring
Before changing anything, measure server response time and Core Web Vitals on four types of pages: home, category, product and cart. In a staging environment, PrestaShop’s profiling mode (the _PS_DEBUG_PROFILING_ constant) shows the time spent in each module, each hook and each SQL query: it is the most valuable tool for finding the culprit.
Cache and performance settings
Under Advanced Parameters > Performance, several options make a big difference:
- Debug mode must be off in production: it slows the store down considerably and can expose sensitive information.
- Template compilation should be set to “Never recompile template files”, with the Smarty cache enabled.
- Combining and compressing CSS and JavaScript files (CCC) reduces the number of files loaded; test the result, as some modules do not cope well with merged files.
- On the server side, PHP’s OPcache and an object cache (Redis or Memcached, if your hosting allows it) lighten every request.
Clean up your modules
Every module hooked into display hooks adds code, SQL queries and often CSS and JavaScript files to every page. On the stores I audit, modules are the leading cause of slowness.
- Uninstall, not just disable, unused modules, including native modules you do not need.
- Use profiling to identify the most expensive modules and look for a lighter alternative.
- Be wary of modules that call an external service every time a page is displayed.
- Check the faceted search configuration (cache enabled, index up to date), often behind slow category pages on large catalogues.
Optimise images
Product photos account for most of a page’s weight. Make sure the image types declared in the back office image settings match the sizes your theme actually displays, delete the ones you do not use and regenerate the thumbnails. Recent versions of PrestaShop can generate WebP and even AVIF images; otherwise, a module or server-side conversion can handle it. Finally, enable lazy loading for images below the fold.
Hosting and PHP version
No setting can make up for an undersized server. A PrestaShop store needs a supported PHP version compatible with its branch, enough memory, SSD or NVMe storage and a properly configured MySQL or MariaDB database. Entry-level shared hosting is rarely enough beyond a small catalogue. If your customers are in several countries, for example in France and Algeria, choose a server close to most of them and consider a CDN for static files.
Clean up the database
Some tables grow endlessly: connection and visitor statistics (ps_connections, ps_guest), pages not found, logs, old abandoned carts. Tables with millions of rows slow down backups, the back office and sometimes the store itself. After a full backup, purge old data that has no value and disable statistics modules you never look at. Never delete carts linked to orders.
What about full-page caching?
Full-page caching, through a dedicated module or a reverse proxy such as Varnish, can transform performance. But it must correctly handle the cart, logged-in customers, specific prices and currencies: badly configured, it can show one customer another customer’s information. It is the last step, once the other levers have been dealt with, and it is always tested in staging.
Want to know what is slowing your store down? The express audit (€290 excl. VAT, 30,000 DZD in Algeria) reviews performance, security and versions and gives you 10 priority actions. For an in-depth diagnosis with a costed action plan, the full technical audit costs €690 excl. VAT (70,000 DZD).