Les métriques WordPress que personne ne surveille (et qui prédisent les pannes)

Un site client, score 92 sur Lighthouse. Le lendemain matin, erreur 502 en boucle. L’hébergeur pointe la base de données : la table wp_options pesait 38 Mo dont 4,2 Mo en autoload. Quinze plugins désinstallés avaient laissé leurs données derrière eux, et personne n’avait jamais regardé.

Ce genre de crash, j’en ai vu des dizaines chez WPServeur entre 2015 et 2020 (hébergement WordPress géré, des milliers de sites). Le point commun : les outils classiques de monitoring ne montrent rien. Le site semble rapide, les scores sont verts… et la base de données pourrit en silence.

Voici les 10 métriques que je surveille systématiquement. Pas les Core Web Vitals. Pas le score Lighthouse. Les indicateurs internes, ceux que personne ne regarde, organisés en trois couches : base de données, exécution serveur, cache et performance.

Quelles métriques surveiller dans la base de données WordPress ?

Quatre métriques ciblent la base de données. C’est là que 80% des pannes WordPress trouvent leur origine. Pas dans le thème, pas dans le PHP, pas dans le serveur web : dans MySQL.

Votre autoload wp_options dépasse-t-il 800 Ko ?

Chaque chargement de page lit toutes les options marquées autoload en une seule requête SQL. Plus ce paquet grossit, plus l’initialisation de WordPress ralentit. Depuis WordPress 6.6 (sorti en juillet 2024), le Site Health déclenche une alerte critique au-delà de 800 Ko. C’est le seuil officiel, documenté par Paul Bearne et Joe McGill dans la dev note Make WordPress Core de juin 2024.

La plupart des administrateurs ne verront jamais cette alerte parce qu’ils ne regardent jamais l’écran Santé du site. C’est un tort.

Nota : depuis WordPress 6.6, la colonne autoload accepte quatre valeurs : 'yes', 'on', 'auto' et 'auto-on'. L’ancienne requête WHERE autoload = 'yes' ne suffit plus. Voici la version à jour.

wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

Cette seconde requête identifie les 20 coupables les plus lourds, triés par poids décroissant.

wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') ORDER BY size DESC LIMIT 20;"

Ce que j’observe sur le terrain : les trois premiers coupables sont presque toujours les mêmes. Des options de cache d’extensions désinstallées, des résidus de page builders, et des données sérialisées de plugins SEO qui stockent leurs configurations complètes en autoload. Sur un site avec 20 extensions testées puis supprimées au fil des années, j’ai mesuré 2,8 Mo d’autoload fantôme. Le site mettait 1,4 seconde rien qu’à lire la table wp_options.

En dessous de 800 Ko, tout va bien. Entre 800 Ko et 1 Mo, il est temps d’investiguer. Au-delà d’1 Mo, le nettoyage devient urgent. Et passé 2 à 3 Mo, le temps de réponse serveur grimpe nettement, jusqu’aux erreurs 503 sur les grosses installations (la documentation WordPress VIP situe l’idéal sous 1 Mo).

Mon conseil : lancez cette requête une fois par mois. C’est 10 secondes en WP-CLI et ça peut vous épargner un lundi matin catastrophique.

La table wp_postmeta grossit sans limite

La table wp_postmeta est la plus volumineuse sur la majorité des sites WordPress. C’est le stockage fourre-tout : champs personnalisés, données Yoast, réglages Elementor, métadonnées ACF…

Et là, on touche un vrai problème structurel. Elementor stocke 5 à 8 métadonnées par page, dont _elementor_data : un champ JSON qui peut peser plusieurs centaines de Ko. Chaque autosave duplique ce JSON dans une nouvelle révision. Un article sauvegardé 50 fois avec Elementor génère 50 copies du même JSON massif. Ajoutez les SVG inline (_elementor_inline_svg) et les données de conditions… On l’oublie trop souvent, mais j’ai déjà audité un site de 400 articles avec 280 000 lignes dans wp_postmeta. La requête SELECT * FROM wp_postmeta WHERE post_id = X prenait 800 ms à elle seule.

wp db query "SELECT COUNT(*) AS total_rows FROM wp_postmeta;"
wp db query "SELECT COUNT(*) AS total_posts FROM wp_posts WHERE post_type NOT IN ('revision','attachment');"

Divisez le premier par le deuxième. Si vous dépassez 100 métadonnées par article, il y a un problème de fragmentation. La commande suivante nettoie les métadonnées orphelines, celles dont l’article parent a été supprimé.

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

Jusqu’à 50 000 lignes pour un site de 500 articles, c’est normal. Entre 50 000 et 100 000, ça mérite un coup d’œil. Au-delà de 100 000 lignes pour moins de 500 articles, vous avez un problème de fragmentation.

