7  signes avant-coureurs de la base de données WordPress que la plupart des propriétaires de sites manquent

Votre site se charge. Les visiteurs ne se plaignent pas. Rien dans wp-admin ne génère d'erreurs.

Pourtant, votre base de données accumule silencieusement du poids mort depuis des mois, voire des années.

Le gonflement de la base de données ne se manifeste pas toujours en façade. Vos pages peuvent sembler identiques aux visiteurs, que votre base de données soit optimisée ou qu'elle contienne des milliers de révisions de publications.

Les problèmes surviennent ailleurs : une sauvegarde qui prend deux fois plus de temps à se terminer, une migration qui bloque à mi-chemin, ou un tableau de bord d'administration qui semble lent à chaque chargement de page.

J'ai vu cela sur des sites par ailleurs bien entretenus. Personne n'avait regardé la base de données depuis des années, et cela s'est vu au moment où nous avons essayé de migrer.

Ces signes sont spécifiques et diagnostiquables. Vous n'avez pas besoin d'exécuter des requêtes SQL ou de fouiller dans phpMyAdmin pour savoir si votre base de données a besoin d'attention. Il vous suffit de savoir quoi chercher.

Je vais vous montrer les signes clés indiquant que votre base de données WordPress a besoin d'optimisation et à quoi ressemble une base de données saine, afin que vous ayez un objectif à atteindre.

Voici les points clés à retenir :

• Le gonflement de la base de données peut être invisible en façade, surtout sur les pages mises en cache. Les signes se manifestent souvent dans la taille des sauvegardes, les temps de migration et la vitesse d'administration plutôt que sur votre site en direct.
• Les signes à surveiller : administration lente, erreurs lors de la sauvegarde des publications, délais "en attente de la base de données" dans les tests de vitesse, chargements lents des pages non mises en cache, sauvegardes surdimensionnées, migrations lentes et taille disproportionnée de la base de données.
• Les données autoloadées dépassant environ 800 Ko à 1 Mo peuvent devenir une préoccupation, en fonction du site et de la configuration du cache. La table wp_options est le premier endroit à vérifier.
• Les tables orphelines de plugins désinstallés s'accumulent silencieusement et contribuent à la taille de la base de données sans rien ajouter d'utile.
• DB Optimizer donne à votre base de données un score de santé de 0 à 100 dans cinq catégories afin que vous sachiez exactement ce qui nécessite une attention avant de migrer ou de sauvegarder.
• Nettoyez avant de migrer, pas après. Une base de données plus petite signifie une sauvegarde plus petite, un transfert plus rapide et moins de débogage si quelque chose tourne mal.

Table des matières

Qu'est-ce qui s'accumule dans votre base de données WordPress ?

WordPress génère une quantité surprenante de données qui n'ont rien à voir avec votre contenu réel. Ce n'est pas de votre faute ; c'est juste la façon dont la plateforme fonctionne.

Révisions d'articles

Chaque fois que vous enregistrez ou mettez à jour une publication, WordPress en stocke une révision. Il n'y a pas de limite intégrée par défaut, sauf si vous en définissez une.

Une publication que vous avez modifiée 50 fois contient 50 copies stockées dans votre base de données. Sur un blog actif ou un site où plusieurs éditeurs travaillent, ces copies s'accumulent rapidement.

Transitoires expirés et données autoloadées

Les transients sont des enregistrements temporaires que les plugins stockent dans votre base de données. Par exemple, les réponses d'API, les résultats de requêtes mis en cache et les paramètres de courte durée.

Ils sont conçus pour expirer d'eux-mêmes après une période définie. Souvent, ils restent dans la base de données jusqu'à ce qu'ils soient nettoyés ou accédés à nouveau.

Les transients expirés peuvent s'accumuler dans votre table wp_options, qui est l'endroit où WordPress stocke les paramètres globaux du site. Ceux marqués comme "autoloaded" sont chargés à chaque requête de page non mise en cache.

Lorsque les données "autoloaded" atteignent 800 Ko à 1 Mo ou plus, cela peut devenir un problème de performance. Cela ajoute une surcharge à chaque chargement de page de votre site, que ce soit dans l'administration ou ailleurs.

Commentaires spam, corbeille et métadonnées orphelines

Mettre un article à la corbeille ou marquer un commentaire comme spam ne le supprime pas de la base de données. Il y reste jusqu'à ce que vous le supprimiez définitivement.

