10 Practical Ways to Speed Up Your PrestaShop 9 Store
PrestaShop 9 gives merchants a more modern technical foundation, but store speed still depends heavily on configuration, modules, database design, images, hosting and background jobs.
There is no single checkbox that makes every PrestaShop store fast.
The most effective approach is to identify the largest bottlenecks and fix them in order.
This guide focuses on ten improvements that can produce meaningful results in real stores without relying on vague advice such as “buy better hosting.”
Version note: This article was verified on September 22, 2026. PrestaShop 9.0 recommends PHP 8.4, while PrestaShop 9.1 supports and recommends PHP 8.5. PrestaShop 9 includes native WebP and AVIF support and several front-office performance improvements.
Before You Change Anything: Measure the Store
Before applying optimizations, record a baseline.
Test several different page types:
- homepage;
- category;
- product;
- search;
- cart;
- checkout;
- Back Office product page;
- Back Office order page.
Measure:
- Time to First Byte;
- total page weight;
- number of requests;
- Largest Contentful Paint;
- server response time;
- PHP execution time;
- slow database queries;
- cron duration.
If possible, test while normal background jobs are running.
A store may appear fast when no imports or synchronization jobs are active and slow down dramatically when those tasks start.
The purpose of a baseline is simple: after every meaningful change, measure again.
1. Use the Right PHP Version
One of the easiest checks is the PHP runtime.
The current PrestaShop compatibility table recommends:
- PHP 8.4 for PrestaShop 9.0;
- PHP 8.5 for PrestaShop 9.1.
Modern PHP versions contain performance and engine improvements, but compatibility must be tested.
Do not change production PHP directly.
Create a staging environment and test:
- homepage;
- product pages;
- checkout;
- payment modules;
- shipping modules;
- imports;
- cron jobs;
- CLI commands;
- custom modules.
Check CLI PHP too
A common mistake is verifying only the PHP version used by the website.
Run:
php -v
from the same environment used by cron.
It is possible for:
Web PHP = 8.5
CLI PHP = 8.2
That can create confusing bugs where the shop works in the browser but scheduled commands fail.
Enable OPcache
A production PrestaShop store should normally use OPcache.
OPcache keeps compiled PHP bytecode in memory instead of parsing and compiling PHP files repeatedly.
Check that it is actually enabled and monitor whether the cache is large enough for:
- PrestaShop core;
- Symfony;
- modules;
- custom code.
Do not assume the server default is optimal.
2. Find the Slowest Modules
The number of installed modules is not the main performance metric.
One badly designed module can be slower than fifty good ones.
A module can slow the store if it:
- executes expensive SQL on every page;
- makes remote API requests;
- loads large datasets;
- attaches heavy logic to global hooks;
- recalculates data that could be cached;
- performs file operations during front-office rendering.
Use a controlled test
On staging:
- measure a slow page;
- disable one non-critical module;
- measure again;
- repeat.
If page time drops from:
1.8 seconds
to:
600 milliseconds
after disabling one module, you have found a high-value optimization target.
Do not simply remove the module if it is important.
Profile its code and find the expensive operation.
3. Optimize Database Queries
Large PrestaShop stores are often database-bound.
A query that takes 20 ms with 1,000 products may take several seconds after years of catalog growth.
Enable the database slow-query log for a controlled period.
Look for queries related to:
- product listings;
- category pages;
- search;
- Back Office grids;
- stock synchronization;
- imports;
- feeds.
Then use:
EXPLAIN
to inspect how the database executes the query.
Watch for full scans
A module may repeatedly run something like:
SELECT *
FROM ps_custom_queue
WHERE status = 'pending'
AND id_shop = 2
ORDER BY id_queue
LIMIT 100;
If the table contains millions of rows and has no useful index, the database may scan far more data than necessary.
An appropriate composite index might be:
(id_shop, status, id_queue)
But never add indexes blindly.
The correct index depends on the real query and data distribution.
Avoid redundant writes
Updating a product when nothing has changed creates unnecessary:
- SQL writes;
- index maintenance;
- cache invalidation;
- hook execution.
Supplier integrations should use timestamps, hashes or change tracking when possible.
4. Use WebP and AVIF Correctly
PrestaShop 9 introduced native support for modern image formats including:
- WebP;
- AVIF.
These formats can significantly reduce transferred image bytes.
But simply enabling WebP or AVIF does not guarantee a fast store.
You should also check:
- source image dimensions;
- generated image types;
- compression quality;
- responsive image sizes;
- lazy loading;
- CDN behavior.
Do not load a huge image into a small card
If a category product card is 320 pixels wide, downloading a 2000-pixel image is wasteful.
The browser may display it at 320 pixels, but the customer still pays the download and decode cost.
Use a suitable generated size.
Audit image types
Themes and modules can create many thumbnail sizes.
Imagine:
80,000 products
× 4 photos
× 10 image types
That can produce:
3,200,000 generated images
If the theme uses only six image types, the others may be unnecessary.
Do not delete them until you verify that:
- modules;
- feeds;
- emails;
- marketplaces;
do not use them.
5. Move Heavy Work to CLI and Cron
A browser request is a poor place to process 100,000 products.
Long operations may hit:
- proxy timeouts;
- PHP execution limits;
- browser disconnects;
- memory limits.
Use CLI, cron or queue workers for:
- supplier imports;
- image processing;
- feed generation;
- price updates;
- stock synchronization;
- bulk maintenance.
Batch the work
Instead of:
Process all 100,000 products
use:
Claim 200 records
Process
Save progress
Exit or continue
This makes the job easier to:
- resume;
- monitor;
- retry;
- stop safely.
Add locking
If cron runs every minute and the previous process is still active, a second worker may start.
Use locks or leases.
Duplicate heavy jobs can double resource consumption and cause inconsistent data.
6. Cache Static Assets Aggressively
CSS, JavaScript, fonts and images change far less frequently than HTML.
Configure useful browser cache headers.
Static assets are good candidates for long cache lifetimes when filenames or URLs change on deployment.
Examples:
CSS
JavaScript
JPG
PNG
WebP
AVIF
fonts
This reduces repeat downloads and server traffic.
Use a CDN when appropriate
A CDN can improve static delivery for customers far from the origin server.
It can also reduce load on the web server.
However, a CDN cannot fix slow PHP.
If Time to First Byte is already two seconds before the browser starts downloading images, optimize the application first.
7. Be Careful with Full-Page Cache
Full-page caching sounds attractive because it can bypass much of PHP.
But ecommerce pages are often personalized.
Output can differ by:
- customer;
- customer group;
- currency;
- country;
- language;
- tax rules;
- cart contents;
- shop.
A badly designed page cache can show the wrong:
- price;
- cart;
- discount;
- customer block.
Cache aggressively only when the cache key correctly represents every important context.
For many stores, static asset caching and application-level caching are safer places to start.
8. Remove Unused Modules and Old Code
Unused code increases maintenance complexity.
Old modules may still:
- register hooks;
- load autoloaders;
- leave cron jobs active;
- create database queries;
- introduce PHP compatibility problems.
Audit the production installation.
For every module, ask:
- Is it used?
- Who owns it?
- When was it last updated?
- Does it have a scheduled task?
- Does it store business data?
- Is there a replacement?
Remove obsolete modules carefully.
Do not delete a module before checking whether another system depends on its data.
Review overrides too
An old override may replace a core method with code written for an earlier PrestaShop generation.
That can create both performance and compatibility problems.
9. Control PHP-FPM Concurrency
More PHP workers are not always better.
Suppose:
Average busy worker = 180 MB
If:
pm.max_children = 40
then potential worker memory is:
7.2 GB
before counting:
- MySQL;
- Redis;
- Nginx;
- operating system;
- CLI jobs.
On an 8 GB server, that is risky.
When memory is exhausted, Linux may swap or kill processes, causing severe latency.
Measure worker memory under realistic traffic and set a safe limit.
The goal is enough concurrency without destroying memory headroom.
10. Monitor Performance Continuously
Optimization is not a one-time project.
Performance changes when:
- catalog grows;
- modules update;
- theme changes;
- marketing traffic increases;
- suppliers add more products;
- cron jobs become longer.
Monitor:
- response time;
- HTTP 5xx rate;
- CPU;
- RAM;
- PHP-FPM queue;
- database connections;
- slow queries;
- disk I/O;
- free disk space;
- inode usage;
- queue backlog;
- cron duration.
Monitor business jobs too
A product import taking 20 minutes today and 90 minutes next month is a performance regression even if the storefront still looks fast.
Track job duration and throughput.
Quick 30-Minute PrestaShop Speed Audit
If you only have half an hour, do this:
1. Check PHP
Confirm:
php -v
and the web PHP version.
2. Confirm OPcache
Make sure it is enabled.
3. Measure three pages
Record:
- homepage;
- category;
- product.
4. Inspect slow SQL
Look at the slowest database queries.
5. Check image sizes
Compare rendered dimensions with transferred dimensions.
6. Review active cron jobs
Find jobs running during busy hours.
7. Check server pressure
Inspect:
- RAM;
- CPU;
- disk;
- I/O wait.
This short audit usually points to the next useful action.
Example: Fixing a Slow Category Page
Suppose a category page takes:
2.1 seconds TTFB
Profiling shows:
Custom filter module: 950 ms
Database query: 600 ms
Other PHP: 350 ms
Remaining work: 200 ms
Instead of buying a larger server, start with the custom filter module.
The query may lack an index.
After adding the correct index:
Database query: 80 ms
Then cache filter metadata:
Filter module: 150 ms
New TTFB:
780 ms
That is a much more efficient result than blindly adding hardware.
Example: Fixing Import-Related Slowdowns
Imagine the storefront is fast most of the day but slow between 02:00 and 04:00.
The supplier import performs:
full product scan
full image download
full stock update
full price update
for every product.
A better design separates work:
Supplier scan
↓
Detect changed records
↓
Product update queue
├── price worker
├── stock worker
└── image worker
Now unchanged products are skipped.
The image worker can be limited to one or two processes.
Stock updates can remain frequent.
This reduces server peaks and shortens the total work.
What Not to Do
Do not install every “speed module” you find
Performance modules can conflict or cache the wrong content.
Do not clear every cache every minute
Constant invalidation removes the benefit of caching.
Do not add random database indexes
Indexes should support real queries.
Do not increase memory limits indefinitely
Fix memory-heavy algorithms.
Do not run five image workers because one is slow
Check whether CPU or disk is already saturated.
Do not benchmark only the homepage
Category, product, checkout and Back Office workloads are different.
PrestaShop 9 Speed Checklist
- Supported and appropriate PHP version
- OPcache enabled
- OPcache sized correctly
- PHP-FPM concurrency measured
- Slow database queries reviewed
- Indexes validated with
EXPLAIN - Expensive modules identified
- Remote API calls removed from hot paths
- WebP/AVIF evaluated
- Image dimensions correct
- Unused image types removed
- Static assets cached
- CDN considered
- Heavy jobs use CLI
- Cron jobs use locks
- Imports are batched
- Unchanged products skipped
- Queue backlog monitored
- Disk and inode usage monitored
- Performance baseline retained
Frequently Asked Questions
Why is my PrestaShop 9 store slow?
Common causes include slow modules, inefficient SQL, oversized images, too many PHP workers, overloaded hosting and background jobs competing with customer traffic.
What should I optimize first?
The slowest measured component. Do not choose the fix before measuring the bottleneck.
Does PrestaShop 9 support WebP?
Yes. PrestaShop 9 includes native WebP support.
Does PrestaShop 9 support AVIF?
Yes. AVIF support is also native in PrestaShop 9.
Should I use PHP 8.5?
PrestaShop 9.1 supports and currently recommends PHP 8.5. PrestaShop 9.0 recommends PHP 8.4. Test modules before switching.
Does Redis improve PrestaShop speed?
It can improve particular workloads, but it does not automatically repair slow SQL or inefficient modules.
Should I upgrade the server first?
Only when monitoring shows that server resources are the actual limit. Code and database fixes often produce larger gains.
How can I speed up a large product import?
Stream source data, process in batches, skip unchanged records, separate product updates from images and use bounded worker concurrency.