Transients expirés : la dette technique invisible

Les transients sont des données temporaires stockées en base (ou en cache objet si Redis est actif). WordPress les utilise partout : résultats d’API, vérifications de mises à jour, fragments de cache…

Bonne nouvelle : depuis WordPress 4.9, un cron quotidien (delete_expired_transients) nettoie automatiquement les transients expirés. Mauvaise nouvelle : ce nettoyage ne couvre que les transients dont le timeout est dépassé et qui sont encore référencés. Les extensions désinstallées laissent derrière elles des transients orphelins que le cron ne touche pas.

wp db query "SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();"
wp transient delete --expired

Sur les sites que j'audite, au-delà de 500 transients expirés, je considère le nettoyage urgent. Ce n'est pas un seuil officiel. C'est un repère calibré après des centaines d'audits. Le vrai indicateur, c'est l'impact sur l'autoload : si les transients représentent plus de 30% de la taille autoload totale, la situation est critique.

Moins de 100 transients expirés, c'est tolérable. Entre 100 et 500, un nettoyage programmé s'impose. Au-delà de 500, ou si les transients représentent plus de 30% de votre autoload, c'est urgent.

Combien de révisions pourrissent votre base ?

Par défaut, WordPress ne limite pas le nombre de révisions. Chaque Ctrl+S crée une nouvelle entrée dans wp_posts avec ses métadonnées associées dans wp_postmeta. Ça paraît évident, mais... personne ne regarde. J'ai audité un site de 500 articles actif depuis 5 ans : 42 000 révisions. 42 000 lignes inutiles au quotidien.

wp post list --post_type=revision --format=count

La solution tient en une ligne dans wp-config.php (source : documentation officielle WordPress).

define('WP_POST_REVISIONS', 5);

Moins de 5 000 révisions sur l'ensemble du site, c'est sain. Entre 5 000 et 20 000, planifiez un nettoyage. Au-delà de 20 000, ou si un seul article dépasse 50 révisions, la base souffre.

Comment détecter un ralentissement côté serveur WordPress ?

La base est propre ? Bien. Maintenant, regardons ce qui se passe à chaque chargement de page : les requêtes SQL, les tâches planifiées, et les appels réseau sortants.

Combien de requêtes SQL votre page génère-t-elle vraiment ?

Un WordPress vanilla avec un thème par défaut récent génère autour de 20 à 25 requêtes SQL par chargement de page. Ajoutez 15 extensions actives... et vous montez facilement à 150, voire 200+.

Votre site tourne, mais est-ce qu'il rame en silence ? Passé 100 requêtes par page, il faut investiguer. Et pour ça, un seul outil : Query Monitor.

Query Monitor affiche le compteur de requêtes directement dans la barre d'administration. L'onglet "Queries by Component" identifie quel plugin ou thème génère le plus de requêtes. C'est chirurgical. Sur les sites que j'audite, le coupable numéro un est presque toujours un page builder qui charge ses métadonnées sur chaque page, même celles qu'il n'a pas créées. Le deuxième : WooCommerce sur des boutiques avec 5 000+ produits sans optimisation de base de données.

Moins de 50 requêtes par page, c'est correct. Entre 50 et 100, ça commence à peser. Au-delà de 100, il y a forcément un composant qui abuse.

Comment détecter un WP-Cron bloqué ?

WordPress utilise un pseudo-cron déclenché par les visites. Pas de visiteur, pas de cron. Sur un site à faible trafic, vos publications planifiées ne sortent pas, vos emails restent en file, et le nettoyage automatique des transients ne se fait jamais.

