Optimisation PrestaShop : base de données, images et performances

Publié le — PrestaShop

Une boutique PrestaShop qui ralentit, c'est des clients qui partent. Chaque seconde de chargement supplémentaire réduit le taux de conversion. Les causes sont souvent les mêmes : une base de données qui grossit sans être nettoyée, des images non optimisées, des modules trop nombreux et un cache mal configuré. Ce guide couvre les optimisations concrètes, du nettoyage SQL à la compression d'images.

Nettoyage de la base de données

Avec le temps, une boutique PrestaShop accumule des milliers d'enregistrements inutiles : logs d'erreurs, connexions visiteurs, statistiques anciennes, paniers abandonnés, caches obsolètes. Ces données s'entassent dans MySQL et finissent par ralentir les requêtes, alourdir les sauvegardes et consommer les ressources serveur.

Les tables à nettoyer en priorité

Ces tables peuvent être vidées régulièrement sans impact sur le fonctionnement de la boutique :

  • ps_log — Logs d'erreurs PHP et PrestaShop. Peut contenir des millions de lignes sur une boutique active. Recommandation : purger les données de plus de 3 mois.
  • ps_connections / ps_connections_source / ps_connections_page — Toutes les connexions au site, y compris les robots d'indexation. Données statistiques non essentielles.
  • ps_guest — Informations sur les visiteurs non enregistrés. Se vide sans conséquence.
  • ps_statssearch — Mots-clés recherchés par les clients. Utile pour l'analyse mais vidable si non exploité.
  • ps_cart — Paniers abandonnés. Peut contenir des millions d'entrées sur une boutique à fort trafic. Ne supprimer que les paniers de plus de 30 jours sans commande associée.
  • ps_cart_rule_combination — Sur les versions antérieures à PrestaShop 1.7.8, cette table peut atteindre plusieurs Go si le nombre de règles paniers est important.
  • ps_mail — Historique des emails envoyés. Peut être vidée si les emails sont archivés ailleurs.

Requêtes SQL de nettoyage

Ces requêtes suppriment les données inutiles. Toujours faire une sauvegarde complète avant d'exécuter ces commandes.

-- Logs (garder les 30 derniers jours)
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Connexions (tout vider)
TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_connections_source;
TRUNCATE TABLE ps_connections_page;

-- Visiteurs non enregistrés (garder ceux avec un panier actif)
DELETE g FROM ps_guest g
LEFT JOIN ps_cart c ON g.id_guest = c.id_guest
WHERE c.id_cart IS NULL;

-- Statistiques de recherche
TRUNCATE TABLE ps_statssearch;

-- Paniers abandonnés de plus de 30 jours (sans commande)
-- 1. Supprimer les produits liés aux paniers orphelins
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON c.id_cart = cp.id_cart
WHERE c.id_cart NOT IN (SELECT id_cart FROM ps_orders)
AND c.date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- 2. Supprimer les paniers eux-mêmes
DELETE FROM ps_cart WHERE id_cart NOT IN (SELECT id_cart FROM ps_orders)
AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Récupérer l'espace après nettoyage
OPTIMIZE TABLE ps_log, ps_connections, ps_guest, ps_cart, ps_cart_product;

La commande OPTIMIZE TABLE récupère l'espace libéré et défragmente les fichiers de données. Le gain estimé est de 10 à 30 % d'amélioration sur les requêtes SQL après un nettoyage complet.

Automatiser le nettoyage

Un nettoyage manuel mensuel est suffisant pour les petites boutiques. Pour les boutiques à fort trafic, une tâche CRON hebdomadaire ou quotidienne est recommandée. Plusieurs modules facilitent cette automatisation :

  • PrestaShop Cleaner — Module officiel gratuit. Purge des paniers, correction d'intégrité, nettoyage des coupons expirés.
  • DB Cleaner — Module officiel pour un nettoyage ciblé des tables volumineuses.
  • Database Cleanup (mypresta.rocks) — Suppression des paniers abandonnés, logs, stats de recherche, guests expirés et données orphelines.

