Sur PrestaShop, la vitesse a un impact direct sur les ventes : chaque seconde de chargement en plus fait fuir une partie des visiteurs avant même qu’ils n’aient vu le catalogue, et Google en tient compte dans le classement. Voici les erreurs que je retrouve le plus souvent en intervenant sur des boutiques existantes, dans l’ordre où je les vérifie, avec la façon de les corriger.

D’abord, mesurer

Avant de toucher à quoi que ce soit, il faut savoir où le temps est perdu. Deux mesures suffisent pour commencer :

Sur une copie de la boutique (jamais en production), le mode profilage de PrestaShop détaille le temps passé par chaque module et chaque requête SQL. Il s’active dans config/defines.inc.php :

define('_PS_DEBUG_PROFILING_', true);

1. Le mode debug ou le cache désactivé en production

C’est l’erreur la plus simple à corriger et l’une des plus fréquentes, souvent après une migration ou une intervention technique. Dans Paramètres avancés > Performances, vérifiez que :

2. Trop de modules « au cas où »

Chaque module greffé sur les points d’affichage (hooks) du thème ajoute du code exécuté à chaque chargement de page, même si sa fonctionnalité ne sert presque jamais. Les plus coûteux sont ceux qui s’accrochent à l’en-tête ou au pied de page, car ils s’exécutent sur toutes les pages.

3. Un thème surchargé

Les thèmes premium embarquent des dizaines d’options pensées pour convenir à tout le monde : sliders, animations, carrousels, plusieurs polices, parfois plusieurs bibliothèques JavaScript qui font la même chose. Désactiver ce qui n’est pas utilisé sur votre boutique allège sensiblement chaque page. Si le thème a été modifié directement, sans thème enfant, chaque mise à jour devient risquée : c’est souvent le moment de remettre les modifications au propre.

4. Des images produit trop lourdes

Un catalogue avec des centaines de fiches et des photos envoyées telles quelles par les fournisseurs (souvent plusieurs mégaoctets chacune) alourdit chaque page catégorie. Trois actions :

5. Une base de données qui grossit sans que personne ne le voie

Certaines tables grossissent en silence : statistiques de connexion (ps_connections, ps_guest), pages introuvables (ps_pagenotfound), journaux (ps_log), paniers abandonnés. Après quelques années, elles peuvent peser plus lourd que le catalogue et ralentir le back-office comme le front. Pour repérer les plus grosses :

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 1) AS taille_mo
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY taille_mo DESC
LIMIT 10;

Le nettoyage se fait avec prudence, après une sauvegarde vérifiée (voir la règle des sauvegardes que presque personne ne respecte), et en désactivant si besoin les modules de statistiques qui ne servent pas.

6. Un hébergement pensé pour un site vitrine

PrestaShop est plus gourmand qu’un site vitrine, surtout avec un catalogue conséquent. Points à vérifier avec l’hébergeur :

La check-list

  1. Mesurer le temps de réponse serveur et le score mobile d’une fiche produit et d’une catégorie.
  2. Mode debug désactivé, cache Smarty et CCC activés.
  3. Modules inutilisés désinstallés, hooks d’en-tête et de pied de page vérifiés.
  4. Options inutiles du thème désactivées.
  5. Images redimensionnées, miniatures régénérées, format WebP.
  6. Tables de statistiques et de journaux surveillées et nettoyées après sauvegarde.
  7. PHP récent avec OPcache, CDN pour les fichiers statiques.
  8. Mesurer à nouveau, pour vérifier que chaque correction a eu un effet.

Pour aller plus loin : mon expertise : Développeur PrestaShop freelance · à lire aussi : Migrer sa boutique PrestaShop sans perdre son référencement