Why is your PrestaShop shop running slowly? The truth about modules, hosting and the ‘headless’ trap

The same scenario plays out almost every week. A desperate e-commerce owner contacts us: their PrestaShop shop takes 4–6 seconds to load at peak times, customers are abandoning their trolleys, and Google Ads or Meta Ads campaigns are burning through the budget due to a high bounce rate.

An entrepreneur’s first instinct? „Our server’s probably not powerful enough.” So they go ahead and upgrade their hosting package, migrate to a powerful VPS, and often end up buying a dedicated server for 1,000 or 1,500 zł a month. The result? The website has gained a fraction of a second, the infrastructure bill has risen several-fold, the database still crashes at the slightest promotion, and the online shop is just as sluggish as it ever was.

The truth can be uncomfortable: You can buy a server the size of a small nuclear power station, but if the shop’s code is poorly optimised, the database will still be wrecked.

Where does the real source of the problem lie? In practice, it boils down to two main causes.

1. A collection of modules and SQL queries that crash the database

PrestaShop is a powerful, flexible platform with a vast ecosystem of ready-made solutions. This is its greatest strength, yet it is also the source of its biggest performance issues. Many shop owners and inexperienced developers treat modules like Lego bricks: „I need a pop-up – I’ll download a module”, „I want a free delivery banner – another module”, „a review carousel – a third module”.

As a result, 60, 80 or sometimes over 100 third-party modules end up running on the shop. The problem is that a large proportion of them come from random developers on marketplaces and have been written without adhering to basic software engineering standards.

These modules are extremely poorly optimised for working with the database:

• Missing indexes in tables: The module creates its own tables in MySQL, but the author fails to index the columns used later to filter the data. The result? With every query, the database performs a so-called. full table scan – it searches through hundreds of thousands of rows from start to finish, rather than instantly retrieving a specific record.
• The deadly problem of N+1 queries: A poorly written module: instead of retrieving data for the 20 products in the category list using a single optimised query from JOIN, it sends a separate query to the database for every single product on the list. Multiply that by 10 poorly designed modules and 50 users browsing the catalogue at the same time – the database performs thousands of unnecessary, resource-intensive operations in a fraction of a second.
• No caching: Complex calculations and queries are performed anew every time the page is reloaded, rather than storing the processed result in the cache.

As a result, it is not the processor’s computing power or the amount of RAM on the server that is the bottleneck. The bottleneck is the blocked queue of queries to MySQL, which pushes the server’s response time (TTFB) up to several seconds.

2. Poor hosting and an unsuitable environment architecture

The second reason is the infrastructure, which is advertised as offering „unlimited data transfer and plenty of gigabytes” in promotional brochures, but in reality bears no resemblance to an environment optimised for e-commerce applications.

PrestaShop is a comprehensive system based on PHP and a relational database. Above all, it requires a very fast single CPU thread (high clock speed Single Core Performance), rather than dozens of slow cores. Furthermore, it requires a specific environment configuration:

• There is a lack of aggressive code caching by OPcache with a sufficiently large cache limit,
• The shop is running on an outdated version of PHP (e.g. 7.4 instead of 8.1 or 8.2), which automatically reduces script execution performance by 20-30%,
• The database engine operates using the provider’s default, conservative settings (the pool size is too small innodb_buffer_pool_size), which means that, instead of operating from fast RAM, MySQL is constantly reading data from the hard drive,
• There is no integrated RAM cache (e.g. Redis or Memcached), which would take over the management of user sessions and system objects, thereby reducing the load on the main database.

Is that all? Absolutely not – you need synergy (1 + 2)

You may have a perfectly configured, dedicated server, fine-tuned by the best systems administrator on the market. However, if your PrestaShop shop is overloaded with sub-optimal modules that generate hundreds of chaotic database queries – That fast hosting won’t make any difference. The database will end up getting clogged up anyway, and the server’s resources will be pointlessly wasted.

It works the other way round too: you can have a perfectly optimised, lightweight template and a clean database free of unnecessary clutter. However, if you host that shop on a cheap, sluggish shared hosting plan costing 100 zł a year, where hundreds of other websites are competing for the same CPU thread – The shop will still run slowly anyway.

Maximum performance in e-commerce is always a matter of: A lightweight, optimised shop + server architecture tailored to PrestaShop. One simply cannot exist without the other.

Headless PrestaShop – is it worth going for?

In the face of performance issues in the e-commerce sector, a certain trend has emerged. Many agencies are offering a „modern” solution: „Let’s go headless! Let’s detach the standard frontend, build the application using Next.js or Nuxt, and leave PrestaShop solely as a backend engine connected via an API.”.

In theory, it sounds modern and prestigious. In practice? Converting PrestaShop to a headless setup is, in the vast majority of cases, a terrible idea.

We know this first-hand. We’ve already had 2–3 projects come our way that were left half-finished by previous contractors precisely because they hit a brick wall with headless architecture. Clients had wasted huge budgets, were left with non-functional shops, and found themselves back at square one. What was the outcome? Instead of ploughing ahead down this dead end, we rebuilt these shops from scratch using a classic, well-refined PHP architecture. The result? In terms of speed and performance, we achieved results virtually identical to those promised by headless architecture, whilst our clients avoided a whole host of major technological problems:

• You’re making the architecture far more complicated: Instead of a single, integrated system, you have to maintain, monitor and pay for two completely separate environments – a Node.js application serving the front-end and the PrestaShop engine on the back-end. This doubles the number of potential points of failure.
• You lose compatibility with 90% off-the-shelf modules available on the market: Forget about installing payment gateway modules, parcel lockers, instalment payment systems or marketing tools with a single click. Any module that affects the shop’s layout must be manually integrated from scratch and programmed at the front-end level in JavaScript.
• The enormous cost of the service: Any modification to the template – however minor – a change to the shopping basket or the addition of a new banner requires the involvement of full-stack developers, which increases the ongoing maintenance costs of the online shop by hundreds of per cent.

And what about performance itself?

The truth is that A well-optimised, lightweight, dedicated theme built on the classic PrestaShop engine achieves scores of between 90 and 98 points in Google PageSpeed tests on mobile devices.

For the end user, the difference in performance between a well-refined classic template and a headless architecture is marginal and often imperceptible. However, the difference in the complexity of the process, the implementation budget and subsequent maintenance costs is simply colossal.

Where should you start when trying to fix a slow-loading shop?

Before you spend yet more thousands on a more powerful server or take the risky decision to rewrite your shop using the latest technologies, start with hard data and basic technical best practice:

1. Enable the PrestaShop Profiler on the test environment: Take a close look at which database queries take the longest, which tables are overloaded, and which modules cause the greatest delays when generating a page.
2. Carry out a thorough audit of the modules: Disable and uninstall anything that does not generate direct sales value. Replace five poor-quality modules – from simple animations to clean code in the template.
3. Optimise MySQL tables: Review the database structure, remove phantom shopping trolleys, clear the system logs and add any missing indexes to the external module tables.
4. Ensure the right environment: Make sure your server is running a new version of PHP, has OPcache configured, and supports Redis as an object cache.
5. Go for a bespoke, lightweight theme: Instead of overloaded ready-made templates with hundreds of unnecessary options, choose a template tailored to your actual needs – without any unnecessary CSS or JavaScript that blocks page rendering.

A fast PrestaShop site isn’t a matter of „magic” or blowing the budget on oversized servers. It’s a matter of sound programming craftsmanship, a well-organised database and a properly chosen infrastructure.