Les plugins désactivés laissent des lignes dans wp_postmeta et wp_options. Une fois qu'un plugin est supprimé, ces lignes n'ont plus d'enregistrement parent auquel s'attacher.

On les appelle métadonnées orphelines, et elles s'accumulent silencieusement chaque fois que vous changez de plugin.

Surcharge des tables

Lorsque des lignes sont supprimées d'une table de base de données, MySQL ne récupère pas automatiquement cet espace. Les espaces laissés sont appelés surcharge.

Les tables qui gèrent des écritures fréquentes (comme wp_options et wp_postmeta) peuvent accumuler de la surcharge plus rapidement que d'autres. La surcharge ne casse généralement rien, mais elle gaspille de l'espace disque et peut rendre certaines tâches de maintenance moins efficaces.

7 signes indiquant que votre base de données WordPress a besoin d'optimisation

Un site lent est facile à attribuer à l'hébergement ou aux plugins. Ces signes sont plus spécifiques. Chacun pointe directement vers la base de données.

• Administration WordPress lente : Le tableau de bord contourne la mise en cache des pages et interroge la base de données à chaque chargement. Une table wp_options surchargée rend chaque page d'administration lente.
• Erreurs lors de la sauvegarde des articles : Les échecs d'écriture et la corruption de table produisent des erreurs de sauvegarde qui ressemblent à des conflits de plugins mais qui remontent à la base de données.
• "En attente de la base de données" dans les tests de vitesse : GTmetrix l'identifie spécifiquement. Un TTFB élevé avec une réponse serveur lente indique des tables fragmentées, pas votre hébergeur.
• Chargements de pages non mis en cache lents : Les utilisateurs connectés, les éditeurs et les pages de paiement WooCommerce contournent la mise en cache. Si ces flux sont lents, la base de données en est probablement la cause.
• Sauvegardes surdimensionnées : La taille de la sauvegarde reflète directement la taille de la base de données. Le poids mort est sauvegardé avec tout le reste.
• Migrations lentes : Une base de données surchargée produit un package de migration plus volumineux, un téléchargement plus lent, et plus de choses peuvent mal tourner pendant le transfert.
• Taille de base de données disproportionnée : Si votre base de données est beaucoup plus volumineuse que ne le suggère votre nombre de contenus, les tables orphelines et les déchets accumulés expliquent l'écart.

L'administration de votre WordPress est sensiblement lente

C'est généralement la première chose que les propriétaires de sites remarquent. Le front-end semble correct, mais le tableau de bord, la liste des articles et la médiathèque se chargent lentement.

L'administration WordPress contourne entièrement la mise en cache des pages. Chaque page d'administration dépend des requêtes de base de données.

Lorsque wp_options est surchargé de transients expirés et de paramètres de plugin résiduels, WordPress dispose de plus de données à traiter à chaque requête non mise en cache.

J'ai vu cela sur des sites où les données autoloaded avaient dépassé 2 Mo. Chaque page wp-admin prenait plusieurs secondes à répondre.

La solution n'était pas une mise à niveau de l'hébergement. C'était le nettoyage de la base de données.

Le seuil à connaître : les données autoloaded supérieures à environ 800 Ko à 1 Mo sont souvent un signe avant-coureur.

Vous obtenez des erreurs lors de la sauvegarde des articles

Les erreurs intermittentes lors de la sauvegarde des articles sont faciles à attribuer à un conflit de plugin. La base de données est souvent la cause réelle.

Une base de données sous tension en raison de corruption, de problèmes de verrouillage ou de contraintes serveur peut commencer à échouer sous la charge d'écriture. Vous pourriez voir une invite générique « Êtes-vous sûr de vouloir faire cela ? », un écran blanc, ou un article qui semble être sauvegardé mais ne l'est pas.

