Quand une boutique PrestaShop ralentit avec les années, on accuse l'hébergement. Bien souvent, le temps se perd dans la base de données MySQL : des tables qui ont grossi sans que personne ne les vide, des requêtes que plus rien n'accélère, un réglage hérité d'une vieille version. Voici où regarder, ce que l'on peut nettoyer sans risque, et ce qu'il ne faut surtout pas toucher.
Avant toute chose : sauvegarder
Tout ce qui suit modifie la base. Avant la moindre manipulation, faites un export complet de la base de données et rangez-le hors du serveur. Mieux encore, travaillez d'abord sur une copie de la boutique : on y mesure le gain, et on ne touche à la vraie base qu'une fois la méthode validée.
Les tables qui grossissent toutes seules
PrestaShop garde des traces de chaque visite, de chaque recherche et de chaque panier. Sur une boutique de quelques années, certaines tables dépassent largement le catalogue lui-même. Les noms ci-dessous utilisent le préfixe par défaut, ps_, qui peut être différent chez vous :
- ps_connections, ps_connections_page et ps_connections_source : une ligne par visite et par page vue, conservée indéfiniment par défaut ;
- ps_guest : un enregistrement par visiteur non connecté ;
- ps_cart : tous les paniers, y compris ceux abandonnés depuis des années ;
- ps_pagenotfound et ps_statssearch : les pages introuvables et les recherches internes enregistrées par les modules de statistiques ;
- ps_log et ps_mail : le journal du back-office et la liste des e-mails envoyés.
Ces données servent aux statistiques. Vider les visites de plus d'un an ne gêne en général personne, mais vérifiez d'abord que vous ne vous en servez pas, et ne supprimez jamais un panier lié à une commande : la commande en a besoin.
Nettoyer sans casser
Il existe un module de nettoyage, « PrestaShop Cleaner », qui purge les données techniques inutiles et vérifie la cohérence de la base. Il faut le manier avec prudence : il propose aussi de supprimer le catalogue, les commandes ou les clients, des fonctions pensées pour vider une boutique de démonstration, et qui sont irréversibles sur une vraie boutique. N'utilisez que le nettoyage des données techniques, et uniquement après sauvegarde.
Pour les tables de statistiques, je préfère une purge datée, qui ne garde par exemple que les douze derniers mois, et qui peut être relancée chaque mois. Une purge faite une fois puis oubliée revient au même point deux ans plus tard.
Trouver les requêtes lentes
Le nettoyage soulage, mais la vraie lenteur vient souvent d'une poignée de requêtes. MySQL sait les repérer : le journal des requêtes lentes (« slow query log ») enregistre toutes celles qui dépassent un temps donné, par exemple une seconde. Une fois activé quelques jours, il désigne les coupables sans discussion. Les plus fréquents :
- la recherche à facettes, c'est-à-dire les filtres de couleur, de taille ou de prix des catégories, sur un gros catalogue dont l'index de filtres n'a pas été reconstruit ;
- un module qui recalcule à chaque page un total ou une liste qu'il pourrait stocker ;
- des tables sans index ajoutées par un module, qui obligent MySQL à tout relire à chaque requête.
Activer ce journal demande un accès au serveur, ou une demande à l'hébergeur. Sur un hébergement mutualisé, c'est parfois impossible : on mesure alors depuis la boutique, page par page.
Les réglages hérités des anciennes versions
Le moteur de stockage
Les boutiques installées il y a longtemps ont parfois des tables en MyISAM, l'ancien moteur de MySQL. Il verrouille une table entière à chaque écriture : pendant qu'un client valide sa commande, les autres attendent. Les versions récentes de PrestaShop utilisent InnoDB, qui ne verrouille que les lignes concernées. La conversion est une opération courte, mais elle se prépare : sauvegarde, puis conversion table par table, sur la copie d'abord.
La version de MySQL
PrestaShop 9 demande au minimum MySQL 5.7 ou MariaDB 10.2, et une version récente est recommandée. Si votre hébergeur fournit encore une version plus ancienne, c'est un point à régler avant toute montée de version de PrestaShop.
Dans quel ordre s'y prendre
- sauvegarder la base, et monter une copie de la boutique ;
- mesurer le temps de réponse des pages les plus visitées ;
- purger les tables de statistiques au-delà de la durée utile ;
- activer le journal des requêtes lentes, et traiter les coupables ;
- convertir les tables MyISAM restantes en InnoDB ;
- mesurer à nouveau, et ne reporter sur la vraie boutique que ce qui a fait gagner du temps.
Cette démarche s'inscrit dans un travail plus large sur la vitesse, que je détaille dans le guide boutique PrestaShop lente : où passe réellement la seconde. Si vous préférez la confier, je m'occupe de l'optimisation de la base de données PrestaShop, ou d'un audit de performances complet qui chiffre chaque gain avant d'y toucher.
Commentaires
Aucun commentaire pour l’instant. Le vôtre sera le premier.