Luca Cavallini

Performance

How to speed up PrestaShop: a practitioner’s checklist

A field-tested checklist for making PrestaShop fast — including on catalogues with hundreds of thousands of products. In rough order of impact, from the changes that move the needle most.

Performance work pays back twice: better conversion and better ranking. But most “speed up PrestaShop” advice is a pile of tips with no priority. Here’s what actually matters, in the order I’d tackle it.

1. Measure first — always

Before changing anything, get a baseline: a Lighthouse run, real page-load timing, and the slow-query log enabled. You can’t improve what you don’t measure, and you’ll want before/after proof. Optimizing by feel is how people spend a week speeding up the wrong thing.

2. Fix the database

On large catalogues, the database is usually the real bottleneck. Enable the slow-query log, find the worst offenders, and look for missing indexes and N+1 patterns (often introduced by modules). Tune MySQL/MariaDB buffers for your dataset. This is where the biggest wins hide on big shops.

3. Turn on real caching

  • OPcache — non-negotiable; make sure it’s on and sized properly.
  • PrestaShop cache — enable it and use a real backend (Redis) rather than filesystem on busy shops.
  • Full-page caching for anonymous traffic, with invalidation you trust.

4. Audit your modules

The single most common cause of a slow PrestaShop is module bloat: too many modules, each adding queries and assets to every page. Disable what you don’t use, and find the few that are quietly doing the most damage. Overrides are part of this too — they’re a frequent source of conflicts and slowdowns.

5. Optimize the front-end

  • Bundle and minify CSS/JS; remove render-blocking resources.
  • Serve images in modern formats, correctly sized, with lazy-loading.
  • Mind Core Web Vitals (LCP, CLS) — they affect both users and ranking.

6. Tune the server

PHP-FPM worker counts, the web server (Apache/Nginx), HTTP/2, compression and TLS all matter. The fastest application still feels slow on a misconfigured server — and most performance problems live exactly on the boundary between code and server.

The honest summary

On a big shop, the order is almost always: database → caching → modules → front-end → server. Measure, fix the biggest thing, measure again. If you’d rather hand it over, performance optimization on large PrestaShop catalogues is one of the things I do most.

What’s the single biggest win for a slow PrestaShop?
On a large catalogue, almost always the database: missing indexes and N+1 queries, often introduced by modules. On a small shop, it’s usually caching (OPcache + a real cache backend) and module bloat.
Will a caching module fix everything?
No. Caching hides a slow shop for anonymous visitors but does nothing for logged-in users, the cart or the checkout — and it can mask a database problem instead of fixing it.
Can hundreds of thousands of products ever be fast?
Yes, with the right indexing and caching strategy. I run shops with over a million products kept fast under real load — it’s an engineering problem, not a limit of PrestaShop.

Tell me what’s not working — or not talking to what.

New build, a system that needs rescuing, an integration, the June 2026 deadline. One developer who builds it and stays to run it. Reply usually within 1–2 business days.