Why is PrestaShop slow — 12 causes and how to diagnose them

A "slow store" can mean slow HTML generation on the server, slow page rendering in the browser, or both at once. A high TTFB points the diagnosis toward the backend — PHP, MySQL, infrastructure and server configuration. A good TTFB with a poor LCP or INP points instead to the front-end — images, JavaScript, CSS and third-party scripts. This distinction saves hours of looking in the wrong place.

One of the more common and most underestimated causes. Shared hosting with high disk latency, restrictive CPU limits or little available memory may not keep up with a store that generates expensive queries and real traffic. The disk type (SSD vs NVMe) or the product count alone don't settle it — what matters is disk latency, random IOPS, host contention and the neighbours on a shared environment. A too-small InnoDB buffer pool increases storage reads and can worsen query latency.

How to diagnose: measure TTFB (server response time) multiple times, from a location close to the server, separately for cache hit and cache miss, and without extra redirects. Bear in mind that a publicly measured TTFB also includes DNS, TCP/TLS, proxy/CDN and the network — it is not pure PHP/MySQL time, so measure as close to the origin as you can, compare similar pages (p50/p95), and read the application time itself from the profiler or an APM. Our rough warning sign is ~600 ms on a category page — a practical threshold from audits, not a standard; it depends on location and architecture. Also check disk IOPS and CPU saturation. Do not diagnose by "RAM usage" alone — Linux and MySQL deliberately use free memory for cache, so high usage by itself is not a problem.

PrestaShop accumulates data over time: the ps_connections, ps_guest, ps_cart, logs and stats tables can grow to millions of rows. Also worth checking is ps_configuration, loaded heavily while serving requests: its growth after dozens of installed and removed modules (orphaned rows) can add overhead, but the real impact depends on the version and how it is cached — confirm it by measurement, and do not delete rows blindly (back up first, as manual cleanup can break modules). The default schema does have indexes, but as tables grow so does the cost of the queries that scan large ranges, sort/aggregate, or miss a suitable index (typically module queries) — not all queries get proportionally slower.

Without OPcache, PHP reloads and compiles the code from scratch on every request. In PrestaShop, also make sure that forced template (Smarty) recompilation is disabled in production and that the compiled-template cache is active. This is one of the first things to check — the check is quick and a misconfiguration affects the whole application; it is very often simply set wrong.

The object cache does not always speed the store up. In Advanced → Performance (on PrestaShop 1.7/8/9) you usually get APC (APCu on PHP 7+) and Memcached — the exact list depends on the store version and the installed PHP extensions. Redis is not a standard object-cache backend in the panel (the core has no CacheRedis class) — it needs a dedicated module. On a single, fast server the extra layer may bring no noticeable gain, and when misconfigured it can even add latency. It matters at higher traffic, for expensive operations and in multi-server setups. Measure cache effectiveness and your query profile before enabling it.

How to diagnose: check not only whether OPcache is active (opcache_get_status), but also whether it is short on memory and script slots (opcache.memory_consumption, opcache.max_accelerated_files, the cached-scripts count, out-of-memory restarts) and whether you are looking at the right SAPI — PHP-FPM, not CLI. Also verify Smarty template compilation and the var/cache/prod directory. Do not enable the object cache "just in case" — match it to your architecture and traffic.

Modules are one of the most common sources of "hidden" load. Rich filters, "recently viewed", recommendations or counters can generate hundreds of SQL queries on every page and load their own CSS/JS across the whole store.

How to diagnose: enable the profiler (set _PS_DEBUG_PROFILING_ to true in config/defines.inc.php) only in a controlled environment — the profiler exposes SQL queries, paths and configuration data, so never leave it on public staging or production. Then look at the SQL query count and load time per hook. More important than the raw query count is their total time, repetition and cost under load — a module responsible for a large share of PHP time, or running repeated, scanning queries, is a candidate for optimization, replacement or removal (hundreds of queries on a single page is a warning sign).

Product imports, stock synchronization, ERP and marketplace integrations, thumbnail regeneration, search indexing and bulk price updates can hit PHP, MySQL and the disk all at once. The store then slows down only at certain hours, so a one-off audit easily misses it.

How to diagnose: correlate the hours of slowdowns with the cron schedule, integration logs and the CPU, I/O and MySQL query charts. Running jobs off-peak helps, but it is not a universal cure (multi-market stores, continuous stock sync): limit concurrency, split work into smaller batches, queue it, add idempotency and retry with backoff, and guard against several copies of the same process running in parallel (a lock).

A store can be fast under normal traffic yet slow down because of price comparison engines, AI bots, SEO crawlers, marketplace integrations and scrapers. The most expensive URLs are filters, search, sorting and category combinations — each visit can generate heavy SQL queries.

How to diagnose: analyze access logs by IP, User-Agent, request count and most-visited URLs; check whether bots hit dynamic pages, the API, search and infinite filter combinations. Before you start blocking, distinguish the traffic classes (legitimate crawler, business partner, API integration, monitoring, malicious scraper) — each needs a different response: work out whether the traffic is business-required, whether the bot respects robots, whether it uses the API, whether its rate can be limited, and whether it has a stable IP or authentication. Only then reach for Cloudflare, rate limiting, cache rules and correct indexing management. Remember: robots.txt is not a security control — honest bots respect it, malicious ones need not.

Large, uncompressed images and render-blocking scripts wreck Core Web Vitals — especially LCP (time to render the largest element) and INP (responsiveness to interaction). This directly affects the perceived speed, and Core Web Vitals are one of many signals Google systems take into account.