Le Site Health de WordPress considère une tâche comme en retard après 15 minutes et en échec après 1 heure (source : Trac #47223). Deux commandes WP-CLI suffisent pour diagnostiquer la situation.

wp cron event list
wp cron test

La première liste toutes les tâches et leur statut. La seconde vérifie si le loopback fonctionne : c'est le mécanisme par lequel WordPress s'appelle lui-même pour déclencher le cron de WordPress. Si wp cron test échoue, vos tâches planifiées sont mortes.

Un détail que personne ne mentionne : John Blackbourn est l'auteur de Query Monitor et de WP Crontrol. Les deux outils de debug et monitoring WordPress les plus populaires, maintenus par la même personne. Ça en dit long sur l'état de l'écosystème de monitoring WordPress.

Tant que toutes les tâches s'exécutent à l'heure, pas de souci. Une tâche en retard de plus de 15 minutes, c'est un premier signal. Au-delà d'une heure de retard, ou si wp cron test échoue, le cron est cassé.

Vos extensions appellent-elles des serveurs tiers en cachette ?

Combien de secondes vos extensions ajoutent-elles en coulisse ? À chaque chargement, certains plugins font des appels HTTP vers des serveurs tiers : vérification de licence, récupération de données API, chargement de polices Google, embeds oEmbed...

Query Monitor affiche tout ça dans l'onglet "HTTP API Calls" : URL appelée, méthode, temps de réponse, composant responsable. C'est souvent la révélation.

Le nombre de requêtes importe moins que le temps cumulé. Une seule requête vers une API lente qui met 3 secondes à répondre est pire que 10 requêtes rapides de 50 ms. Sur les sites que j'audite, au-delà d'1 à 2 secondes de temps cumulé, c'est un signal d'alerte.

Voici les corrections les plus efficaces.

• Google Fonts : hébergez-les en local (Perfmatters ou OMGF)
• Licences : le filtre pre_http_request intercepte et bloque les appels inutiles
• Embeds oEmbed : désactivez-les si vous n'intégrez pas de contenu tiers
• Scripts analytics : chargez-les en asynchrone

Moins de 500 ms cumulées en requêtes externes, c'est acceptable. Entre 500 ms et 2 secondes, ça commence à peser sur le TTFB. Au-delà de 2 secondes, c'est un frein réel au chargement.

Comment mesurer le cache et la performance WordPress en production ?

Les deux couches précédentes sont invisibles. Celle-ci commence à se voir, mais pas là où vous regardez d'habitude.

Quel est le hit rate de votre cache objet ?

Le cache objet (Redis ou Memcached) stocke les résultats des requêtes SQL en mémoire vive pour éviter de les refaire à chaque page. C'est un accélérateur puissant... quand il fonctionne bien.

Pas de panique si vous n'avez pas Redis : beaucoup d'hébergements mutualisés ne le proposent pas. Mais si vous l'avez activé, vérifiez qu'il fait vraiment son travail. Un hit rate inférieur à 80% signifie que plus d'une requête sur cinq retourne en base. Autant ne pas avoir de cache du tout.

Avec l'extension Redis Object Cache (Till Krüss, 300 000+ installations, note 4.5/5) :

wp redis status

Ou directement via redis-cli :

redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys"

Le hit rate se calcule ainsi : keyspace_hits / (keyspace_hits + keyspace_misses) x 100. Visez 90%+.

Et les évictions ? Si evicted_keys est supérieur à zéro, la mémoire allouée à Redis est insuffisante. Point final. Redis ne mesure pas les évictions en pourcentage. Toute éviction = mémoire trop petite. Augmentez le maxmemory.

Au-dessus de 90% de hit rate avec zéro éviction, votre cache fait son travail. Entre 80 et 90%, la configuration mérite un ajustement. En dessous de 80%, ou dès qu'une éviction apparaît, le cache ne remplit plus son rôle.

TTFB par page : la métrique que vous mesurez mal

Votre TTFB global est bon, mais page par page ? Le TTFB moyen ne veut rien dire quand votre homepage en cache répond en 50 ms et que la page "mon-compte" non cachée met 1,2 seconde.

Google Lighthouse échoue l'audit au-delà de 600 ms (source : web.dev). Avec un cache de page actif, le TTFB devrait rester sous 200 ms. Au-delà, la configuration du cache est défaillante.

curl -s -o /dev/null -w '%{time_starttransfer}\n' https://votre-site.com/page-cible/

Testez systématiquement les pages dynamiques : administration, espace client, panier WooCommerce, résultats de recherche. Ce sont elles qui révèlent les vrais problèmes.

Sur wpformation.com, j'obtiens un TTFB de 14 ms en moyenne. Mais c'est un cas particulier : le frontend est en Next.js avec des pages pré-générées. Sur les WordPress classiques que j'audite, la moyenne tourne autour de 400 à 600 ms sans optimisation... et 80 à 150 ms avec un bon cache de page.

Avec un cache actif, le TTFB devrait rester sous 200 ms. Entre 200 et 600 ms, quelque chose cloche dans la configuration. Au-delà de 600 ms, c'est le seuil d'échec de l'audit Lighthouse : votre page est objectivement lente côté serveur.

Quels plugins chargent leurs scripts sur chaque page ?

Celle-là, c'est mon combat depuis des années. 90% des sites que j'audite chargent Contact Form 7 sur toutes les pages. 90%. Alors que le formulaire n'existe que sur la page contact. Bref.

Chaque extension qui enregistre un fichier JavaScript ou CSS le fait par défaut sur toutes les pages. C'est le comportement standard de wp_enqueue_script(). Comptez les scripts enregistrés sur votre installation avec cette commande WP-CLI.

wp eval 'echo count(wp_scripts()->registered);'

Query Monitor affiche les onglets "Scripts" et "Styles" avec le composant responsable de chaque fichier. Pour corriger, deux approches. L'approche code, avec un hook conditionnel dans functions.php.

add_action('wp_enqueue_scripts', function() {
    if (!is_page('contact')) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
    }
});

