Comment nettoyer les tables gonflées par WooCommerce ?

Une boutique WooCommerce en production depuis trois ans a presque toujours une base de données deux à dix fois plus grosse que ce que son catalogue justifie. Le phénomène est mécanique : chaque commande, chaque session, chaque appel d'extension laisse des traces, et rien ne les efface. Le nettoyage des tables wp_options et wp_postmeta est l'intervention qui produit le gain de performance le plus net pour le temps investi, avant tout travail sur le thème ou les images. Elle est aussi celle qui expose le plus, puisqu'on supprime des données en production : elle se mène donc avec une méthode, une sauvegarde vérifiée et une idée précise de ce que l'on retire.

Poser le diagnostic avant de supprimer

Supprimer sans mesurer conduit à retirer ce qui ne pesait rien et à laisser ce qui pèse. La première demi heure se consacre entièrement au constat, avec quelques requêtes qui donnent une image complète. Cette étape s'inscrit dans la séquence d'audit décrite dans notre article sur la manière d'auditer la vitesse d'une boutique WooCommerce.

Classer les tables par volume

Une requête sur le schéma d'information donne la taille de chaque table, données et index séparés. Sur une boutique, l'ordre attendu place en tête les métadonnées d'articles, les métadonnées de commandes si elles sont séparées, les journaux d'extensions et les sessions. Un écart flagrant, une table de journal plus grosse que le catalogue par exemple, désigne immédiatement le premier chantier. Ce relevé doit être conservé, il servira de point de comparaison après intervention.

Mesurer le poids des options chargées automatiquement

C'est le chiffre le plus important de tout le diagnostic, parce qu'il se paie à chaque requête. Une requête qui somme la longueur des valeurs marquées pour chargement automatique donne le volume lu et désérialisé à chaque page. En dessous de cinq cents kilooctets, il n'y a rien à faire ; au delà d'un mégaoctet, le gain sera visible ; au delà de cinq, c'est probablement la première cause de lenteur du site. La liste des vingt plus grosses entrées désigne alors nommément les responsables.

Compter les métadonnées par clé

Sur la table des métadonnées, un comptage groupé par nom de clé fait apparaître en quelques secondes les extensions qui écrivent massivement. On y trouve régulièrement des clés inconnues, laissées par des extensions désinstallées depuis longtemps, dont les données n'ont jamais été retirées. Un comptage complémentaire, portant sur les métadonnées dont l'article de rattachement n'existe plus, mesure la part strictement orpheline. Sur une boutique de trois ans, cette part dépasse fréquemment le quart des lignes, et sa suppression allège les requêtes de catalogue autant que le disque.

Repérer les journaux et les tables d'extensions

Beaucoup d'extensions créent leurs propres tables et y écrivent sans limite : journaux d'activité, historiques de synchronisation, files d'attente d'envois, suivis de campagnes. Ces tables ne posent pas de problème tant qu'elles restent modestes, et deviennent un problème dès qu'elles atteignent plusieurs millions de lignes. Leur purge relève de l'extension concernée, qui propose souvent un réglage de rétention désactivé par défaut. Quand ce réglage n'existe pas, la purge manuelle reste possible mais doit être refaite régulièrement, ce qui en fait un bon argument pour chercher une extension mieux tenue.

Vérifier les index

Le volume n'est pas seul en cause : une table de deux millions de lignes correctement indexée se consulte instantanément, la même sans index adapté ralentit tout. Le journal des requêtes lentes, croisé avec le plan d'exécution des requêtes concernées, indique si un index manque. Sur les installations anciennes, il n'est pas rare que des index ajoutés par les versions récentes de WordPress ou de WooCommerce n'aient jamais été créés, une mise à jour ayant échoué silencieusement. Ajouter un index sur une grosse table est une opération sensible qui verrouille l'écriture le temps de sa création, et qui doit donc être menée en dehors des heures de commande, après avoir vérifié sur une copie que le gain est réel.

Estimer le gain avant d'intervenir

Le diagnostic doit se conclure par un chiffre, faute de quoi le chantier se justifie mal. Trois valeurs suffisent : le volume total récupérable, le poids des options chargées automatiquement qui peut être retiré, et le nombre de lignes concernées dans les tables les plus sollicitées. La première parle au commerçant, la deuxième prédit assez bien le gain sur le temps de réponse, la troisième dit combien de temps l'opération prendra. Sur une boutique de trois ans jamais nettoyée, il n'est pas rare d'annoncer une réduction de moitié du volume et un gain de plusieurs dixièmes de seconde par page, ce qui suffit largement à décider. Annoncer ces chiffres avant, puis les vérifier après, transforme aussi une intervention invisible en résultat démontrable.

Ce que l'on peut retirer sans risque

