Quand un client arrive en disant "mon PrestaShop est lent, qu'est-ce qu'on fait", la première chose à dire honnêtement est que PrestaShop n'est presque jamais lent par nature. Il est lent par configuration, par accumulation de modules, par hébergement bas de gamme, par optimisations sautées. Les sites PrestaShop bien configurés sont rapides ; ils sont rares parce que la chaîne d'optimisation est sous-estimée. Ce papier décrit ce qu'on fait vraiment quand un client arrive avec un Lighthouse à 28 et veut passer au vert. Pour le contexte business, voyez notre playbook e-commerce Maroc 2026.
D'abord, la photo de l'avant
Avant de toucher quoi que ce soit, on capture l'état initial. Cinq pages clés : accueil, catégorie principale, fiche produit best-seller, panier, checkout. Sur chaque page, on relève TTFB, LCP, INP, CLS via PageSpeed Insights et WebPageTest. On regarde aussi le rapport Core Web Vitals dans Search Console qui donne la donnée terrain CrUX.
Cette photo est plus importante qu'elle n'en a l'air. Sans elle, on ne sait pas si l'optimisation a marché ou si on a juste cru qu'elle marchait. La majorité des "optimisations" qu'on voit chez des concurrents reposent sur Lighthouse desktop pris à un instant t — un outil qui simule, qui ne reflète pas la réalité utilisateur, et qui peut donner des scores totalement différents d'un test à l'autre. CrUX sur P75 mobile sur 28 jours est le seul indicateur qui compte pour le ranking.
Le levier le plus rentable : PHP
Quand on regarde le serveur d'un PrestaShop lent, dans 60 % des cas la cause principale est PHP. Soit la version est ancienne (PHP 7 abandonné par la communauté), soit OPcache n'est pas activé, soit OPcache est mal configuré.
Migrer vers PHP 8.2 ou 8.3 avec OPcache correctement configuré est l'optimisation la plus rentable du marché. Le travail consiste à :
; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
realpath_cache_size=4096K
realpath_cache_ttl=600
Sur les stacks anciennes, le gain TTFB est typiquement de 30 à 50 %, parfois plus. Sans aucun changement applicatif, sans aucun module à modifier. C'est l'investissement à privilégier en sprint 1 d'une mission d'optimisation.
L'objection classique : "mais mes modules ne sont pas compatibles PHP 8". En 2026, la majorité des modules sérieusement maintenus le sont. Les modules incompatibles sont presque toujours des modules abandonnés qu'il faudrait remplacer ou supprimer. La migration PHP est aussi l'occasion de faire le ménage.
Le mode CCC et le nettoyage des modules
PrestaShop intègre nativement un mode CCC (Combine, Compress, Cache) pour CSS et JavaScript. Il faut l'activer dans Paramètres avancés > Performance, en même temps que le cache Smarty. Cela coûte zéro et donne des gains mesurables sur le poids des pages.
Le ménage des modules est plus délicat et plus rentable. Sur les sites que nous reprenons, nous trouvons fréquemment 50 à 80 modules actifs, dont 20 à 40 ne servent à rien — soit parce qu'ils ont été installés "au cas où" et jamais utilisés, soit parce qu'ils ont été remplacés par d'autres modules sans que les anciens soient désinstallés. Chaque module actif coûte du PHP, des requêtes DB, parfois des hooks lourds qui s'exécutent sur chaque page.
Notre règle de pouce : un site PrestaShop sérieux a entre 15 et 25 modules actifs, dont la majorité officiels ou maintenus par des éditeurs reconnus. Au-delà, c'est suspect ; en deçà, c'est exceptionnel. Faire ce ménage avec discernement (en testant après chaque désactivation) donne souvent un gain Lighthouse de 5 à 15 points.
Varnish devant le front
Sur les sites PrestaShop avec un trafic significatif, mettre Varnish en reverse proxy devant le serveur applicatif est l'étape qui transforme la performance. Le pattern type :
[Cloudflare] → [Nginx 80/443] → [Varnish 6081] → [Nginx interne 8080] → [PHP-FPM]
Varnish met en cache les pages publiques (catégories, fiches produit) et bypasse les pages personnalisées (panier, checkout, mon compte). Une VCL minimaliste pour PrestaShop ressemble à :
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
if (req.url ~ "^/(panier|checkout|mon-compte|admin)") {
return (pass);
}
if (req.http.Cookie ~ "PrestaShop-") {
return (pass);
}
unset req.http.Cookie;
return (hash);
}
sub vcl_backend_response {
set beresp.ttl = 1h;
set beresp.grace = 6h;
}
Cette VCL est un point de départ. Elle se précise selon vos modules — un module qui injecte des cookies tiers ou qui personnalise des blocs front pour chaque session demandera des règles supplémentaires. Mal configuré, Varnish peut servir une page d'un client à un autre client, ou casser le panier. Bien configuré, il fait passer le TTFB sur catégorie de 1000 ms à 50 ms.
Redis pour la session et le cache d'objets PrestaShop complète Varnish efficacement. Configurer PrestaShop pour utiliser Redis comme cache (Paramètres avancés > Performance > Cache) et la session via la directive PHP session.save_handler=redis réduit la pression sur la base de données.
Les images, levier #1 sur LCP
Sur la majorité des sites PrestaShop, le LCP (Largest Contentful Paint) est dominé par l'image principale du produit ou du carrousel d'accueil. C'est donc le point où concentrer l'effort. Bonne pratique :
<picture>
<source type="image/avif" srcset="/img/p/1/2/12-large_default.avif">
<source type="image/webp" srcset="/img/p/1/2/12-large_default.webp">
<img src="/img/p/1/2/12-large_default.jpg"
width="600" height="600"
alt="Nom du produit"
fetchpriority="high"
loading="eager">
</picture>
Quatre détails comptent. La conversion AVIF/WebP via module ou pipeline serveur réduit le poids de 30 à 70 % par rapport au JPEG. Les dimensions explicites width/height bloquent le CLS — sans cela, l'image redimensionne le layout au chargement et le score chute. Le fetchpriority="high" sur l'image principale au-dessus de la ligne de flottaison indique au navigateur de la charger en priorité. Le loading="lazy" sur les autres images du flux évite le download inutile.
Sur les fiches produits, le gain LCP attendu après cette chaîne est typiquement de 1 à 2 secondes, c'est-à-dire le passage de "Poor" à "Good" sur cette métrique seule.
Le JavaScript, levier #1 sur INP
L'INP (Interaction to Next Paint) est devenu une métrique officielle Core Web Vitals. Elle mesure la réactivité de la page aux interactions utilisateur — clic sur un menu, ajout au panier, ouverture d'un filtre. Sur PrestaShop, le coupable principal de l'INP est presque toujours le JavaScript des modules tiers : tag manager, scripts marketing, popups, chat embarqué.
L'audit consiste à lister les scripts tiers chargés sur chaque page, à se demander honnêtement si chacun est nécessaire, à mettre defer ou async sur les non-critiques, à charger les modules de chat et de popup en idle callback après interaction. Sur un site avec un tag manager mal géré, on a vu l'INP P75 passer de 480 ms à 130 ms après ce travail seul.
Le CSS et la stabilité visuelle
Le CLS (Cumulative Layout Shift) ne vient presque jamais du CSS lui-même mais de trois sources : images sans dimensions explicites (déjà traité), polices web qui s'affichent après le chargement et provoquent un re-layout, bannières et popups qui s'injectent en haut de page sans réservation d'espace.
Les corrections : font-display: optional ou swap sur les polices web, préchargement des polices critiques via <link rel="preload" as="font">, self-hosting des polices au lieu de Google Fonts CDN, hauteur réservée pour les bandeaux de consentement et les popups marketing.
Le SEO technique, complément non négociable
Une fois la performance stabilisée, le SEO technique devient le levier d'acquisition. Sur PrestaShop, cinq points méritent attention.
Les URLs et canonicals doivent être propres : friendly URL activé dans Préférences > SEO et URLs, URL canonique cohérente entre <head>, og:url et sitemap, gestion stricte des paramètres (noindex sur tri de produits ou pagination si nécessaire).
Le sitemap XML doit être segmenté : sitemap général, sitemap par catégorie, sitemap des fiches produits. Maximum 50 000 URLs par fichier. Soumis dans Search Console.
Le hreflang sur sites multilingues : déclaration cohérente entre <head> ET sitemap, codes pays valides (fr-MA, en-US, ar-MA), pas d'erreur Search Console. Une erreur invalide la déclaration entière sur la page.
Les schémas JSON-LD sur fiche produit (Product avec Offer et AggregateRating si avis), sur catégorie (ItemList), au niveau global (Organization, WebSite). Sans ces schémas, vous perdez la concurrence dans les SERPs enrichies.
Le robots.txt strict : bloquer panier, compte client, recherche interne, paramètres de tri. Ouvrir explicitement ressources statiques (CSS, JS, images).
Un cas réel avant/après
E-commerce mode mid-market à Sidi Maarouf, 1 800 SKU, hébergement Hetzner Cloud, mission d'optimisation de 6 jours-homme dev sur 4 semaines. Stack initiale : PHP 7.4, pas d'OPcache configuré, pas de Varnish, 47 modules actifs dont 23 inutilisés, images JPEG sans optimisation, thème classique.
Travail réalisé : migration PHP 8.2 + OPcache, ménage de 23 modules, activation CCC, mise en place Varnish + Redis, conversion AVIF/WebP automatique, audit JavaScript et defer/async sur 8 scripts tiers, ajout fetchpriority sur images principales, mise en place Cloudflare devant Varnish.
| Métrique | Avant | Après |
|---|---|---|
| TTFB catégorie | 1 080 ms | 180 ms |
| LCP fiche produit | 4,1 s | 1,9 s |
| INP P75 | 290 ms | 140 ms |
| CLS | 0,17 | 0,03 |
| Lighthouse mobile | 38 | 89 |
| Conversion organique | 0,8 % | 1,4 % |
ROI mesurable en 6 semaines via baisse du taux de rebond et hausse de conversion organique. Ce gain n'est pas exceptionnel ; il est reproductible quand la chaîne est suivie dans le bon ordre.
Erreurs fréquentes qu'on voit chez les concurrents
Installer 5 modules de cache différents qui se neutralisent. Un seul module CCC natif plus Varnish externe suffit.
Activer un module Varnish sans lire ni adapter la VCL. La VCL générée par défaut casse souvent le panier ou le checkout.
Optimiser les images sans bloquer width/height. Gain LCP, perte CLS catastrophique.
Configurer hreflang avec des codes pays inexistants. Search Console ignore la déclaration entière.
Mesurer Lighthouse Desktop comme indicateur principal. La réalité ranking est sur mobile P75 dans CrUX.
Pour aller plus loin
Si vous avez un PrestaShop à optimiser ou un audit à mener avant de signer une refonte, contactez Eurastech. Voir aussi notre playbook e-commerce Maroc 2026 et le focus SEO e-commerce Maroc, 15 leviers.