What actually makes PrestaShop slow: database, modules and hosting

PrestaShop is not slow by nature. A clean 1.7, 8.x or 9.x install with a sensible catalogue and a disciplined module list answers in well under a second. So when a store crawls, "PrestaShop is heavy" is almost never the real diagnosis. Something specific is making this store slow, and it lives in one of three places: the database, the modules, or the hosting. The trap most merchants fall into is treating all three at once, buy Redis, switch host, and disable half their modules in a panic. Without ever finding out which one was actually costing them the seconds. This guide is about attribution: how to look at a slow PrestaShop store and tell which layer is the culprit, so you spend your effort where the time is genuinely being lost.

The fixes themselves each have their own home in this cluster. We link to them as we go. What you'll get here is the part nobody writes down: how to tell, on your own store, which of the three is the one dragging you down.

Reviewed June 2026 for PrestaShop 1.7, 8.x and 9.x. One honest framing note for newer versions: PHP 8's JIT and OPcache are where most of the "newer PrestaShop feels faster" gain comes from, and PS9's move to Symfony 6.4 trims the container compile, but those lift the hosting/PHP layer, not a bloated database or a module looping queries. Upgrading the platform never substitutes for attributing the real cause below.

Why "it's slow" is three completely different problems

Slowness is a symptom, and the same symptom has three unrelated causes that you fix in three unrelated ways. Treating the wrong one is wasted money. Here is how each layer fails, what it feels like, and where the time actually goes:

So what? If your problem is the database, a faster server barely moves the needle. You'll just run the same slow queries on slightly faster metal. If your problem is hosting contention, cleaning the database won't save you from the neighbour running a backup at 5pm. Matching the fix to the cause is the entire game.

Step one: split the timeline into "server" and "browser"

Before you can blame a layer, you have to know whether the time is being lost on the server (PrestaShop building the page) or in the browser (downloading and rendering it). That single split sends you down two different roads.

The number that separates them is TTFB, Time to First Byte: how long the server takes to start answering. On a healthy PrestaShop store, TTFB sits under ~300ms; over a second means the server side is in trouble. Everything after the first byte (images, CSS, JavaScript, fonts) is the browser/front-end story.

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://www.example.com/category-url

• High TTFB, fast render once it arrives → the cause is server-side: database or hosting (read on to tell those two apart).
• Low TTFB, but the page still feels slow to appear → the cause is front-end: usually modules piling on requests, plus images and assets.

We won't re-teach the measurement mechanics here, testing TTFB across page types, reading Core Web Vitals (LCP, INP, CLS), and what a "good" number looks like are covered properly in is your store slow? how to check and what to do about it. Run that first; come back with a TTFB number and which page type is worst. The rest of this guide reads those two facts.

Is it the database? The most common, and most hidden, cause

In our experience running and fixing PrestaShop stores, the database is the single most common source of server-side slowness, and the most under-suspected, because it leaves no obvious trace in the browser. The give-aways:

• TTFB rises as the store ages. It was fine at launch and got worse with no obvious change. That's table bloat: ps_connections, ps_connections_source, ps_guest, ps_statssearch, ps_pagenotfound and ps_log grow forever and are queried for statistics. Old abandoned rows in ps_cart never leave on their own.
• The back office is slow too, not just the storefront. A pure hosting or front-end problem usually spares the admin; a database problem hits both because both run the same queries against the same fat tables.
• The same table shows up again and again in the slow query log (set long_query_time low and watch). Repeat offenders without an index on the columns used in WHERE/JOIN are your smoking gun. A query that's instant at 1,000 rows is painful at 1,000,000.

The fix splits cleanly. Trimming the bloat is the easy, high-return half, and it's a whole topic on its own: see database cleanup: why your store gets slower over time for what's safe to delete and what isn't. The deeper half, query-level tuning, indexes, and pairing cleanup with caching, is in performance tuning your store: from database queries to full page cache.

If you'd rather not run delete statements by hand or set up the cron yourself, our Database Cleanup module does the safe-by-default version from the back office, expired carts, old search stats, guest and connection records, obsolete logs, on a schedule, so the tables never get the chance to bloat again. So what? The TTFB that was creeping up every month stops creeping, without you touching SQL or remembering to do it.

The configuration tab shows the cleanup workspace enabled and the module marked installed and ready.

SELECT table_name, table_rows, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name IN ('ps_connections', 'ps_connections_page', 'ps_guest', 'ps_cart', 'ps_log', 'ps_search_index')
ORDER BY (data_length + index_length) DESC;

