Un site associatif de mise en relation entre bénévoles et structures locales tournait sous WordPress 6.1 depuis plusieurs mois sans problème notable, avec un TTFB moyen mesuré à 180 millisecondes. La montée vers WordPress 6.2, effectuée un lundi matin en dehors des heures de pointe, s’est traduite dès les premières heures par un TTFB moyen de 410 millisecondes, plus du double, sans qu’aucun message d’erreur n’apparaisse dans les journaux.
La question posée par l’équipe technique était directe : faut-il déjà planifier un rollback vers 6.1, ou le problème vient-il d’ailleurs et peut-il être corrigé sans revenir en arrière ? La réponse ne pouvait venir que d’un diagnostic méthodique, en écartant les causes une par une plutôt qu’en devinant.
Écarter d’abord les faux problèmes
Avant de chercher une cause complexe, deux vérifications rapides et souvent négligées : le cache d’objet et le cache de page fonctionnent-ils toujours normalement après la mise à jour, et la mesure du TTFB avant/après compare-t-elle des situations comparables (même heure, même absence de cache froid) ? Sur ce site, le cache de page FastCGI avait été purgé automatiquement par le script de déploiement, ce qui gonflait artificiellement le TTFB moyen des premières minutes. Une fois le cache reconstitué après une vingtaine de minutes, le TTFB est redescendu à 340 millisecondes, encore loin des 180 millisecondes initiales mais nettement moins alarmant.
Isoler la cause : cœur, extension ou base de données
Trois hypothèses restaient sur la table : un ralentissement introduit par le cœur de WordPress 6.2 lui-même, une extension devenue incompatible qui déclenche un comportement de secours coûteux, ou une migration de structure de base de données mal indexée après la mise à jour.
La méthode suivie a consisté à traiter ces trois hypothèses dans l’ordre du coût de vérification, du moins coûteux au plus coûteux.
Étape 1 — Vérifier les migrations de base de données
WordPress consigne les migrations de schéma appliquées dans l’option db_version. La commande wp db check et une inspection manuelle des tables via wp db query "SHOW TABLE STATUS" ont permis de vérifier qu’aucune table n’affichait de croissance anormale ni de fragmentation excessive après la mise à jour. Cette hypothèse a été écartée en moins de dix minutes.
Étape 2 — Désactivation dichotomique des extensions
Sur un environnement de recette identique en configuration, les vingt-deux extensions actives ont été désactivées par moitié successive (recherche dichotomique), en remesurant le TTFB à chaque étape avec wp-cli et un test de charge léger via k6 pour dix requêtes consécutives sur la page d’accueil.
$ wp plugin deactivate --all --path=/var/www/recette
$ wp plugin activate plugin-a plugin-b plugin-c ... # première moitié
$ k6 run --vus 1 --iterations 10 ttfb-check.js
La recherche a convergé en quatre itérations vers une seule extension responsable : un plugin de gestion de formulaires qui, à partir de WordPress 6.2, se rabattait sur une méthode de compatibilité plus lente pour enregistrer ses blocs, faute d’une mise à jour de l’extension elle-même prenant en charge la nouvelle API. Ce comportement de secours (fallback) exécutait une requête SQL supplémentaire non indexée à chaque chargement de page, y compris hors formulaire.
Étape 3 — Confirmer avec Query Monitor
Une fois l’extension isolée, Query Monitor a confirmé une requête SELECT sur la table postmeta sans index approprié, ajoutée à chaque chargement de page par ce mode de compatibilité, avec un temps d’exécution de 190 millisecondes en moyenne sur ce serveur.
Le correctif retenu
Deux options existaient : revenir à WordPress 6.1 en attendant une mise à jour du plugin de formulaires, ou mettre à jour ce plugin vers sa version la plus récente, sortie deux semaines plus tôt et corrigeant justement cette incompatibilité d’après son changelog. La deuxième option a été retenue et validée en recette avant un nouveau déploiement en production, ramenant le TTFB moyen à 195 millisecondes, proche de la valeur initiale.
- Écarter d’abord les artefacts de mesure (cache froid, heure de comparaison différente).
- Vérifier les migrations de base avant de suspecter le cœur de WordPress.
- Isoler par dichotomie plutôt que de désactiver les extensions une par une au hasard.
Un TTFB qui double après une mise à jour du cœur est rarement causé par le cœur lui-même ; il est bien plus souvent le symptôme d’une extension qui n’a pas suivi.
Notre verdict
Le rollback n’était pas nécessaire dans ce cas, mais il restait une option de repli légitime si aucune cause n’avait pu être isolée dans un délai raisonnable. La règle adoptée depuis par l’équipe : ne jamais planifier de montée de version majeure sans avoir d’abord vérifié, sur un environnement de recette, l’état de compatibilité des extensions les plus utilisées du site, en particulier celles qui manipulent des blocs ou des métadonnées à fort volume.
