Is your PrestaShop slow?
we speed it up for real.
PrestaShop performance audit and optimisation
LCP > 3s, sluggish cart, product page taking 5s to load: you know you are losing sales, and you know it is fixable. Across the last 12 optimisations, median gain −62% on LCP and +22% organic traffic in 60 days.
Before / after on 3 optimised stores
GSC + Lighthouse + RUM measurements, 60-day rolling window. Not promises, numbers.
The 8 levers we pull
Always in this order, from most immediate to most structural. Each has a measurable, quantified impact in the audit.
CCC (Combine, Compress, Cache) in production mode, Smarty cache in compile_check=off, browser cache via Cache-Control: public, max-age=31536000 headers on versioned assets. Typical impact: −800ms to −1.2s on LCP.
Automatic JPEG/PNG → WebP conversion with fallback, loading="lazy" on every off-viewport image, explicit width/height attributes to prevent layout shift. Impact: −1.5s to −2s on LCP, CLS close to 0.
Review of every active module, identification of duplicate tracking modules (Google, Meta, TikTok), orphan modules never used, chat modules loading 800KB of JS. Clean disable via admin + SQL cleanup of orphan hooks. Impact: −150 to −400ms on TTFB.
Slow query profiling via EXPLAIN and slow_query_log. Adding indexes on ps_product_attribute (id_product, default_on), ps_specific_price (id_product, id_country, from, to), ps_orders (id_customer, date_add). Impact: TTFB cut by 2 to 4× on catalogues > 1000 products.
On PrestaShop 8.x/9.x, activation of Redis object cache (sessions + app cache). On 1.7.x, configuration via defines_custom.inc.php. Impact: −250ms to −500ms on TTFB, essential at peak hours.
Audit of JS injected by modules: tracking scripts set to defer, chat widgets in delayed load after user interaction, duplicate removal (gtag.js loaded 3 times by 3 different modules is classic). INP impact: −150 to −200ms.
Migration of Google Fonts to self-hosting (GDPR-friendly too), <link rel="preload"> on WOFF2 files used above the fold, font-display: swap. Impact: −300ms on FCP, FOIT eliminated.
If TTFB stays > 800ms at peak hours after the 7 previous levers, hosting is the bottleneck. Assisted migration to optimised VPS (Kinsta, WP Engine, SiteGround, Hetzner) or PrestaShop-specialised hosting. Impact: TTFB down to 150-300ms.
What we look at, in this order
Full audit in 4h. Deliverable: PDF report with quantified recommendations and prioritised action plan.
php-fpm.log, Xdebug or Tideways profiling on 3 key pages (home, category, product). Identify time spent in PHP vs SQL vs network.
EXPLAIN on the top 20. Index recommendations specific to your catalogue.
memory_limit, Redis/Memcached presence, HTTP/2, Brotli. If limitations detected: before/after migration comparison.
Pricing stated up-front
Free pre-audit. For the optimisation, you know exactly what it costs before we touch the code.
Pre-audit
- Lighthouse + RUM measurement (LCP, INP, CLS)
- Top 3 levers for your case
- Firm quote with estimated gain in ms
- You decide if we continue
Targeted optimisation
- Lighthouse + RUM measurement before optimisation
- Lever activation (cache, WebP, JS, DB, Redis...)
- After measurement + quantified comparison
- Written report real gain in seconds
- 30-day RUM tracking after going live
Performance maintenance
- 2h of dev/month rollable (Performance plan)
- Daily backups externalised
- Monthly Core Web Vitals tracking
- Progressive optimisations no big cheque
PrestaShop performance — frequently asked questions
ps_product_attribute or ps_specific_price as the catalogue grows, (3) misconfigured Smarty + CCC cache, (4) JPEG/PNG images without WebP or lazy-loading, (5) under-sized shared hosting, (6) no Redis/Memcached, (7) blocking chat/tracking JS, (8) unoptimised custom theme. A single point can cost 2s; stacking them can triple load time.15 min to see where you stand
Free 30-min pre-audit: LCP, INP, CLS, the top 3 levers for you. No commitment, no fluff.