PrestaShop starts light, but with a growing catalogue, thirty installed modules, and poorly configured cache, the server starts to struggle. And in a shop, every extra second of loading time means one less sale and one less position on Google.
I handle the system layer: the server, the operating system, and all the services PrestaShop runs on. PrestaShop itself — code, modules, theme, and application updates — is handled by the agency or your development team. My job is to make sure the environment where the store lives is fast, secure, monitored, and available.
I work mainly with agencies and developers who need a systems specialist for their PrestaShop projects without adding one to the payroll, and also directly with e-commerce managers who want a store that holds up. In the background, as an extension of your team.
Where I start: the problems I usually find
Most PrestaShop projects arrive with one of these symptoms:
- The store is slow. High TTFB, product pages and categories that drag, a heavy back office. Often it is not the code: it is a server without cache, an untuned database, or shared hosting that is no longer enough.
- It goes down exactly when it sells the most. Sales, Black Friday, a campaign that works too well… and the server gives up at the worst possible moment.
- A migration or a new server. Hosting change, moving off shared hosting that has become too small, consolidating servers, or switching to a better-sized environment — without losing sales or SEO. (Updating the store itself is coordinated by your team; I prepare and migrate the infrastructure.)
- Security concerns at the system level. Unhardened server, admin folder accessible from any IP, no WAF, no clear backup plan. In e-commerce, that is money and customer data at risk.
If any of those sound familiar, that is where I come in.
How I solve it
I do not sell magic recipes or generic “optimisations”. The approach is always the same: measure, dimension, and tune the specific stack of your store, not the one from a manual.
I start from real data (server metrics, service profiling, traffic logs from past campaigns) to find where the actual bottleneck is before touching anything. From there I tune each service in the stack — web server, PHP, database, cache — for the real load pattern of your store, leave everything documented and reproducible, and stay available for peaks. The idea is to have the infrastructure ready before the campaign, not fighting fires during it. The application runs on top; I make sure it has solid ground beneath its feet.
What is included
This is what I contribute at the system level in a PrestaShop project. You do not need to take all of it: it adapts to what the project needs.
Performance and stack tuning
- Tuning of PHP-FPM and OPcache for the store’s real load pattern (pools, workers, memory) — a critical point in PrestaShop given the number of modules.
- Configuration of the web server (Nginx or Apache) with compression, static cache, and HTTP/2 or HTTP/3.
- Provisioning and tuning of the cache service (Redis / Memcached) that PrestaShop uses as a cache backend.
- Varnish deployed and configured as a cache in front of the store, coordinating with your team on the PrestaShop integration.
- Tuning of MariaDB/MySQL (buffer pool, connections, slow queries) — very sensitive to catalogue size and number of modules.
- Provisioning of the search service (e.g. Elasticsearch) if your store’s module requires it.
- The cron daemon properly configured so that PrestaShop’s scheduled tasks have a solid place to run without crashing the server.
Campaign and peak preparation
- Pre-event load tests to know the server’s real ceiling before the event.
- Resource sizing (vertical and, where applicable, horizontal with load balancing) to handle the peak.
- Contingency plan and reinforced availability (on-call) during the critical window.
Security and hardening
- Server hardening: firewall, fail2ban, IP-restricted admin folder access, permissions, and web server-level headers.
- System security updates: OS, kernel, and stack services kept up to date. (Updates and patches to the PrestaShop store itself are your team’s responsibility; I keep what is underneath secure.)
- WAF in front of the store (Cloudflare, ModSecurity, or others) and bot and scraping mitigation.
- Best practices aligned with PCI-DSS compliance on the infrastructure side.
- Management of TLS certificates and automatic renewals.
Infrastructure migrations
- Hosting or server migrations with no perceptible downtime and no SEO loss.
- Moving off shared hosting to a dedicated or cloud environment that is properly sized.
- Provisioning of equivalent staging and production environments, so your team deploys and tests on a solid base.
- Data and service migration at the system level, with a clear rollback plan if something goes wrong.
Backups and monitoring
- Encrypted, offsite, tested backups (3-2-1 rule): a backup that has never been restored does not count.
- Continuous monitoring of server, services, and availability — so you find out before your client does.