Is it the modules? Death by a thousand hooks

The difference between a fast PrestaShop store and a slow one is, more often than any other single factor, the modules. Specifically how many of them run on every page and what they do while they're there. The tells here are different from the database's:

• One page type is dramatically slower than the others. Product pages crawl while the homepage is fine, say. That points at a module hooked into that page (a real-time stock checker, a cross-sell that computes relationships, a reviews widget) rather than a flat server problem.
• Lots of front-end requests and heavy JavaScript in the network panel, often from third-party domains. That's the front-end signature of module sprawl.
• It got slower right after you installed something. The cleanest test in this whole guide: disable a suspect module, re-measure, re-enable. Enable the Profiler (set _PS_DEBUG_PROFILING_ to true in config/defines.inc.php on a staging copy), then read its output to inspect hook execution time and SQL query counts per module, that's how you catch the one adding 200ms on every load. The Advanced Parameters → Performance page itself is for cache and debug-related settings, not profiling results.

What to watch for specifically:

• Too many hooks. Every module on displayHeader, displayTop, displayFooter or actionFrontControllerSetMedia runs on every single page. Thirty modules there is thirty functions before a single pixel renders.
• External API calls on page load. A carrier rate fetched live, a currency rate pulled on every view, a social feed phoned home in real time. Each adds 200–500ms of network latency, and if that service is down, your page waits with it. The fix is always the same: cache the result locally and refresh it on a cron, never on the visitor's request.
• Redundant modules. Two SEO modules, three analytics trackers, a pair of cookie banners, each one taxes every page. One well-chosen module beats three fighting over the same job; audit and remove the duplicates.

For a worked example of how far this can go in the right direction, a real PrestaShop 9 store carrying 130-plus modules and still scoring 99/100, see PageSpeed 99/100 on a real store with 130+ modules. The lesson there is the encouraging one: module count isn't the enemy, module discipline is.

Is it the hosting? The flat tax you can't cache away

Hosting is the layer merchants blame first and diagnose last, usually because the fix costs money. The honest tells that it's genuinely your problem and not a scapegoat:

• Performance is inconsistent by time of day. Fast at 3am, sluggish at 6pm with no traffic change of your own. That's classic shared-hosting CPU/RAM contention, your neighbours' load leaking into your store.
• TTFB is high even on a clean, cache-warm page with the database already trimmed. If you've ruled out the other two and the server is still slow to respond, the metal underneath is the constraint.
• OPcache is off. This is the highest-impact single hosting setting for PrestaShop. It keeps compiled PHP bytecode in memory so files aren't re-parsed every request, and it's worth a large chunk of your TTFB. Confirm opcache.enable=1, with opcache.memory_consumption=256 and opcache.max_accelerated_files=20000. Set opcache.validate_timestamps=0 only if your deployments reliably reset PHP-FPM/OPcache afterwards. Otherwise keep timestamp validation with a sensible opcache.revalidate_freq, or you'll serve stale PHP after a module, core or theme update.

A serious PrestaShop store wants, at minimum, a VPS or dedicated server (not crowded shared hosting), SSD storage, PHP 8.1+ with OPcache, and MySQL 8.0 / MariaDB 10.6+ with innodb_buffer_pool_size tuned to your RAM. But "buy a bigger server" is the lazy version of this advice, and a lot of what hosts sell is marketing. Which specs actually move PrestaShop's needle, and which are upsell, is its own decision, laid out in choosing hosting for PrestaShop: what matters and what is marketing. Resize the server after you've cleared the other two layers, not before, or you'll pay monthly to run the same slow queries faster.

Where caching fits, and where it doesn't

Caching is the reflex answer to slowness, and it's a good answer for the right cause, but it masks problems as often as it solves them, so it belongs at the end of this guide, not the start. A cache hides a slow database from anonymous visitors; it does nothing for the logged-in customer, the checkout, or the back office, all of which still hit the real query.

Two kinds matter, and they map to two of the layers above:

• Object cache (Redis / Memcached) attacks the database layer, where core and modules use PrestaShop's cache APIs, it can speed up repeated cacheable lookups and cut filesystem-cache overhead. It isn't a blanket SQL query cache, though: it caches only values explicitly stored through those APIs, so plenty of queries still hit MySQL. This is the highest-impact change you can make if your diagnosis above pointed at the database. The setup and the realistic gains are in Redis cache for PrestaShop: setup and performance gains, with the why-it-helps reasoning in Redis: the speed upgrade your store probably needs. Our Redis Cache Manager & Monitor module configures and monitors the required Redis settings from the back office if you'd rather not edit the configuration by hand.
• Full page cache serves a pre-built HTML page to anonymous visitors so PrestaShop builds nothing at all. The biggest single win for storefront TTFB on cache-eligible traffic. It's not in core; the module options, and their honest trade-offs around cache invalidation, are compared in PrestaShop cache: full page cache modules explained.

