Luca Cavallini

PrestaShop performance

PrestaShop performance optimization

Slow PrestaShop made fast: queries, caching, the asset pipeline and the server config underneath. Measured before and after — never guessed. Very large catalogues are a specialty.

Work with me → See the work →

A slow shop quietly costs you money: worse conversion, worse ranking, support tickets, abandoned carts. PrestaShop can be fast — even with hundreds of thousands of products — but only when every layer is right, from SQL up to the HTTP response.

I optimize the whole stack, not just one trick. I measure first (real metrics, real load), find what actually hurts, fix it, then measure again. You get numbers, not promises — and a shop that stays fast because the person who tuned it also runs the server.

Scope

What’s included

  • Database & queriesSlow-query analysis, missing indexes, N+1 patterns, schema and MySQL/MariaDB tuning for big catalogues.
  • Caching, end to endPrestaShop cache, OPcache, Redis, full-page and object caching — invalidation done right.
  • Asset pipelineCSS/JS bundling, image optimization, lazy-loading, render-blocking removed — better Core Web Vitals.
  • Server configurationPHP-FPM, Apache/Nginx, HTTP/2, compression and TLS tuned for the actual traffic.
  • Measured resultsBefore/after benchmarks (Lighthouse, real load) so you can see exactly what changed.
  • Module-bloat triageFinding the modules and overrides silently dragging the whole shop down.
Proof

Related work

Server / DevOps Linux server management cPanel/WHM, Proxmox, tuning, backups, monitoring. Built and kept alive. Development PrestaShop development Custom shops, themes and modules on 1.6 → 9 — clean, upgrade-safe code.
FAQ

Questions, answered

My catalogue has hundreds of thousands of products. Can it still be fast?
Yes — that’s exactly my specialty. I run shops with over a million products under management, kept fast under real load. Large catalogues need the right indexing and caching strategy, not magic.
Will you break my shop while optimizing?
No. I work on a staging copy where possible, change one thing at a time, measure, and keep everything reversible. Your live shop stays safe.
Do you only fix the code, or the server too?
Both. Most performance problems live across the boundary between code and server — and I run both, so nothing falls between the cracks.

Tell me what’s not working — or not talking to what.

New build, a system that needs rescuing, an integration, the June 2026 deadline. One developer who builds it and stays to run it. Reply usually within 1–2 business days.