Why your PrestaShop store is slow, and what actually helps

A slow store loses sales twice: visitors leave before the page loads, and search engines rank slow pages lower. The good news is that PrestaShop is rarely slow because of PrestaShop itself. Usually it is a handful of specific things, and some of them take minutes to fix.

This guide goes from the server to the browser, in the order we check stores ourselves.

Measure first#

Before changing anything, write down where you are:

• PageSpeed Insights (pagespeed.web.dev) for the home page, one category page and one product page, on mobile. It shows Core Web Vitals: LCP (how fast the main content appears), INP (how fast the page reacts to clicks) and CLS (how much the layout jumps).
• Server response time. In the browser's developer tools, the Network tab shows how long the first HTML document takes. If that alone is over one second, start with the server and the database, not with images.

Measure the same pages after every change. Otherwise you will not know what helped.

The server#

• PHP version. Newer PHP versions are noticeably faster. PrestaShop 8 supports PHP up to 8.1, and PrestaShop 9 runs on PHP 8.1 to 8.4. A store still on PHP 7 is leaving speed on the table.
• OPcache must be enabled. Without it PHP compiles every file on every request. Most hosts enable it, but not all.
• Enough resources. Cheap shared hosting can be fine for a small catalogue, but it slows down with thousands of products, many combinations or layered navigation.

The Performance page#

Advanced Parameters > Performance has the settings that matter most, and they are often left in development mode after a launch or an update:

• Template compilation: Never recompile template files on a live store. Recompiling is only for development.
• Cache: turn on the Smarty cache.
• Debug mode: off. It slows every page and shows internal details.
• CCC (combine, compress and cache) for CSS and JavaScript: fewer files for the browser to download. Test the store after turning it on, because a badly written module can break when its scripts are combined.

Modules#

Every active module can add database queries, CSS and JavaScript to each page, even where it does nothing. Stores that have been running for a few years often have dozens of modules nobody remembers installing.

• Uninstall modules you do not use. Disabled modules are better than active ones, but uninstalled is best.
• Watch for modules that load their scripts on every page while they are needed only on one, such as a product page widget loaded on the home page.
• Debug mode with the profiler shows which hooks and modules take the most time on a page. That points to the real culprit instead of a guess.

Images#

Images are usually the heaviest part of a page.

• Upload at a sensible size. A 5000-pixel photo straight from the camera is too large for any screen. PrestaShop creates smaller copies, but the original still costs disk space and time.
• Modern formats. Recent PrestaShop versions can also generate WebP or AVIF images (Design > Image Settings). They are much smaller than JPEG at the same quality. After changing formats, regenerate the thumbnails.
• Lazy loading for images below the first screen, and no lazy loading for the main image at the top, which should load first because it is usually the LCP element.

Theme and scripts#

• Fonts, sliders, chat widgets, tracking pixels and review badges all add up. Each one should earn its place.
• External scripts (chats, pixels, A/B tools) cannot be cached by your store and can block the page. Load them later where possible.
• A heavy theme bought for its demo often loads features the store never uses.

The database#

This is the part most often forgotten, and in older stores it is frequently the main problem.

• Statistics tables grow forever. Tables such as connections, connections_source and guest store every visit. After a few years they can hold millions of rows and slow down pages that touch them. Old rows can be cleaned up safely, after a backup. If you use another analytics tool, the built-in statistics modules may not be needed at all.
• Logs and abandoned carts also pile up: the log table, cart rows from visitors who never ordered, old mail entries.
• Layered navigation (faceted search) keeps its own index. Rebuild it after big catalogue changes, using the cron link the module gives you, so filters stay fast and correct.

What to do first#

If you only have an hour, this order gives the most for the least:

1. Check the Performance page: no recompiling, cache on, debug off.
2. Uninstall unused modules.
3. Check PHP version and OPcache with your host.
4. Look at the size of the statistics and cart tables.
5. Then images and scripts, measured page by page.

Need a hand?#

Our speed audit and fixes package covers all of the above for a fixed price of €390: we measure, find what slows your store down, fix it (up to 8 hours of work included) and show the results before and after.