Activez (et réglez) le cache Smarty et le cache HTTP

Le cache Smarty natif de PrestaShop élimine la recompilation des templates à chaque requête ; mal réglé, notamment en mode développement laissé actif en production, il peut multiplier les temps de réponse par trois ou quatre. Couplez-le à un cache HTTP en façade (Varnish, ou simplement le cache navigateur via des en-têtes adaptés dans le .htaccess) pour soulager le serveur sur les pages catalogue à fort trafic.

Paramètres avancés ▸ Performance

Optimisez vos images sans sacrifier la qualité

Convertissez les visuels produits en WebP (voire AVIF), définissez des dimensions exactes pour chaque emplacement (vignette, zoom, mobile) plutôt que de laisser le navigateur redimensionner à la volée, et activez le chargement différé sur tout ce qui se trouve sous la ligne de flottaison. Sur un catalogue de plusieurs milliers de références, ce seul chantier peut réduire le poids des pages de 40 à 60 %.

Désinstallez (vraiment) les modules inutilisés

PrestaShop installe par défaut une trentaine de modules dont une bonne partie ne sera jamais utilisée. Chaque module actif continue de s’accrocher à des hooks et d’exécuter du code à chaque chargement de page. Un audit régulier des hooks actifs permet d’identifier ceux qui plombent réellement le temps de réponse.

Paramètres avancés ▸ Performance ▸ Débogage

Restez sur une version PHP supportée, avec OPcache actif

Les gains entre PHP 7.4 et PHP 8.2 sont loin d’être anecdotiques, particulièrement sur le rendu Smarty et les boucles de catalogue. Lors des migrations PS8/PS9 que je traite régulièrement, le passage à PHP 8.2 associé à un OPcache correctement dimensionné représente souvent le gain de performance le plus visible, sans toucher une ligne de code métier.

Nettoyez et indexez la base de données régulièrement

Les tables de logs, de connexions invitées et de paniers abandonnés grossissent vite et ralentissent les requêtes les plus courantes. Un ANALYZE TABLE périodique, la purge des données obsolètes et la vérification des index sur les tables produit/catégorie évitent que la base ne devienne le vrai goulot d’étranglement, souvent invisible jusqu’à ce que le catalogue dépasse plusieurs dizaines de milliers de références.

Servez les fichiers statiques via un CDN et compressez les réponses

Déporter les images, le CSS et le JS sur un CDN réduit la latence géographique, surtout pour les boutiques qui vendent à l’international. Couplé à la compression Gzip ou Brotli côté serveur, ce réglage améliore directement le LCP sans aucune intervention sur le thème.

Activez la compilation CCC avec prudence

L’option native de combinaison/compression/cache (CCC) regroupe et minifie le CSS et le JS pour réduire le nombre de requêtes. Elle entre cependant souvent en conflit avec certains modules tiers qui injectent leurs propres scripts de façon non standard — à tester systématiquement en pré-production avant activation définitive.

Préférences ▸ Performance ▸ CCC

Maîtrisez les combinaisons produits pour éviter le duplicate content

Chaque déclinaison (taille, couleur) peut générer sa propre URL si la canonisation n’est pas verrouillée correctement, créant un contenu dupliqué qui dilue le référencement en plus d’alourdir le crawl. Vérifiez que chaque combinaison renvoie bien une balise canonique vers la fiche produit principale.

Profilez les hooks et les requêtes lentes avant d’optimiser à l’aveugle

Un profiler (Blackfire, ou simplement les logs de requêtes lentes MySQL) révèle souvent qu’un seul module mal codé est responsable de la majorité du temps de chargement d’une page catégorie. Optimiser au hasard fait perdre du temps ; identifier précisément le hook ou la requête fautive permet de cibler l’effort là où il compte vraiment.

Mettez en place une surveillance active et des sauvegardes automatisées

Un monitoring d’uptime, une alerte sur les erreurs 500 et une sauvegarde automatisée (fichiers et base) ne sont pas des optimisations de vitesse au sens strict, mais ils évitent qu’un incident technique n’annule en une nuit tous les gains accumulés. Une boutique rapide qui tombe en panne reste, pour le client, une boutique qui ne fonctionne pas.