La corruption de table (qui peut se produire lorsqu'une opération de base de données est interrompue) produit les mêmes symptômes.

Si vous avez exclu les conflits de plugins et que les erreurs persistent, vérifiez d'abord la santé de votre base de données.

Les outils de test de vitesse indiquent des délais « En attente de la base de données »

Des outils comme GTmetrix vous montrent où le temps est passé lors du chargement d'une page.

Dans GTmetrix, la barre violette dans le graphique en cascade représente le « temps d'attente » — le temps entre l'envoi de la requête par le navigateur et la réception du premier octet du serveur.

Une longue barre violette indique un traitement côté serveur lent. Ce traitement comprend les requêtes de base de données.

Lorsque les tables fragmentées prennent plus de temps à analyser qu'elles ne le devraient, les requêtes qui devraient s'exécuter en moins de 10 millisecondes commencent à s'accumuler. La barre violette s'allonge.

Un TTFB élevé (Time to First Byte, le temps entre une requête du navigateur et le premier octet d'une réponse) avec un temps de réponse serveur lent est l'un des signaux mesurables les plus clairs que votre base de données a besoin d'attention.

Les chargements de pages sont lents pour les requêtes non mises en cache

La mise en cache masque les problèmes de base de données pour la plupart des visiteurs. Elle sert une copie stockée de la page au lieu d'interroger la base de données à chaque fois. Mais la mise en cache ne couvre pas tout le monde.

Les utilisateurs administrateurs, les éditeurs et les membres connectés contournent entièrement le cache de page. Les pages de panier et de paiement WooCommerce le contournent généralement également. Si ces flux semblent lents, la base de données est probablement la cause.

Vos sauvegardes sont plus volumineuses qu'elles ne devraient l'être

La taille de la sauvegarde est un reflet direct de la taille de la base de données. Les données inutiles sont sauvegardées avec tout le reste.

Une base de données contenant 100 000 révisions d'articles et 50 000 transients expirés ajoute des mégaoctets réels à chaque sauvegarde. Cela signifie des temps de transfert plus longs, plus de stockage cloud consommé et des restaurations plus lentes si vous en avez jamais besoin.

La plupart des gens ne le remarquent pas car les sauvegardes s'exécutent en arrière-plan. Vous ne le ressentez que lorsqu'une sauvegarde expire ou qu'une restauration prend une heure de plus que prévu.

Les migrations prennent plus de temps que prévu

Lorsque vous migrez un site WordPress, la base de données complète est déplacée avec lui. Chaque ligne orpheline, chaque transient expiré et chaque copie de révision fait le voyage.

Une base de données volumineuse produit un package de migration plus volumineux. Cela signifie un téléchargement plus lent, plus de temps pour que quelque chose se passe mal pendant le transfert, et une situation plus complexe à déboguer si la migration échoue.

Le bon ordre est de nettoyer la base de données d'abord, puis de créer votre sauvegarde, puis de migrer.

DB Optimizer est spécialement conçu pour ce flux de travail de pré-migration. Vérifiez votre score de santé, nettoyez ce qui doit l'être, puis déplacez-vous.

Votre base de données contient des tables orphelines ou une taille disproportionnée

Chaque plugin qui crée ses propres tables de base de données les laisse derrière lui lorsqu'il est désinstallé — à moins que le développeur n'ait explicitement écrit de code de nettoyage.

Des tables de plugins que vous avez supprimés il y a des années pourraient encore se trouver dans votre base de données. Elles prennent de la place et ajoutent de l'encombrement à chaque requête qui scanne votre liste de tables.

Si votre base de données fait 500 Mo mais que vous n'avez que 300 articles, les tables orphelines et les déchets accumulés peuvent expliquer l'écart.

La plupart des tableaux de bord d'hébergement affichent la taille de votre base de données. Si vous ne l'avez pas vérifié récemment, cela vaut la peine d'y jeter un œil.

À quoi ressemble une base de données saine

Voici à quoi ressemble une base de données WordPress bien entretenue :

• Données autoloadées à environ 800 Ko à 1 Mo, selon le site et la configuration du cache
• Surcharge de table à zéro ou proche de zéro après un nettoyage récent
• Transients soit effacés, soit expirant comme prévu
• Révisions d'articles limitées ou purgées périodiquement
• Aucune table restante de plugins désactivés

La plupart des propriétaires de sites n'ont aucun moyen de vérifier ces éléments sans exécuter des requêtes SQL ou fouiller dans phpMyAdmin. C'est la lacune que DB Optimizer comble.

DB Optimizer est un plugin qui donne à votre base de données un score de santé de 0 à 100. Il évalue cinq catégories : surcharge de table, transients, révisions, taille autoload, et éléments dans la corbeille.

Chaque catégorie a sa propre barre de progression et une note codée par couleur. Le vert signifie que vous êtes en bonne voie. Le jaune signifie que quelque chose nécessite une attention. Le rouge signifie qu'il est temps de nettoyer.

Optimisez votre base de données entière en masse avec l'onglet Nettoyage. DB Optimizer nettoie vos révisions d'articles, commentaires de spam, transients, trackbacks et autres données inutiles.

Cela transforme la maintenance de la base de données en une tâche simple que vous pouvez réellement maîtriser.

Comment vérifier la santé de votre base de données avant votre prochaine migration

Si vous prévoyez une migration, c'est le bon moment pour vérifier la santé de votre base de données. Pas après que le transfert ait pris deux fois plus de temps.

Ouvrez DB Optimizer et vérifiez votre score de santé. Regardez quelles catégories sont vertes, jaunes ou rouges. Cela vous indique où se trouvent les problèmes avant de toucher quoi que ce soit.

Allez dans l'onglet Nettoyage. Avant d'exécuter quoi que ce soit, DB Optimizer vous montre le nombre total d'éléments disponibles pour le nettoyage et l'espace récupérable dans toute votre base de données. Vous décidez quoi nettoyer et quoi laisser.

Définissez votre seuil de rétention. La valeur par défaut est de 7 jours, ce qui signifie que tout ce qui a été créé au cours de la dernière semaine est hors limites, quelles que soient les catégories de nettoyage que vous avez sélectionnées.

Si vous êtes prudent, définissez-le plus haut. Si vous voulez une ardoise propre avant de migrer, définissez-le plus bas.

DB Optimizer affiche le nombre d'éléments et la taille estimée pour chaque type de nettoyage avant que quoi que ce soit ne s'exécute. Examinez la liste, désélectionnez tout ce que vous souhaitez conserver et confirmez lorsque vous êtes prêt.

DB Optimizer détecte automatiquement Duplicator et place un lien direct vers créer une sauvegarde juste à côté des contrôles de nettoyage. Cliquez dessus, car vous ne voulez rien perdre d'important.

Une base de données plus propre signifie une sauvegarde plus petite, un transfert plus rapide et moins de choses à trier en cas de problème.

Questions fréquemment posées (FAQ)

Une base de données volumineuse ne se répare pas toute seule

Les problèmes de performance abordés dans cet article sont réels, mais ils se manifestent dans la taille des sauvegardes, les temps de migration et la vitesse de réponse de l'administration, pas sur votre frontend. C'est pourquoi ils sont ignorés.

Le coût se manifeste plus tard. Une migration qui devrait prendre 20 minutes en prend deux heures. Une sauvegarde échoue en cours de transfert car le fichier est devenu trop volumineux. Une sauvegarde de publication commence à générer des erreurs, et vous passez un après-midi à écarter les conflits de plugins alors que la base de données avait besoin d'un nettoyage.

La maintenance de la base de données est facile à reporter indéfiniment car les conséquences sont invisibles jusqu'à ce qu'elles ne le soient plus.

Une vérification à faire dès maintenant, avant d'installer quoi que ce soit : ouvrez votre tableau de bord d'hébergement ou phpMyAdmin et regardez la taille de votre table wp_options. Sur un site WordPress typique, elle devrait être inférieure à 3 à 5 Mo.

Si elle est de 10 Mo ou plus, les données autoloadées sont presque certainement le problème. Cette seule table, lorsqu'elle est volumineuse, ajoute une surcharge à chaque chargement de page sur l'ensemble de votre site, qu'elle soit mise en cache ou non. C'est le moyen le plus rapide d'obtenir une évaluation approximative de la présence d'un problème dans votre base de données qui mérite d'être résolu.

DB Optimizer vous donne une image plus complète. Il vous fournit un score de santé de la base de données, un aperçu complet de ce qui peut être nettoyé avant toute exécution, et un seuil de rétention configurable qui exclut automatiquement les données récentes.

DB Optimizer est inclus dans le plan Duplicator Elite aux côtés de WP Media Cleanup, Activity Log et Duplicator Pro. Quatre outils pour maintenir votre site WordPress sain, sauvegardé et prêt à être déplacé lorsque vous en avez besoin.

Si cet article vous a fait réfléchir à la santé de votre base de données, ces guides méritent d'être lus ensuite.

• Comment optimiser votre base de données WordPress
• Voici les étapes de réparation de la base de données WordPress que j'ai moi-même suivies (aucun développeur nécessaire)
• Maintenance de la base de données WordPress : Ce qu'il faut faire chaque semaine, chaque mois et chaque trimestre
• Comment sauvegarder une base de données WordPress (Guide complet)
• Comment restaurer une base de données WordPress (3 méthodes)
• 13 meilleurs plugins de base de données WordPress pour une gestion facile des données