# Your PrestaShop shop takes too long to load

> A slow shop isn't fixed by switching hosting at random. Slowness almost always comes from a specific point: unindexed SQL queries, a misconfigured Smarty cache, or a module running unnecessary code on every page.

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

## Direct answer

> Start with Advanced Parameters > Performance: template cache set to never recompile, debug mode off, CSS and JS combination on. Then check on the server that OPcache is running and which PHP version is in use. If nothing improves, the bottleneck is in the database: pull the MySQL slow query log and look for missing indexes on ps_product and ps_category_product.

## How I measure before stepping in

1. **Profiling the page** — I enable the performance debugger to list the SQL queries run on a given page, their number and execution time. A product page triggering over 200 queries isn't normal.
2. **Checking the cache** — I check the state of the Smarty cache (compile and render cache) and, on PrestaShop 1.6, whether CSS/JS combine and compression (CCC) is enabled.
3. **Analysing MySQL indexes** — I look at slow queries on the database side and add missing indexes on the most heavily used tables, typically ps_product, ps_product_attribute and ps_category_product.
4. **Auditing modules** — I spot modules attached to hooks that run on every page (displayHeader, actionFrontControllerSetMedia) and that make unnecessary external calls or queries.
5. **Checking the server** — I check whether OPcache is enabled, the PHP version in use, and whether an in-memory cache (Redis or Memcached) is available to replace the default file cache.

## Slow PrestaShop site: server or browser?

Before fixing anything, you need to know whether the time is lost on the server or in the browser. Open the browser’s developer tools, Network tab, and look at the first line: how long the server takes to respond, the TTFB.

High TTFB, above roughly one second: the server is slow to build the page. The cause lies in PHP, the database or a module, which is what this page covers.

Good TTFB but the page is slow to appear: the server answers quickly, then the browser struggles. Heavy images, third-party scripts (chat, reviews, ad tracking), fonts and JavaScript that are not deferred: this is front-end work, not server work.

Only the back office is slow: look at order, product or customer lists on large volumes, dashboard modules, and the size of statistics tables such as ps_connections, ps_guest or ps_pagenotfound, which grow without limit when nothing purges them.

## Forgotten settings that slow the whole shop down

A surprising share of the slow shops I see have no code problem at all: a troubleshooting setting was simply left on.

_PS_MODE_DEV_ left at true in config/defines.inc.php after an intervention. On 1.7, 8 and 9 it also runs the back office in Symfony’s development environment, which is noticeably slower.

_PS_DEBUG_PROFILING_ enabled: every page computes and displays its own profile, which costs time on every view.

Under Advanced Parameters > Performance, template compilation set to “Force compilation”: Smarty recompiles templates on every view instead of reusing them.

Caching switched off on that same screen, sometimes to “see a change”, and never switched back on.

These four points take minutes to check and need no development. They come before any conclusion about the hosting.

## Signs that justify an audit

- A product or category page taking more than 3 seconds to display
- Back office getting slow once the catalogue passes a few thousand references
- Gradual slowdown over the months with no obvious change
- Slowness spikes only during high-traffic periods
- Poor PageSpeed or Core Web Vitals score despite decent hosting

## What I fix most often

PrestaShop's default file cache (var/cache) holds up well on a catalogue of a few hundred products, but becomes a bottleneck on a large catalogue with a lot of simultaneous traffic, because every cache write locks the disk. Switching to an in-memory cache often changes things significantly without touching the code.

On the database side, missing indexes on columns used in joins (id_product, id_shop, id_lang) makes response times explode as the catalogue grows, even though the same page stays fast in a test environment with little data.

Finally, some recommendation, marketing tracking or PDF generation modules run heavy code on every page load, even when the feature isn't being used at that moment. I identify these through the hook debugger and suggest either conditional disabling or moving them to an asynchronous task.

## Switching hosting isn't always enough

> A more powerful server masks a badly indexed query problem for a while, but the slowdown returns as soon as the catalogue or traffic grows. I prefer fixing the cause before recommending a server upgrade.

## Related pages

- **Diagnosing a slow shop** — The step-by-step measuring method, before touching anything. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Modules that slow the shop down** — Spotting modules that run on every page for no reason. ([/modules/modules-qui-ralentissent-la-boutique](/modules/modules-qui-ralentissent-la-boutique))
- **Performance of a large PrestaShop catalogue** — What changes beyond several tens of thousands of products. ([/expertises/performance-catalogue-volumineux-prestashop](/expertises/performance-catalogue-volumineux-prestashop))
- **Site slow overnight** — When the slowdown has a precise date, so does its cause. ([/problemes/site-lent-depuis-hier](/problemes/site-lent-depuis-hier))
- **Category filters gone** — Faceted search and its index, often behind slow category pages. ([/prestashop/problemes/filtres-page-categorie-disparus](/prestashop/problemes/filtres-page-categorie-disparus))
- **Rebuild the site because it is slow?** — Rarely the right answer: what a rebuild fixes, and what it reproduces. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Do I need to switch hosts to fix the slowness?

Not necessarily. I start by measuring where the time is actually lost: often the cause is in the code or database, not the server's power.

### Will the performance audit slow down or risk the live shop?

No, profiling doesn't interrupt the site. Fixes are tested before being applied to production, and I can work outside peak traffic hours if needed.

### What access do I need to give you?

FTP or SSH access, database access, and if possible access to the hosting admin area to check the PHP configuration and available cache.

### How long does a performance audit take?

Diagnosis usually takes half a day to a day. Fixes then vary depending on their nature: adding an index takes minutes, rebuilding a badly optimised module takes longer.

### Will this improve my SEO?

Loading speed is one of the criteria Google considers (Core Web Vitals), so yes, indirectly, but it's not a guarantee of a better ranking on its own.

### Why did my PrestaShop site suddenly become slow?

A sudden slowdown almost always has a dated cause: debug mode left on after an intervention, a module installed or updated, the PHP version changed by the host, a statistics table crossing a threshold, or a wave of bots. Match the date of the slowdown against recent changes and the access logs before touching the server.