Speeding Up PrestaShop: Where the Store Loses Seconds and Orders
A slow PrestaShop almost never hits a "weak server" — it hits specific bottlenecks that are visible in the profiler and slow query logs.
A catalog with several thousand products with filters by attributes and combinations generates heavy queries with multiple JOINs, and a category page assembles the price, stock, and discount for each product with a separate database call.
Add to that unoptimized templates with extra modules in hooks — and server response time grows with every installed discount or recommendation add-on.
The cost of this is not abstract "seconds" but customer behavior.
Online store loading speed directly affects whether a person makes it to the cart: on a slow catalog, some visitors leave before the product list finishes rendering, and search engines show pages with poor response metrics less often.
Under load, during a sale or an ad campaign, the picture gets worse: bloated statistics, cart, and log tables begin competing for resources with the catalog, and the store sags exactly when traffic arrives.
A separate category is optimizing store speed on the delivery side: uncompressed catalog images, blocking module scripts, no page caching, and repeated database queries on every hit.
Here it's important not to guess but to measure: capture a query profile, see which pages respond slower than the rest, and find what exactly is eating the time — the database, the template, or external calls.
We begin speeding up PrestaShop with diagnostics, not with installing yet another cache module: first a map of PrestaShop bottlenecks, then targeted fixes — indexes and rewritten catalog queries, cleaning up hooks and templates, configuring caching and compression. Next, we break down how this is closed step by step.
What gives PrestaShop acceleration: response time, cache, failures
PrestaShop acceleration starts with an honest measurement: where exactly the store loses time. In practice, 60–80% of the delay comes not from the frontend but from the catalog — heavy queries across attribute combinations, recalculating prices and stock on every listing page. Until this is separated by layers, any "by eye" tweak speeds up one page and slows down another.
Application-level caching
Full-page cache for guests and category listings removes repeated template assembly and database queries. Category response time drops from seconds to hundreds of milliseconds, and server load stops growing linearly with the number of visitors.
The limitation — the cart, checkout, and customer account cannot be cached, they are assembled per user.
Catalog query optimization
This is where the main class of failures under peak load goes away. We separate product retrieval from facet counting, remove SELECT * and unnecessary JOINs across related tables, and move discount and stock recalculation into background jobs.
A catalog with tens of thousands of items stops blocking connections during a simultaneous surge — instead of a queue and timeouts, the server serves the page in predictable time.
Infrastructure layer
Object and session cache in memory, a separate node for static assets, HTTP cache for images and theme resources. This does not speed up an individual query, but it removes load from the database server — which is most often the bottleneck under traffic.
| Approach | When it fits | Limitations |
|---|---|---|
| Full-page cache | Catalog, categories, product pages for guests | Does not work for the cart and authenticated scenarios |
| Catalog query optimization | Large catalog, complex filters and discounts | Requires reworking modules and theme templates |
| In-memory cache and CDN | Stable traffic, lots of static assets | Does not fix slow database queries |
| Hardware replacement | Fast temporary effect | The problem returns as the catalog grows |
The combination of the first three gives a lasting result: store response time is cut severalfold, and peak failures disappear as a class. We rely on the built-in caching mechanism and query profiling of PrestaShop, not on third-party add-ons that break updates.
How we speed up PrestaShop: stages of engineering work
Speeding up PrestaShop begins not with edits in templates, but with measurement: until there is accurate data on exactly where time is being lost, any optimization turns into guesswork.
Therefore, the first step is a PrestaShop performance audit on a real load profile: we take measurements on the catalog, cart, checkout, and admin panel, analyze slow database queries, the weight and number of files on the page, and the behavior of modules and third-party extensions.
The output is a map of bottlenecks with priorities: what delivers the main gain and what merely masks the problem.
- PrestaShop performance audit. We profile key scenarios, collect statistics on slow queries, measure response time before and after cache warm-up, and record a baseline for comparison.
- Optimization plan. We draw up a work scheme with the expected effect for each item: indexes and query structure, disabling unnecessary modules, optimizing templates and images, configuring the server environment.
- Cache configuration. We configure caching at all levels — template compilation, catalog and category cache, object cache, page cache at the server level — with correct invalidation when products and prices are updated.
- Query and database optimization. We rewrite heavy queries, add missing indexes, and clean out outdated statistics and log tables that quietly slow down the catalog.
- Load testing. We run scenarios with concurrent users, check behavior under peak load, observe how the cache behaves on a cold start, and repeat measurements against the baseline.
- Documentation handover. We provide configurations, the caching scheme, a list of modified queries and modules, instructions for safe updates and rollback, as well as a checklist for post-release monitoring.
Each stage ends with a measurable result, not a report saying "the work has been completed." If after cache configuration the catalog response time has not changed, then the bottleneck was not in the cache — and we return to the audit rather than moving on down the list. This order eliminates the situation where a store has been "optimized" but still lags at checkout.
Describe your task and current stack — we will come back with an estimate and a work plan for your store.
How does acceleration through cache differ from query optimization?
Cache and query optimization solve different problems, and confusing them is the most common reason why PrestaShop acceleration produces an effect for a week, and then the store starts "sinking" again.
Cache eliminates repeated work: a catalog page assembled once is served from storage until the data changes. Query optimization eliminates the work itself: heavy SQL stops scanning entire tables.
The first treats the symptom, the second treats the cause, and individually each hits its own ceiling.
Caching is beneficial where data is read frequently and changed rarely: categories, product pages, static pages, blocks with selections. As long as the catalog isn't updated, delivery comes from cache, and the database rests.
But as soon as the cache is invalidated — during a bulk import, price changes, stock updates — all queries return at once. If they aren't optimized, the store gets a load spike at exactly the moment when it's critical.
Query optimization works at the level of data structure. Database indexes turn row iteration into point lookups: filters by category, price, attributes, sorting in listings, and selections in the admin panel stop reading entire tables.
Rewritten SQL eliminates unnecessary joins and repeated accesses to the same tables within a single page. This delivers a stable gain at any catalog size — and on a cold cache too.
The choice of approach is determined by the load profile. If the catalog is small and traffic is steady, a properly configured PrestaShop cache is sufficient — it covers the bulk of delivery.
If the catalog has tens of thousands of items, many filters, and frequent stock updates, a cache without SQL optimization will be constantly invalidated and won't have time to cool down.
In practice, the approaches are combined: first unnecessary queries are eliminated and indexes are added, then the cache is configured on top of already fast selections — that way it holds the load rather than masking it.
The order of work here is not a coincidence but a condition for results: a cache on top of slow queries gives a short-lived effect and a high risk that the store will go down at the very first catalog update.
Describe your case — catalog size, update frequency, traffic peaks — and we'll come back with an assessment of which approach will deliver stable acceleration in your specific case.
Case study: how PrestaShop acceleration cut response time by three times
A PrestaShop store came to us with a catalog that was growing faster than its infrastructure: tens of thousands of products, hundreds of attribute combinations, tens of thousands of visitors per day.
The catalog had grown, and a category page was assembled from hundreds of individual database queries — under peak load, response time reached 6-8 seconds, and some requests dropped out on timeout.
The owner saw this as "the site sometimes goes down during peak hours" and was losing orders precisely during the most profitable hours.
We captured a profile on live traffic and on a synthetic load test reproducing the peak.
The picture turned out to be typical for an overgrown PrestaShop: heavy queries across product-attribute-category relations ran on every page view, the page cache did not cover filters and pagination, and some modules loaded data synchronously where it was not needed.
We checked the indexes separately — on the overgrown relation tables they were missing, and the database was scanning entire tables.
What we changed: we rewrote the heaviest catalog queries and added the missing indexes, enabled multi-level caching — pages, category blocks, and filter results, moved static assets and media to a separate delivery layer, and deferred non-critical modules. Every change was verified with a load test so as not to catch a regression at peak.
Metrics before and after:
| Metric | Before | After |
|---|---|---|
| Category response time (peak) | 6-8 s | 2-2.5 s |
| Share of requests with timeout | noticeable | isolated |
| Database load at peak | grew linearly with the catalog | stable |
| Behavior under peak traffic | degradation, failures | holds the peak without a dip |
The class of failures that was eliminated is degradation under peak: previously, when visitors flooded in, the site started to "crumble" and lost orders; now the peak passes smoothly.
PrestaShop acceleration here was delivered not by a single technique but by the combination of "queries + cache + static delivery," and that is exactly why the result is sustainable rather than one-off.
We honed the caching methodology and the analysis of heavy queries in practice, relying on the PrestaShop performance documentation and on profiling on real traffic.
Compatibility, migration, and rollback concerns — let's discuss your task
The most common technical fear before speeding up PrestaShop is that after the changes prices will go haywire, checkout will break, or the integration with 1C and the warehouse will fall apart.
That's why we never touch a live store "head-on": first we take a full copy of the database and files, deploy it on a separate staging environment, and run all changes — caching, indexes, templates, modules — there.
Only when the copy passes checks for checkout, cart, and export does the configuration get transferred to the production server.
Our rollback isn't just "on paper" either. Before deployment we lock in a return point: a database snapshot, the file version, and a list of changed settings.
If something behaves incorrectly after the transfer, we return the store to that point in minutes, not in a night of manual troubleshooting.
We grant access on the principle of least privilege: a separate user for the task, without rights to customers' payment data, all actions logged, and access closed once the work is complete.
What if we have custom modules and our own theme?
That's the norm, not the exception. Before we start, we analyze which modules interfere with catalog and cart output, and we test the acceleration specifically on them — on a staging environment with your copy.
If a third-party module is incompatible with the enabled caching, we find a workaround or leave it out of the cache so functionality isn't lost.
What if a PrestaShop update conflicts with the current modifications? We lock the branch and core version before work begins and don't pull updates during the process — otherwise the rollback point is lost. We plan the update as a separate stage, after speed has been stabilized.
What if further work is needed after delivery? We hand over not just the result, but also how it's built — so changes can be made without us.
The client receives:
- a snapshot of the database and files before the changes — the return point;
- a list of changed server, cache, and PrestaShop settings;
- the caching and indexing rules configuration;
- the deployment scheme for the staging and production environments;
- a list of modules with compatibility notes;
- an access log and permissions matrix;
- a brief guide to rollback and post-release checks.
Describe your configuration — which modules, theme, and how product export is set up. We'll come back with an estimate and a work plan for your store.