For a store serving mainly one market, with a server in a nearby region, good cache headers, HTTP/2 or HTTP/3, a fast origin and fewer resources often matter more than a CDN. The latency benefit of a CDN is usually larger for users far from the origin, but a CDN also offloads and protects the server (cache, traffic-spike absorption, TLS termination, bot filtering) for domestic traffic too. Compression (Brotli/gzip) greatly reduces the transfer of text assets — HTML, CSS, JS, JSON, SVG; already-compressed formats (JPEG, WebP, AVIF, PNG, WOFF2) gain little from it.

How to diagnose: check separately the cacheability and headers (Cache-Control, asset versioning), the compression (Content-Encoding), and the transfer and download time of static assets from different locations.

Practical tip: for many stores, the simplest way to offload the server is putting Cloudflare in front. Even the Free plan gives a global CDN, compression, HTTP/3, static-asset caching and basic bot filtering. Installing it will not fix slow code or a slow database, but it often usefully complements infrastructure optimization — what it gives you, where its limits are and which mistakes to avoid, we cover in a separate article.

Every dynamic PrestaShop request occupies one PHP-FPM worker. When all workers are busy, further requests wait in a queue — even if the server is not using all of its CPU or RAM — so the store stalls or returns 502/504 while looking idle. It is worth seeing this for what it usually is: a symptom, not the root cause. The pool fills up because something is making requests slow, and that something is normally one of the causes already covered — slow SQL, expensive modules, bots, external APIs or cron jobs. Hitting the pm.max_children limit is only evidence that the workers are busy; it does not say why.

That is why raising pm.max_children without finding the underlying cause usually just hides the problem — and can make it worse, since more concurrent workers mean more memory used and more parallel load on MySQL. Before touching the pool, correlate the signals: the "server reached pm.max_children" message and pool status (active processes, listen-queue length, the max_children-reached counter), the PHP-FPM slowlog (request_slowlog_timeout), request duration, MySQL activity (Threads_running), external API calls, bot traffic and the cron schedule. Only once you know what is keeping the workers busy should you size the pool — and never raise pm.max_children without calculating a single worker's memory footprint, or you risk swapping and processes being killed by the OOM Killer.

Debug mode (_PS_MODE_DEV_) left on after deployment turns on extra diagnostics, detailed error reporting and development-environment mechanisms, which can significantly increase the time and memory of every request. The profiler (_PS_DEBUG_PROFILING_) adds a separate, large measurement overhead on the front office and back office. This is a common, trivial, yet very costly mistake.

How to diagnose: verify _PS_MODE_DEV_ and _PS_DEBUG_PROFILING_ in config/defines.inc.php (and config/defines_custom.inc.php if it exists — the values set there take precedence). In production both must be disabled.

Unsupported, older PHP versions are not only a security risk — they also lack many performance improvements from newer releases. The real gain, however, depends on the store code, the modules and the OPcache configuration. Note: the PHP version is tied to the PrestaShop version (older PrestaShop will not run on the latest PHP), so bumping PHP usually requires a coordinated PrestaShop and module upgrade — a project, not a flag flip.

How to diagnose: check the PHP version (php -v) and the PrestaShop version in the back office, then verify which PHP your PrestaShop version supports. Do not upgrade PHP without testing theme, override and module compatibility. A newer PHP can improve performance, but the effect has to be measured on the specific store — sometimes the dominant problem remains SQL, an API or a module.

Apache reads the .htaccess file and recompiles its RewriteRule directives on every request (unlike the vhost configuration, where rules are compiled once and cached). If someone dropped thousands of unoptimized 301 redirects into .htaccess — after a URL migration or from an SEO module — every request runs sequentially through hundreds of regular expressions. That directly raises TTFB, the server response time.

How to diagnose: check the size and rule count of .htaccess (how many RewriteRule/Redirect lines) — the count alone, though, is only a signal; order, backtracking, the number of RewriteCond and how often rules match all matter too, so confirm the problem by measurement (compare TTFB with the full vs a slimmed-down .htaccess). The fix: move stable rules into the server configuration (vhost), where they compile once, and handle bulk redirects more efficiently — a server-level redirect map instead of a thousand regex lines. Note: on shared hosting or Plesk, vhost access is often unavailable — then at least reduce and simplify the rules. A plain Redirect (mod_alias) can be cheaper than a complex RewriteRule when no rewriting is needed, but it has different semantics (query strings, ordering) — verify them before swapping.

A slowdown is usually not one cause but several at once. The first step is always an audit: TTFB measurement (separately for cold and warm cache — the first hit after a cache clear can be much slower), slow query log analysis, PHP profiling and a hosting test. Only the data shows what to fix first to get the biggest effect for the least effort. For tougher, cross-layer cases, an APM or transaction profiling (e.g. Blackfire, Tideways, New Relic, Datadog, OpenTelemetry) that ties a single request to the controller, module, SQL and external API helps.

A single test does not show how the store behaves under load — PrestaShop may respond in 300 ms for one request yet slow to several seconds during a campaign or a bot surge. Run a controlled load test — preferably against a production-like environment or in an agreed window, on safe endpoints and with a capped rate, because a test can overload the store, send emails, create carts, fire integrations and trip the WAF. For realistic scenarios use k6 or a similar tool that handles sequences, cookies and multiple endpoints (treat ab as only a simple single-URL test). Watch, at the same time, CPU, I/O wait, load average, the PHP-FPM queue, MySQL Threads_running, throughput (RPS) and the error rate (timeouts, 429, 5xx), and the p95/p99 response time, not just the average. And do not judge the store by a single Lighthouse run — compare lab data with real-user Core Web Vitals (CrUX) and with server-side measurements.