PrestaShop Performance Optimization — Speed Guide [2026]

PrestaShop can be fast — but a default installation with a dozen modules and an unconfigured server is one of the most common causes of cart abandonment in e-commerce. Every extra second of load time means real losses: conversion studies show that a one-second delay can cut sales by several percent. The good news: PrestaShop can be optimised methodically — from server and PHP, through caching and images, to the database and modules. A typical audit shows 30–70% faster load times, and implementing the optimisation usually costs 1,500–5,000 PLN net.

Najważniejsze: PrestaShop optimisation works across five layers: server and PHP (8.x, OPcache, Redis), PrestaShop caching (Smarty, CCC, full-page), images and frontend (WebP, lazy loading, CDN), the database (cleanup, indexes) and modules/overrides. A performance audit costs 500–1,500 PLN net, implementation 1,500–5,000 PLN net, and ongoing care from 300 PLN per month. The result: faster loading, better Core Web Vitals and higher conversion.

Where to start optimising a PrestaShop store?

Start with measurement, not guesswork. Without data you cannot tell whether the bottleneck is the server, the theme or a single module — and "optimisation by feel" ends with money spent and no result.

1. Performance audit — PageSpeed Insights and Lighthouse (Core Web Vitals: LCP, INP, CLS), WebPageTest for a full loading profile.
2. Server profiling — PHP response times, CPU/RAM usage, disk I/O, MySQL/MariaDB configuration.
3. PrestaShop profiling — in developer mode enable the profiler (the _profiler parameter) to see which SQL queries and hooks consume the most time.
4. Module and override inventory — every front-office module adds CSS, JS and queries; overrides can break caching.

Only after the audit do you know what to fix first. The usual order of work: server → cache → images → database → modules.

Server and PHP — the performance foundation

Most slow PrestaShop stores are the result of a mismatched hosting plan. A store is not a brochure site: it runs database queries on every category view and cart action.

• PHP 8.x — PrestaShop 8 and 9 support PHP 8.1+; moving from PHP 7.4 to 8.x alone typically makes code execute 20–40% faster.
• OPcache — enabled and properly configured (memory size, validate_timestamps off in production).
• Redis or Memcached — object caching for PrestaShop, configured in app/config/parameters.php. Redis cuts database queries by 30–60% under heavy traffic.
• Nginx + PHP-FPM — the most common stack for PrestaShop; Apache with mod_php is clearly slower today.
• MySQL/MariaDB — InnoDB, a properly sized buffer pool (innodb_buffer_pool_size), a separate database server for large stores.
• HTTP/2 or HTTP/3 + CDN — especially for stores selling across the country.

Caching in PrestaShop — what to enable and what to watch

PrestaShop has several cache layers and each one needs a decision.

• Rule: enable each layer separately and measure. Caching without measurement is asking for trouble — especially when modules are not compatible with full-page cache.

Images and frontend — the biggest gain for the least effort

On a typical category page, images are 60–80% of the weight. That is why image work delivers the fastest results.

• WebP or AVIF format — less weight at the same quality; PrestaShop 8+ generates WebP natively once enabled in performance settings.
• Correct thumbnail sizes — configure image types (Design > Image Settings) so a category does not load product-size photos.
• Lazy loading — native loading="lazy" below the first screen.
• Compression and image CDN — image CDNs can remove up to 40% of transfer from the server.
• Fonts and icons — self-hosted fonts, subsetting, SVG icons instead of whole libraries.
• Critical CSS and JS — defer non-critical scripts, clean up third-party scripts (chats, pixels).

The database — the invisible performance killer

Stores running for years carry thousands of records that should never have stayed there.

• Guest carts — the ps_cart table can hold millions of rows; cleaning old, abandoned carts is a standard procedure.
• Statistics — ps_connections, ps_connections_page, ps_page_viewed: archive and clean according to a retention policy.
• Old orders and logs — archive to history tables instead of keeping everything in operational tables.
• Indexes — review indexes against the most frequent queries (category, product, price, attributes).
• Module leftovers — clean up tables left behind by uninstalled modules.

Always clean the database after a backup and preferably outside peak hours — these are operations on a live organism.

Modules and customisations — tidying up the code

• Disable what is unused — inactive modules can still load hooks.
• Review overrides — every override is a risk during updates and a potential source of errors; some can be replaced with proper hooks.
• Debug profiler — in developer mode it shows time and query count per hook: the culprits become visible immediately.
• Third-party scripts — load chats, recommendations and ad pixels asynchronously; they often weigh more than the whole theme.
• Updates — PrestaShop 8.x and 9.x include performance fixes; staying on 1.6/1.7 is a cost today, not a saving (see PrestaShop implementation for migrations).

How much does PrestaShop optimisation cost?

If the store also needs bug fixes and development, see PrestaShop help and PrestaShop support. The wider context of building and growing stores is in our e-commerce store development guide.

Frequently asked questions

How much can PrestaShop optimisation gain?

A typical store gains 30–70% in load times after an audit — the biggest wins come from PHP 8.x, Redis, correct images and database cleanup. The effects are also visible in Core Web Vitals and cart abandonment, especially on mobile.

Does optimisation require changing hosting?

Not always — but if the audit shows slow disk I/O, no OPcache or an overloaded shared server, moving to a VPS or dedicated server is often the cheapest big optimisation. Code tuning will not help when infrastructure is the bottleneck.

Can enabling CCC and cache break the store?

Yes — some modules and themes are not compatible with full-page cache, and CCC can break script order. That is why each cache layer is enabled separately, on a copy, and the purchase path is tested: cart, payment, order confirmation.

Are PrestaShop 8 and 9 faster than 1.6 and 1.7?

Yes — newer versions include code improvements and PHP 8.x support, which alone speeds execution by 20–40%. Old versions are also a security risk. Plan a migration as a project: PrestaShop implementation.

How often should the store database be cleaned?

Guest carts and statistics monthly (automatically, after a backup), and a full database review quarterly. For high-traffic stores the stats retention should be short: operational data is not an archive.

Is optimisation a one-off project?

Basic optimisation is a one-off project, but a store lives on: modules, campaigns and products arrive, and each can degrade performance. That is why ongoing care with Core Web Vitals monitoring makes sense — described in PrestaShop support.

Sources and tools

• PageSpeed Insights — Core Web Vitals measurement
• Google Search Central — Core Web Vitals
• PrestaShop DevDocs — performance
• web.dev — images: WebP and lazy loading
• Redis — documentation

👉 Is your PrestaShop store too slow? Start with a performance audit — see how PrestaShop store development works in my offer: audit, server and database optimisation, caching, images and post-launch care. Get in touch via the contact form or at kontakt@informatix.com.pl.

👉 Growing your store and need support? Check PrestaShop help, PrestaShop support and e-commerce integrations.

📖 See also: PrestaShop implementation, PrestaShop API and e-commerce store development.