L'approche plugin : Asset CleanUp (100 000+ installations, note 98/100) permet de désactiver sélectivement les scripts par page. Nota : Asset CleanUp est activement maintenu (version 1.4.0.4, testée avec WordPress 6.9.4) et figure parmi les optimiseurs de ressources les plus utilisés.

Moins de 20 scripts par page, c'est raisonnable. Entre 20 et 40, vérifiez ce qui est réellement utilisé. Au-delà de 40, surtout si plus de la moitié ne servent à rien sur la page courante, le ménage est indispensable.

Questions fréquentes sur les métriques WordPress

Quel outil utiliser pour mesurer toutes ces métriques rapidement ?

Query Monitor donne 80 % des réponses sans config. Pour le reste, WP-CLI couvre la base de données et les transients, redis-cli vérifie le cache objet, et un script bash maison agrège tout. Aucun de ces outils n'est payant : la donnée est déjà là, il faut juste savoir où regarder.

À quelle fréquence faut-il auditer ces 10 métriques ?

Pour un site standard, un audit mensuel suffit. Pour un site WooCommerce ou un site à fort trafic (plus de 50 000 visiteurs par mois), je recommande un audit hebdomadaire. Et toujours un audit ponctuel après une mise à jour majeure de WordPress, l'ajout d'un nouveau plugin, ou un pic de trafic anormal.

Mon hébergement mutualisé peut-il vraiment faire tourner Redis pour le cache objet ?

La plupart des hébergements mutualisés français (OVH Perso, Infomaniak, o2switch sur les offres de base) ne proposent pas Redis. Il faut un VPS, un cloud managé (Kinsta, WP Engine), ou une offre mutualisée premium. Sans Redis, le cache objet WordPress utilise la base de données, ce qui annule justement le bénéfice attendu.

Faut-il payer un APM comme New Relic ou Datadog pour bien surveiller ?

Pas pour démarrer. Query Monitor et WP-CLI couvrent le principal pour un site standard. Un APM payant devient utile au-delà de 100 000 visiteurs par mois, ou quand vous avez plusieurs serveurs à corréler. Avant ce seuil, le ROI est faible et la complexité opérationnelle augmente sans bénéfice tangible.

Que faire si plusieurs métriques sont rouges en même temps ?

Toujours dans cet ordre : autoload (couche 1) avant tout, parce qu'il pénalise chaque requête. Ensuite les requêtes SQL excessives (couche 2). Ensuite le cache objet et le TTFB (couche 3). Le cache de page peut masquer une base de données malade ; ne jamais commencer par le cache si la base déborde.

Mon tableau de bord : les 10 métriques en un coup d'œil

Bon. Voici le récapitulatif complet. Un tableau que vous pouvez imprimer, coller sur votre écran, ou intégrer dans un rapport d'audit client :

Pour automatiser, un script bash qui exécute les commandes WP-CLI en batch :

#!/bin/bash
echo "=== AUDIT METRIQUES WORDPRESS ==="
echo "Autoload: $(wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');" --skip-column-names) bytes"
echo "Postmeta: $(wp db query "SELECT COUNT(*) FROM wp_postmeta;" --skip-column-names) rows"
echo "Transients expirés: $(wp db query "SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();" --skip-column-names)"
echo "Révisions: $(wp post list --post_type=revision --format=count)"
echo "Cron: $(wp cron test 2>&1)"

Planifiez-le en cron hebdomadaire et envoyez le résultat par email. C'est 5 minutes de configuration et ça vous épargne des heures de debug en urgence.

Pour ceux qui préfèrent une interface graphique, WP-Optimize (déjà testé avec WordPress 7.0) centralise le nettoyage des révisions, transients et tables orphelines. C'est l'extension de référence pour la maintenance de base de données, avec 1 million d'installations actives en avril 2026.

Ces 10 métriques couvrent les trois couches invisibles d'un WordPress : la base de données, l'exécution serveur, et le cache. Ça ne remplace pas un monitoring temps réel sur un site critique. Mais pour un freelance qui gère 10 ou 20 sites clients, un audit mensuel de ces indicateurs avec WP-CLI et Query Monitor, c'est la différence entre éteindre des incendies et les prévenir.

Article original sur WPFormation