Une partie du volume est constituée de données par nature temporaires, dont la suppression ne présente aucun danger. C'est par là qu'il faut commencer, parce que le gain est immédiat et le risque nul. Ces opérations sont les mêmes que celles décrites dans notre article sur WP-DBManager, plugin de gestion de base de données, à ceci près qu'une boutique impose davantage de prudence qu'un blog.

Les données temporaires expirées

WordPress stocke des valeurs à durée de vie limitée dans la table des options, avec leur date d'expiration. Le nettoyage automatique existe mais ne s'applique pas dans tous les cas, notamment quand un cache d'objets externe est absent ou mal configuré, et ces entrées s'accumulent par dizaines de milliers. Toutes celles dont la date est dépassée peuvent être supprimées sans aucune précaution : elles seront recréées à la demande si elles servent encore. Il faut en revanche se garder de supprimer les entrées sans date d'expiration, qui ne sont pas des données temporaires malgré un nommage voisin, et dont certaines portent des réglages d'extensions.

Les sessions et paniers abandonnés

WooCommerce conserve les sessions clients dans une table dédiée, avec une date d'expiration. Sur une boutique fréquentée, cette table peut atteindre plusieurs centaines de milliers de lignes si le nettoyage programmé ne s'exécute pas, ce qui arrive dès que les tâches planifiées sont défaillantes. La purge des sessions expirées est sans effet sur les clients, dont le panier était de toute façon périmé.

Les révisions d'articles en excès

Chaque enregistrement d'une fiche produit ou d'une page crée une révision complète, contenu et métadonnées comprises. Sur un catalogue régulièrement mis à jour, les révisions représentent souvent plus de la moitié du volume des tables d'articles. En conserver trois ou cinq par contenu suffit largement ; la limite se règle dans la configuration, et le rattrapage de l'existant se fait par une suppression ciblée, en veillant à retirer aussi les métadonnées associées. Il est prudent d'exclure de cette purge les contenus modifiés dans les derniers jours, une révision récente restant le seul moyen de revenir en arrière après une mauvaise manipulation éditoriale.

Les commandes annulées et les brouillons automatiques

Les commandes abandonnées avant paiement, conservées avec un statut temporaire, et les brouillons créés automatiquement lors de la saisie de produits s'accumulent également. Leur suppression au delà d'un certain âge est sans conséquence, à une réserve près : il faut s'assurer qu'aucune obligation comptable ne porte sur les documents concernés, ce qui n'est pas le cas des commandes jamais payées mais l'est de toute commande ayant donné lieu à facture. La règle usuelle en France impose la conservation des pièces comptables pendant dix ans, ce qui écarte définitivement toute suppression de commandes payées, quel que soit leur poids en base.

La corbeille

Les contenus placés dans la corbeille y restent indéfiniment si le délai de purge automatique a été désactivé, ce que font certaines configurations. Ils continuent d'occuper les tables et, dans certains cas, d'être parcourus par des requêtes. Vider la corbeille au delà de trente jours est une opération triviale que personne ne pense à faire. Le réglage correspondant se pose dans la configuration une fois pour toutes, et il vaut mieux le fixer à une valeur explicite plutôt que de compter sur la valeur par défaut, qu'une extension de nettoyage peut avoir modifiée.

Ce qui demande de la prudence

Au delà de ces catégories, on entre dans des données dont la suppression peut casser quelque chose. La règle est de ne jamais supprimer ce que l'on n'a pas identifié, et de préférer désactiver le chargement automatique plutôt que d'effacer. Cette prudence rejoint celle que nous recommandons pour toute intervention sur un site en production, notamment lors de la surveillance des mises à jour de plugins avec WP-CLI.

Les options d'extensions désinstallées

Une extension retirée laisse presque toujours ses réglages, parfois plusieurs mégaoctets. Avant de les supprimer, il faut vérifier que l'extension n'est ni présente ni prévue de revenir, et conserver une copie des entrées concernées dans un fichier. Cette copie coûte quelques kilooctets et permet de restaurer en cas de doute, ce qui arrive quand une extension est réinstallée trois mois plus tard et qu'on découvre que la configuration a disparu.

Le chargement automatique, à ajuster plutôt qu'à supprimer

Beaucoup d'options volumineuses sont légitimes mais n'ont aucune raison d'être chargées à chaque requête. Basculer leur indicateur de chargement automatique produit l'essentiel du gain sans rien effacer : la donnée reste disponible, elle est simplement lue à la demande. C'est l'intervention la plus rentable et la plus sûre de tout le chantier, et elle est réversible en une requête. La seule vérification à mener est que l'option concernée n'est pas lue à chaque page par du code qui la suppose déjà chargée, ce qui produirait une requête supplémentaire au lieu d'une économie : le cas est rare et se repère au profilage.

Les métadonnées orphelines