And the built-ins you should already have on regardless: Smarty cache enabled with Force compilation: No, and CCC (Combine, Compress, Cache) for CSS/JS, both under Advanced Parameters → Performance. They're free, they ship with the platform, and a surprising number of stores leave them off.

If you'd rather not assemble Redis, fragment caching, asset optimization and monitoring piece by piece, our MPR Performance Revolution module bundles them behind one back-office panel. So what does that buy you? The high-impact caching layers go on together, with monitoring to confirm they're actually hitting, so you're not guessing whether the cache is warm.

The diagnosis-first checklist

Put together, the order that saves you the most wasted effort is: measure, attribute, then fix the layer you actually found, not all three on faith.

• 1. Measure. Record TTFB and full-page-load across homepage, a busy category, and a product page. (Mechanics: is your store slow?)
• 2. Split server vs browser. High TTFB → server (database/hosting). Low TTFB, slow render → front-end (modules/assets).
• 3. If server-side, separate database from hosting. Slow back office + tables growing over time + repeat offenders in the slow log = database. Inconsistent by time of day + OPcache off + clean-but-still-slow = hosting.
• 4. If front-end, isolate the module. One page type far slower → Profiler the hooks, disable-and-remeasure the suspect.
• 5. Fix the layer you found using the linked guide for it, not a scattergun of all three.
• 6. Add caching last, matched to cause: object cache for a database bottleneck, full page cache for storefront TTFB.
• 7. Re-measure against your baseline. If the number didn't move, you treated the wrong layer. Go back to step 3.

Performance isn't a one-time fix. A store that was fast at 500 products needs another look at 5,000; a module list that was lean last year quietly grew. But the discipline that keeps a PrestaShop store fast isn't exotic, it's refusing to guess. Find out which of the three layers is actually costing you the seconds, fix that one, measure, and repeat. "PrestaShop is slow" is almost never true. "This store's database has been bloating for three years," or "these four modules each call an API on the product page," or "this shared host is oversold". One of those is true, and it's findable in an afternoon.

Frequently asked questions

The back office is slow too. Does that narrow it down?

Yes. It's one of the most useful tells you have. A pure hosting bottleneck or a front-end/module problem usually spares the admin, because the back office loads different pages and fewer storefront scripts. When the admin is sluggish as well, both sides are running the same queries against the same fat tables, which points hard at the database. Confirm with the slow query log: the same table showing up repeatedly without an index is your smoking gun.

One product page is slow but the homepage is fine. Where do I look?

That asymmetry almost always points at a module hooked into that specific page, a real-time stock checker, a cross-sell computing relationships, a reviews widget firing one query per item. A flat server or hosting problem slows everything evenly; a single slow page is a module signature. Enable the profiler, read the per-hook timing, and disable the suspect to re-measure. The before/after delta is exactly what that module costs you.

Will Redis fix a database bottleneck?

Partly, and only if the diagnosis genuinely points at the database. Object cache (Redis/Memcached) speeds repeated cacheable lookups and removes filesystem-cache overhead, but it is not a blanket SQL query cache, it caches only values explicitly stored through PrestaShop's cache APIs, so plenty of queries still hit MySQL. Prune the bloated tables and add the missing indexes first; layer Redis on a healthy database, where it pays back rather than papering over a scan.

Is it safe to cache my way past all of this?

A full-page cache is the biggest single storefront-TTFB win, but it only serves anonymous visitors. It does nothing for the logged-in customer, the cart, the checkout, or the back office, all of which still hit the real query. And you must never cache the cart/checkout/login pages themselves: a cached checkout can show one customer another's basket. Cache the storefront shell, leave the dynamic routes live, and treat caching as the last step, not the first.

I upgraded to PrestaShop 9 / PHP 8 and it's still slow. Why?

Because version upgrades lift the PHP and platform layer, JIT, OPcache, a cheaper Symfony 6.4 container compile, not the database. If your real cause is three years of ps_connections bloat or four modules each calling an API on the product page, the newer platform runs those exact problems on faster metal. Attribute the layer first; the upgrade helps the part that was never your bottleneck.