Why Your PrestaShop Store Is Slow and How to Fix It

Before touching anything, you need to know where the time is lost. A page can be slow because the server takes a long time to generate the HTML, because the browser downloads too many resources, or both. These two problems have different causes and different solutions, and confusing them wastes days.

First measure the server response time (TTFB) on the home page, a category page and a product page, both logged in and logged out. Then measure the full browser load with PageSpeed Insights or WebPageTest. A high TTFB points to PHP, the database or modules; a low TTFB with a long load points to the theme, images and scripts.

Temporarily enable PrestaShop's built-in profiler on a test environment: it details the time spent in each hook, each module and each SQL query, and often points straight at the culprit without any guesswork.

PrestaShop is a demanding application. Entry-level shared hosting, sized for a brochure site, cannot keep up once the catalogue and traffic grow. The classic symptoms are a TTFB that degrades at peak hours and erratic response times from one request to the next.

The PHP version has a direct impact: each major branch brings performance gains, and end-of-life versions no longer receive fixes. Check that the OPcache extension is enabled and correctly sized, otherwise PHP recompiles your scripts on every request, wasting CPU.

On the database side, MySQL or MariaDB must have an InnoDB buffer pool large enough to hold the most frequently read tables. On a badly tuned server, every product page triggers avoidable disk reads, and latency piles up with every query.

PrestaShop has several cache layers that must be enabled in production. In the performance settings, the Smarty cache must be on and template recompilation off, using the "Never recompile template files" option. On a store still in development, these settings are often left permissive and then forgotten.

The CCC option (combine, compress and cache) reduces the number of CSS and JavaScript files. The application cache can be handed to Memcached or Redis to avoid hitting the database for rarely changed data. Finally, check that debug mode is disabled in production.

An upstream HTTP cache, through a reverse proxy such as Varnish or a CDN, serves non-personalised pages without even calling PHP. It requires careful configuration to respect the cart and user session, but the effect on response time is spectacular.

Every installed module runs on its hooks at every page load. A badly written search, statistics or recommendation module can add several hundred milliseconds, or even several seconds, to every page. The native statistics modules, which write to the database on every visit, are frequently to blame.

Inventory the modules, uninstall those that serve no purpose, because deactivating is not always enough, and measure the impact of each one with the profiler. Third-party modules that load external scripts, such as chat, customer reviews or ad tracking, also weigh on the browser side.

Beware of purchased themes shipped with dozens of preinstalled modules. A premium theme can bundle sliders, galleries and effects that slow the store down even though you never use them. Every unnecessary module is wasted computing time on every page.

Some PrestaShop tables grow without limit if they are not cleaned: connections, connection sources, guest visitors, abandoned carts, logs. With millions of rows, the queries that read them slow down the whole site, including the back office.

Set up periodic cleaning of these tables and check for slow queries with MySQL's slow query log. Missing indexes on columns used in faceted navigation filters or searches are a frequent cause of slowness on large catalogues.

On large catalogues, regenerating the search index and product combinations must be scheduled outside traffic hours. Also check that scheduled tasks (cron) are actually run by the system and not triggered by customer visits.

A category page displays dozens of images. If they are delivered at full resolution, uncompressed and in an old format, the page weighs several megabytes. Generate modern formats (WebP, AVIF) and serve the right size for each slot, with lazy loading for off-screen images.

The theme must load only what is strictly necessary: a limited set of fonts, minified CSS and JavaScript, third-party scripts loaded asynchronously or deferred. A CDN brings static files closer to your customers and absorbs part of the load, especially during sales campaigns.

These optimisations directly improve Core Web Vitals, which Google takes into account, and conversion: a customer waiting on a slow product page abandons the cart. Performance is a commercial topic as much as a technical one.

The most effective order is almost always the same: measure, fix hosting and PHP if needed, enable the caches, audit the modules, clean the database, then optimise the theme and images. Each step must be measured to verify its real effect.

If the store runs on an old PrestaShop version, upgrading to PrestaShop 8 or 9 brings performance and security gains, but it must be prepared: compatibility of modules, theme and customisations, and full testing on a staging environment.