Store slowing down? The first reaction of most agencies and e-commerce owners is predictable: "Let's call the hosting provider and buy a more powerful VPS or a dedicated server." The invoice doubles, the accountant panics, and the store... is still sluggish.
Why? Because no processor or extra RAM will fix architectural and configuration errors in the code. Hardware has its limits, and optimized code scales much cheaper.
If you follow my social media activity, you know perfectly well that I have been fighting the "Presta is natively slow" myth for years. As I mentioned in my inaugural LinkedIn post (https://www.linkedin.com/posts/micha%C5%82-sobczak_prestashop-devops-webperformance-share-7424395494283444226-T0-e/), many stores lose huge amounts of money due to bugs that are obvious to an architect but remain completely invisible to the business side.
Today, I'm breaking down a specific audit of a store (15k+ products) that was choking with just 50 concurrent users online. Clearing these bottlenecks allowed us to drop the TTFB (Time to First Byte) from a nightmarish 2.5 seconds to just 300 milliseconds. Without spending a single dime on heavier infrastructure.
1. The Killer Real-Time Sitemap
During the aforementioned audit, the hosting provider threw their hands up, claiming the machine was running at full capacity. However, a quick glance at the logs and htop revealed a massive anomaly: Back Office employees were unknowingly destabilizing the entire front-end for the customers.
The culprit turned out to be the sitemap module, which was unfortunately hooked to the product update event (actionProductUpdate).
What did this mean in practice?
Every single click of the "Save" button—when a manager updated a price, description, or stock level in the admin panel—triggered the real-time generation of an XML file for all 15,000 products.
Result: The admin panel "hung" for 30 seconds.
All PHP threads (workers) were instantly utilized.
Customers trying to place an order on the front-end at the exact same time hit a brick wall with a 503 error.
Solution: Completely removing the sitemap generation from the application's core logic and moving this process to a CRON job, scheduled to run once a day at 3:00 AM when store traffic is at its lowest.
2. The Classic N+1 Problem and Database Junk
The second massive delay operator was the MySQL database, which was literally choking on every product page refresh.
First, the native PrestaShop statistics modules were enabled. Collecting analytics directly through the store's engine (in the database) is a relic of the past that has no business justification in the era of GA4. The ps_connections table can bloat to gigantic proportions, blocking the server's I/O operations.
Second, a "Customers also bought" module was causing absolute carnage on the product page. It was written in an extremely unoptimized way—instead of a single, well-crafted query using a JOIN (or IN) operator, the developer threw an SQL query inside a loop.
The N+1 problem in practice: For every recommended product displayed, the system executed a SEPARATE database query for its details. Instead of one hit to MySQL, we had dozens of them on every single page load.
Solution: Disabling the resource-heavy statistics modules, clearing the log tables, and refactoring the recommendation module's code to fetch the data batch in a single query. Additionally, we implemented aggressive object caching using Redis, which almost completely cut off the database from repetitive queries regarding store configuration and static product features.
3. When Standard UI Fails: The 8,000 Categories Horror
In e-commerce, we often encounter the problem of extreme association volumes (data relationships). Together with Miłosz Branewicz, we recently came across a severe engineering case where the standard PrestaShop structure simply surrendered.
The client had an advanced integration with an external API that dynamically created and assigned categories to products based on their features. After years of the system running, the database recorded absolute champions: a single product could have over 8,000 categories assigned to it.
You can read more about the architecture behind this problem and how standard inputs cease to be enough in my dedicated case study on LinkedIn (https://www.linkedin.com/posts/micha%C5%82-sobczak_prestashop-ecommerce-refactoring-share-7425086196017467392-9U9n/).
What was the performance issue?
Attempting to edit such a product in the Back Office was impossible. The default rendering of the full category tree (in the form of a gigantic checkbox structure) clogged the browser's and the server's memory. Cranking up the memory_limit to absurd values allowed the tab to open, but upon trying to save, the server still crashed with timeout errors.
Solution: Instead of fighting Presta's native tree component, we decided to cut it out of the product edition entirely and rewrite the mechanism from scratch:
We removed the default tree rendering in the Back Office.
We implemented full asynchronous behavior (AJAX) and pagination (categories load in batches of a few dozen as you scroll, not 8,000 at once).
We added a "live" category search engine.
Every assignment, unassignment, or default category change happens in the background (XHR) in a fraction of a second, immediately after clicking.
Thanks to this, the product page loads instantly, regardless of the scale of associations, and the front-end and customer search engine work without any changes.
4. The Exception to the Rule: When MUST the System Run Slower?
As an engineer, I usually wage a ruthless war for every millisecond. However, there are situations where intentionally delaying the server's response is the only way to protect the business. A perfect example is the recent security patch in PrestaShop (version 9.0.3), which patches a Time-Based Enumeration vulnerability.
As I detailed in my cybersecurity post (https://www.linkedin.com/posts/micha%C5%82-sobczak_prestashop-cybersecurity-ecommerce-share-7426903135241179136-hJWB/), hackers can exploit the fact that your server is... too fast and too honest. When attempting to log in, a bot provides an email address:
If the email DOES NOT exist in the database, Presta instantly returned an error (e.g., in ~20ms).
If the email DOES exist, the system had to fetch the password hash and run a resource-intensive cryptographic operation to compare it with the entered string. This took much longer (e.g., ~300ms).
For a bot, this 280ms difference is a clear message: "This email exists in the database, add it to the target list for a Brute-Force attack."
What does the new patch do? It introduces a so-called Constant Time Operation. If the user does not exist, the system intentionally performs "fake" processor calculations just to waste time and align the server's response for both scenarios to a constant ~300ms. The server deliberately runs slower to protect your customers' data privacy.
Conclusion: Profiler First, Shopping Later
Before you approve another higher invoice for hosting infrastructure, take a step back. Check htop, profiler logs (e.g., Tideways or the native PrestaShop profiler), and see where the system is actually losing time.
Remember, however, that official patches and a clean core are just the foundation of security and performance. If your e-commerce runs on 50 random modules from unknown authors purchased over the years, patching the engine itself is like installing an armored door in a house where you left the windows wide open.
Does your store need stabilization, protection against sales peaks, and clearing of technical debt? In my daily engineering practice under the Web Berserker banner, I don't just "click together" ready-made templates. I approach e-commerce architecture with strict rigor. Contact me directly via the form on the website, and as part of professional SLA maintenance, the very first thing I will do is perform a hard, structural audit of your code.