Performance Tuning Your PrestaShop Store: From Database Queries to Full Page Cache

Every 100ms of additional load time costs you conversions. In e-commerce, speed is not a nice-to-have — it directly impacts your revenue. This guide focuses on the specific, actionable optimizations that make the biggest difference for PrestaShop stores.

Start with Measurement

Before optimizing anything, you need a baseline. Use these tools:

• Google PageSpeed Insights — gives you Core Web Vitals (LCP, FID, CLS) and a performance score
• GTmetrix — provides waterfall charts showing exactly what loads when
• MySQL slow query log — enable it temporarily to find queries taking more than 1 second
• Xdebug profiler — for PHP-level bottleneck identification (use cachegrind for analysis)

Measure first, then optimize, then measure again. Otherwise you are guessing.

Database Optimization

The database is the most common bottleneck in PrestaShop. Here is what to check:

Index Your Custom Tables

If your modules create custom tables, make sure they have proper indexes. A missing index on a frequently queried column can turn a 10ms query into a 3-second table scan.

ALTER TABLE ps_my_module_data ADD INDEX idx_id_product (id_product);
ALTER TABLE ps_my_module_data ADD INDEX idx_date_add (date_add);

Clean Up Old Data

PrestaShop accumulates data that slows things down over time:

• ps_connections and ps_connections_page — can grow to millions of rows
• ps_log — truncate regularly
• ps_mail — old email records pile up
• Abandoned carts older than 30 days — safe to remove in most cases

Optimize Queries

Use EXPLAIN on any query that touches large tables. Watch for type: ALL (full table scan) and Using temporary; Using filesort — both are red flags.

PHP and OPcache

PHP-level optimization is often overlooked:

• PHP 8.2+ — significantly faster than 7.4, and PrestaShop 8.x/9.x supports it
• OPcache — enable it and set opcache.revalidate_freq=60 in production (not 0)
• Realpath cache — increase realpath_cache_size to 4096K for large stores
• Memory limit — set to at least 512M to avoid garbage collection pressure

Redis for Cache and Sessions

Replace the default file-based cache with Redis:

• Smarty cache, Symfony cache, and module caches all benefit from Redis
• Session storage in Redis eliminates file locking issues under high concurrency
• A single Redis instance can handle all these workloads for a typical store

Front-End Optimization

• CCC (Combine, Compress, Cache) — enable it in Performance settings, but test thoroughly
• Lazy loading — use native loading="lazy" on product images
• WebP images — 25-35% smaller than JPEG at equivalent quality
• CDN — offload static assets to Cloudflare or similar; set the media server URL in PrestaShop
• Critical CSS — inline above-the-fold styles to eliminate render-blocking requests

Full Page Cache

For stores with high traffic and relatively static catalogs, a full page cache (Varnish or nginx FastCGI cache) can reduce response times from 500ms to under 50ms. The tricky part is cache invalidation — you need to purge correctly when prices change, stock updates, or promotions start and end.

Start with the database and PHP optimizations — they give the biggest returns for the least risk. Layer on front-end and full page caching once the foundation is solid.