Optimisation des images

Les images représentent souvent 60 à 80 % du poids total d'une page produit. Une image produit non optimisée peut peser 1 à 2 Mo, alors qu'une version compressée en WebP ne pèse que 50 à 100 Ko — pour une qualité visuelle identique.

Formats modernes : WebP et AVIF

La cascade de formats recommandée pour les images PrestaShop en 2026 :

  1. AVIF — Meilleure compression, qualité supérieure. Supporté nativement depuis PrestaShop 8.2 et PHP 8.1+. Réduit le poids de 50 à 70 % par rapport au JPEG.
  2. WebP — Bon compromis compression/compatibilité. Supporté nativement depuis PrestaShop 8.1. Réduit le poids de 25 à 35 % par rapport au JPEG.
  3. JPEG/PNG — Fallback pour les navigateurs anciens.

Utilisez l'élément <picture> avec des <source> pour servir automatiquement le meilleur format au navigateur :

<picture>
    <source srcset="image.avif" type="image/avif">
    <source srcset="image.webp" type="image/webp">
    <img src="image.jpg" alt="Description" loading="lazy" width="800" height="600">
</picture>

Lazy loading

Le lazy loading retarde le chargement des images hors écran. Le navigateur ne télécharge l'image que lorsqu'elle est sur le point d'apparaître dans le viewport. C'est une optimisation majeure pour les pages catégories avec des dizaines de produits.

  • Utiliser l'attribut natif loading="lazy" sur toutes les images sauf la première (LCP)
  • Toujours spécifier width et height pour éviter le layout shift (CLS)
  • Ne pas mettre loading="lazy" sur l'image principale du produit (Largest Contentful Paint)

Bonnes pratiques images

  • Dimensionner avant upload — Une image de 4000×4000px affichée dans un conteneur de 800px gaspille de la bande passante. Redimensionner à la taille maximale d'affichage.
  • Compresser avant upload — TinyPNG, ImageOptim ou Squoosh pour la compression avant import dans PrestaShop.
  • Utiliser srcset — Servir des images adaptées à la taille de l'écran (mobile, tablette, desktop).
  • Alt text sur chaque image produit — Améliore le SEO et l'accessibilité.

Optimisation du cache

Le cache évite de recalculer les mêmes données à chaque visite. PrestaShop propose plusieurs niveaux de cache :

  • Cache Smarty / Twig — En production, activer "Jamais recompiler les templates". En mode "Si les fichiers ont été modifiés", Smarty vérifie chaque fichier à chaque requête, ce qui génère beaucoup d'I/O inutiles.
  • CCC (Combine, Compress, Cache) — Combine les fichiers CSS et JavaScript en un seul fichier, les minifie et les met en cache. Réduit le nombre de requêtes HTTP.
  • Cache objet (Redis / Memcached) — Stocke en mémoire les résultats de requêtes SQL fréquentes. Particulièrement efficace pour les pages catégories et les blocs de navigation.
  • Cache navigateur — Headers Cache-Control et Expires pour les ressources statiques (images, CSS, JS, polices). Les visiteurs récurrents ne retéléchargent pas les fichiers inchangés.
Niveaux de cache PrestaShop Schéma montrant les 4 couches de cache d'une boutique PrestaShop, de la requête utilisateur à la réponse serveur : cache navigateur (CSS/JS/images), cache objet Redis/Memcached (requêtes SQL), OPcache (bytecode PHP), et cache template Smarty/Twig (HTML compilé). Requête utilisateur Navigateur Cache-Control CSS, JS, images Expires: 1 an Objet Redis / Memcached Requêtes SQL En mémoire OPcache Bytecode PHP compilé Pas de recompil. Template Smarty / Twig HTML compilé Ne pas recompiler Requête → chaque couche intercepte avant d'atteindre la suivante → moins de travail serveur
Les 4 niveaux de cache PrestaShop : chaque couche intercepte la requête et évite de solliciter la suivante.