Supprimer les métadonnées dont l'article parent n'existe plus semble évident et l'est presque toujours, à une exception près : certaines extensions stockent des données rattachées à des identifiants qui ne sont pas des articles, en détournant la table. La vérification consiste à examiner les clés concernées avant la suppression en masse, et à exclure celles dont le nom trahit un usage particulier. Une bonne pratique consiste à procéder clé par clé plutôt que d'un bloc, en commençant par celles qui représentent le plus de lignes, ce qui donne l'essentiel du gain en quelques opérations contrôlées.

Les tables laissées par les extensions

Une table appartenant à une extension désinstallée peut être supprimée, à condition d'être certain de son origine. Le doute est fréquent, les noms de tables n'étant pas toujours explicites. La méthode prudente consiste à renommer la table avec un préfixe temporaire plutôt qu'à la supprimer, à attendre plusieurs semaines, puis à supprimer si rien n'a cassé. Cette précaution transforme une décision irréversible en essai contrôlé. Elle suppose simplement de noter quelque part la liste des tables renommées et la date, sans quoi personne ne saura plus, six mois après, ce que sont ces tables au nom bizarre.

Les données personnelles, à traiter pour elles mêmes

Une base de boutique contient des données personnelles, et leur conservation obéit à des règles qui ne sont pas celles de la performance. Les comptes clients inactifs depuis plusieurs années, les commandes anciennes au delà de la durée de conservation comptable, les paniers abandonnés contenant une adresse électronique et les journaux d'extensions qui enregistrent des adresses réseau relèvent tous du même sujet. La démarche consiste à définir une durée par catégorie, puis à anonymiser ou supprimer au delà, ce que WooCommerce sait faire nativement pour une partie des données. Ce nettoyage là ne se justifie pas par le gain de place, qui est un effet secondaire agréable, mais par une obligation, et il gagne à être programmé plutôt que mené une fois lors d'un audit.

Mener l'opération et la rendre durable

Le nettoyage lui même se déroule en quelques heures. Ce qui compte est l'ordre des opérations et ce que l'on met en place ensuite pour ne pas recommencer dans un an.

Sauvegarder et vérifier la sauvegarde

Une sauvegarde de la base doit être prise juste avant, et surtout vérifiée, c'est à dire restaurée ailleurs et ouverte. Une sauvegarde non testée n'est pas une sauvegarde, et c'est précisément lors d'une opération de suppression que l'on découvre qu'elle était tronquée. Sur une base volumineuse, l'export doit être fait avec un outil en ligne de commande plutôt que par une interface web, dont les délais d'exécution provoquent des fichiers incomplets sans message d'erreur. La sauvegarde des fichiers n'est pas nécessaire pour ce chantier, qui ne touche qu'à la base, ce qui réduit considérablement le temps de préparation.

Travailler par lots

Une suppression portant sur des centaines de milliers de lignes en une seule instruction verrouille la table et peut rendre le site indisponible plusieurs minutes. Découper en lots de quelques milliers de lignes, avec une courte pause entre chaque, permet d'opérer sur un site en production sans interruption perceptible. C'est un peu plus long à écrire et cela évite d'avoir à prévoir une fenêtre de maintenance. Sur les tables les plus sollicitées, il vaut mieux opérer aux heures creuses malgré tout, un verrou de quelques secondes suffisant à faire échouer une commande en cours.

Récupérer l'espace réellement

Supprimer des lignes ne réduit pas nécessairement la taille du fichier sur le disque, l'espace restant réservé pour de futures écritures. Une opération d'optimisation de table est nécessaire pour le rendre au système, et elle doit être menée en dehors des heures de trafic car elle peut être longue. Sur les tables très volumineuses, elle demande temporairement autant d'espace libre que la table pèse, ce qui doit être vérifié avant de la lancer. Sur un hébergement mutualisé où l'espace disque est contraint, cette contrainte suffit parfois à rendre l'opération impossible, et il faut alors passer par une copie de la table plutôt que par une optimisation sur place.

Mettre en place la rétention

Le nettoyage n'a de sens que s'il devient inutile. Cela suppose de fixer une limite de révisions dans la configuration, d'activer les purges proposées par les extensions, de vérifier que les tâches planifiées s'exécutent réellement, et d'ajouter une tâche mensuelle qui traite les catégories sans risque. Un contrôle mensuel du volume des tables et des options chargées, envoyé dans le rapport d'exploitation, suffit à repérer une dérive avant qu'elle ne redevienne un chantier. Ce suivi a une vertu supplémentaire : une croissance soudaine et inexpliquée du volume est souvent le premier signe visible d'une extension qui journalise trop, voire d'une activité anormale sur le site. Un relevé mensuel du poids de ces deux tables, conservé dans un simple tableau, suffit à rendre cette croissance visible, et rend l'anomalie détectable bien avant que les temps de réponse ne se dégradent.