# Slow PrestaShop: where the problem comes from and how to fix it
Table of Contents
A slow online store loses sales, and it’s a silent loss: no customer writes in to say the page took too long, they simply close the tab and buy elsewhere. Every extra second of waiting is paid in abandoned carts, and the bill arrives at the worst possible time, when a promotion or a campaign brings more traffic than usual.
PrestaShop is not a slow platform by itself: it becomes one. Years of modules installed and never removed, a theme bought for its looks, hosting chosen when the shop was small, a database grown without maintenance. The good news is that slowness is neither a sentence nor a mystery: it can be diagnosed and cured, as long as you proceed with a method instead of guesswork.
Slowness always has an address
“The site is slow” is a single symptom, but the causes live in different places: the network and the hosting, the PHP version and its configuration, the MySQL database, the theme and the modules, the front-end with its scripts. Each layer has its own remedies, and working on the wrong layer produces nothing.
The most common mistake is exactly that: moving to more expensive hosting without knowing where the time is lost. If the bottleneck is a module running hundreds of queries to build the home page, doubling the server’s RAM changes little: the bill goes up, the waiting stays.
Measure before you touch anything
Diagnosis separates two families of time. There is the time the server takes to generate the page, visible in the TTFB, the Time To First Byte, and the time the browser takes to make it usable, measured by the Core Web Vitals. A high TTFB points to server, PHP, database or caching; a good TTFB with a sluggish page points to theme, images and scripts.
The tools are already there. PageSpeed Insights frames the front-end. On the server side, PrestaShop ships with a built-in profiler: turn it on and you see, page by page, how much time goes to PHP, how many queries run and which ones cost the most. On the database, MySQL’s slow query log records every statement over a threshold. A concrete example: if the home page answers in 1.8 seconds and the profiler shows 900 queries, the problem is not the image slider, it’s whoever builds that page.
Server side: PHP, OPcache and MySQL
PrestaShop is a PHP application, and the PHP version matters: every recent release runs the same code faster than the previous one, and old versions, besides being slow, no longer receive security fixes. Next to the version you need OPcache, the extension that keeps compiled code in memory instead of recompiling it on every request:
; /etc/php/8.3/fpm/conf.d/10-opcache.iniopcache.enable=1opcache.memory_consumption=256opcache.max_accelerated_files=40000; in production: no file checks on every request,; the cache is flushed at deploy timeopcache.validate_timestamps=0On the database side, MySQL’s golden rule is an InnoDB buffer pool sized so that the shop’s hot data fits in memory: if the buffer is too small, every product page pays disk reads that could be avoided. The picture is completed by a PHP-FPM pool proportioned to the available CPU and RAM and by an active slow query log, so problem queries are seen rather than suspected.
Modules and theme: the usual suspects
Every installed module adds hooks that fire on each page, extra queries, sometimes calls to external services that hold the response hostage. The marketplace is full of well-written modules and badly written ones, and a single bad one is enough: the classic defect is a query repeated for every product in a listing instead of one query for the whole listing.
The cure is unglamorous but effective: an inventory of the modules, disabling the unused ones and the duplicates, and for the suspects the acid test, disable and measure again. The same goes for the theme, where overrides accumulated over the years can rewrite pieces of the platform less efficiently than the original.
The right cache in the right place
Caching in a PrestaShop works in layers: the Smarty template cache, the platform’s internal cache, a full page cache in front of everything for pages that are identical for all visitors, ideally served by a reverse proxy, and a CDN for images and static assets.
Two warnings. First: a cache hides slow code, it does not repair it, and cart, checkout and account areas stay dynamic by nature, so a healthy backend is needed anyway. Second: a badly configured cache does worse damage than slowness, from an outdated price shown to a customer to another user’s cart. It has to be designed, not merely switched on.
Hosting matters, but it’s not always to blame
On shared hosting resources are split with the neighbours: CPU, disk and database can slow down through no fault of yours, and the limits show as soon as the shop grows. Moving to a VPS or to cloud sized on real traffic is often the turning point, and choosing the provider deserves the same criteria as any serious infrastructure.
The right order of things still stands, though: more powerful hardware applied to a shop with 900 queries on the home page is an elegant way to pay more for the same problem. Diagnosis first, sizing second.
In summary
A slow PrestaShop is tackled in sequence: measure TTFB and front-end to understand which side the problem is on, read the profiler and the slow query log, fix the server foundations (recent PHP, OPcache, MySQL with adequate memory), clean up modules and overrides, layer the caching where it helps and, only then, size the hosting on real traffic. Every step is verified by measuring again: if a change doesn’t move the numbers, it wasn’t the bottleneck.