Optimisation PHP et serveur

  • PHP 8.1+ obligatoire — Gain de 20 % en vitesse brute par rapport à PHP 7.4. PrestaShop 9.1 supporte PHP 8.5.
  • OPcache activé — Met en cache le bytecode PHP. Réduit drastiquement le temps d'exécution des scripts.
  • MySQL 8.0+ ou MariaDB 10.6+ — Optimisations du moteur de requêtes, meilleure gestion des index.
  • Compression Gzip / Brotli — Compresse les fichiers texte (HTML, CSS, JS) avant transfert. Brotli offre 15 à 20 % de compression supplémentaire par rapport à Gzip.

Audit des modules

Les modules sont souvent la première cause de lenteur sur PrestaShop. Un seul module mal codé peut annuler toutes les autres optimisations :

  • Désactiver les modules inutilisés — Chaque module actif charge ses CSS, JS et exécute des requêtes SQL, même sur les pages où il n'est pas utilisé.
  • Supprimer les modules désinstallés — La désinstallation ne supprime pas toujours les tables et données résiduelles en base.
  • Auditer l'impact de chaque module — Utiliser le mode debug de PrestaShop ou le profiler Symfony pour identifier les modules qui allongent le temps de réponse.
  • Préférer les modules natifs — Les modules PrestaShop officiels sont généralement mieux optimisés que les modules tiers.

Core Web Vitals et SEO

Google utilise les Core Web Vitals comme facteur de classement. Les seuils à respecter :

  • LCP (Largest Contentful Paint) — Moins de 2,5 secondes. L'image principale du produit ou la bannière est souvent le LCP. Ne pas la lazy-loader.
  • INP (Interaction to Next Paint) — Moins de 200 ms. Réduire le JavaScript bloquant et les scripts tiers.
  • CLS (Cumulative Layout Shift) — Moins de 0,1. Spécifier width et height sur toutes les images et iframes.

Un site éco-conçu est naturellement performant : DOM léger, requêtes minimales, images optimisées — les mêmes fondamentaux que les Core Web Vitals.

Questions fréquentes

Quelles tables PrestaShop peut-on vider sans risque ?

Les tables de statistiques et de logs peuvent être vidées sans impact sur le fonctionnement de la boutique : ps_log, ps_connections, ps_connections_source, ps_connections_page, ps_guest, ps_statssearch. En revanche, ne jamais toucher aux tables ps_orders, ps_customer ou ps_product sans sauvegarde préalable.

Quel format d'image utiliser pour PrestaShop en 2026 ?

La cascade recommandée est AVIF (meilleure compression) → WebP (compatibilité large) → JPEG/PNG (fallback). PrestaShop 8.1+ supporte nativement le WebP, et PrestaShop 8.2+ supporte l'AVIF. Utilisez l'élément <picture> avec <source> pour servir le meilleur format au navigateur.

À quelle fréquence faut-il nettoyer la base de données PrestaShop ?

Un nettoyage mensuel est recommandé pour les tables de logs, connexions et paniers abandonnés. Pour les boutiques à fort trafic, un nettoyage hebdomadaire automatisé via une tâche CRON est préférable. Chaque nettoyage peut libérer plusieurs Go et améliorer les requêtes SQL de 10 à 30 %.

Les modules ralentissent-ils PrestaShop ?

Oui, les modules sont souvent la première cause de lenteur. Chaque module actif peut charger ses propres fichiers CSS, JavaScript et exécuter des requêtes SQL supplémentaires, même sur les pages où il n'est pas utilisé. Désactivez et supprimez les modules inutilisés, et auditez régulièrement l'impact de chaque module sur les temps de chargement.

Top