# Modules that slow the store down

> «I have too many modules» is a common and rarely accurate diagnosis. A store can run many and stay fast, or run only a few and crawl. What weighs isn’t the count: it is what each one executes on every page view.

- Source canonique : [https://allaux.fr/en/modules/modules-qui-ralentissent-la-boutique](https://allaux.fr/en/modules/modules-qui-ralentissent-la-boutique)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> On a copy of the site, set _PS_DEBUG_PROFILING_ to true in config/defines.inc.php: PrestaShop then prints, at the foot of every page, the time spent in each hook and the SQL query count, module by module. The culprit is nearly always hooked to actionFrontControllerSetMedia or to product display, not the sheer number of modules.

## The three ways a module costs time

Database queries. A module hooked into product display that queries the database once per product turns a category page into dozens of extra queries. That design mistake, a query inside a loop, is invisible on a demo store and shows up as soon as the catalogue grows.

Assets loaded into the page. Every module that adds its stylesheet and its script weighs down all pages, including those where it is useless. A comparison module loading its assets on the payment page is the typical example.

Outbound calls during rendering. This is the most expensive and the most insidious: a module that queries a third-party service while building the page makes the visitor wait as long as that service takes to answer. The day the service is slow, your store is slow, with nothing having changed on your side.

## How I attribute lost time to a specific module

1. **Turn on the platform’s profiling** — PrestaShop has a debug mode that shows, per page, the number of SQL queries, their duration and the time spent in each hook point. It is the most direct measurement, and it names the module.
2. **Look at slow queries on the server** — The database’s slow query log surfaces expensive queries with their text. The module producing them is recognised immediately from its table names.
3. **Separate server time from browser time** — A page that is slow to display isn’t always slow to generate. The browser’s network tab separates the wait for the first response from asset loading time.
4. **Disable and re-measure, on a copy** — Before-and-after measurement is the only proof. I do it on a copy of the site, never in production, on the same pages with the same cache state.

## A slow admin and a slow storefront have different causes

> A slow admin usually comes from unindexed queries on tables that have grown large, or from a module recomputing statistics on every load. The storefront mainly suffers from the number of assets loaded and from outbound calls. Fixing one doesn’t fix the other, and you need to know which of the two actually bothers you before committing work.

## What I do once the module is identified

Rarely a plain uninstall: the module provides a service, and removing it moves the problem into daily operations. Three fixes give measurable results. Restrict asset loading to the pages where the module is genuinely used, which is handled in its code without touching its function. Cache the result of outbound calls, so the third-party service is queried periodically rather than on every visit. Replace a query inside a loop with a single query, which is the most profitable fix when the catalogue is large.

When none of those three is possible because the module is encoded or locked by its licence, the question becomes a choice: replace the module, or accept its cost. I say so plainly rather than billing for an optimisation that cannot succeed.

## Related pages

- **Diagnosing a slow store** — The full method, beyond modules alone. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Slow PrestaShop store** — The causes specific to PrestaShop, including cache and SQL queries. ([/prestashop/boutique-lente](/prestashop/boutique-lente))
- **Very slow WordPress admin** — The specific case of the back office, often confused with a slow site. ([/wordpress-woocommerce/problemes/admin-wordpress-tres-lent](/wordpress-woocommerce/problemes/admin-wordpress-tres-lent))
- **Auditing a store’s module estate** — The inventory that precedes any removal or replacement decision. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### How many modules is too many?

There is no number. A store can have many and stay fast if each one is confined to the pages where it is used. The right indicator is page generation time, not the length of the list.

### Is disabling a module enough to recover performance?

Often yes for generation time, but not always: a disabled module can leave large tables and active scheduled jobs behind. Full uninstallation is different from mere deactivation.

### Can a caching module compensate for a slow module?

It hides the problem on cached pages and leaves it intact elsewhere: cart, customer account, checkout, admin. Those are precisely the pages where slowness costs most.

### How do I know whether the slowness comes from a module or from hosting?

By comparing page generation time with network waiting time. If the page is generated quickly but arrives slowly, the lead is hosting or the network; if it takes time to generate, the lead is executed code, so modules.