« Le site rame depuis la migration. » Ce constat, remonté par l’équipe produit d’une jeune pousse quelques jours après le changement d’hébergeur, méritait un diagnostic rigoureux plutôt qu’une hypothèse rapide. Le temps de réponse moyen du serveur, suivi via un outil de supervision externe, était passé d’environ 180 millisecondes avant la migration à plus de 400 millisecondes après, sans qu’aucune modification de code n’ait accompagné le changement d’infrastructure.
Ce billet ne traite pas la question du prix de l’hébergement ni du choix du prestataire, uniquement la méthode de diagnostic qui a permis d’identifier la cause du ralentissement et de la corriger.
Symptôme : un doublement homogène, pas un pic ponctuel
Premier élément notable : le ralentissement n’était pas un pic isolé lié à une charge exceptionnelle, mais un doublement homogène du temps de réponse sur l’ensemble des pages, y compris les pages les plus simples du site. Ce type de symptôme, uniforme plutôt que localisé sur certaines pages précises, oriente généralement vers une couche transversale de l’infrastructure plutôt que vers un problème de code applicatif propre à une page donnée.
Diagnostic : remonter la chaîne de requêtes
La première vérification a porté sur le nombre de requêtes SQL exécutées par page, via l’extension Query Monitor activée temporairement sur l’environnement de préproduction répliquant la nouvelle infrastructure. Le nombre de requêtes n’avait pas changé par rapport à l’ancien hébergement, ce qui écartait une hypothèse de régression côté code.
La deuxième vérification a porté sur le temps d’exécution individuel de ces requêtes, resté comparable à l’ancien environnement. Le ralentissement ne venait donc pas de la base de données elle-même, mais d’un autre maillon.
La troisième vérification, plus déterminante, a porté sur la configuration du cache d’objets. Sur l’ancien hébergement, un serveur Redis dédié assurait un cache d’objets persistant entre les requêtes, réduisant fortement le nombre d’appels effectifs à la base pour les données fréquemment sollicitées comme les options du site ou les menus. Sur le nouvel hébergement, cette configuration n’avait pas été reproduite : WordPress utilisait son cache d’objets par défaut, non persistant, réinitialisé à chaque requête HTTP.
Ce que change concrètement l’absence de cache persistant
Sans cache d’objets persistant, chaque requête HTTP reconstruit depuis zéro les données mises en cache pendant l’exécution précédente. Les fonctions comme get_option() ou les requêtes de menu, normalement servies depuis la mémoire lors d’exécutions successives grâce à un cache partagé comme Redis ou Memcached, retournent à une lecture systématique en base à chaque nouvelle requête. Le nombre de requêtes SQL par page reste identique en apparence, mais le nombre réel d’accès à la base sur l’ensemble du trafic du site augmente fortement, chaque visiteur reconstruisant le même cache que le précédent.
Correctif : réinstaller un cache d’objets persistant
Le correctif a consisté à provisionner une instance Redis sur le nouvel hébergement, puis à installer un connecteur de cache d’objets persistant côté WordPress via le fichier object-cache.php placé dans wp-content. Après vérification que wp_cache_get() et wp_cache_set() utilisaient bien ce backend persistant, le temps de réponse moyen est redescendu à un niveau proche de celui observé avant la migration.
wp redis enable
wp redis status
La commande WP-CLI wp redis status, fournie par l’extension de connexion Redis installée, a permis de confirmer que le cache était bien actif et correctement connecté, plutôt que de se fier uniquement à une amélioration visuelle du temps de chargement.
Prévention : un script de vérification post-migration
Pour éviter qu’un oubli similaire ne se reproduise lors d’une future migration, un court script de vérification a été ajouté à la procédure standard de mise en production sur un nouvel environnement :
- Vérifier la présence du fichier
object-cache.phpet sa correspondance avec le backend de cache réellement disponible sur l’hébergement cible. - Comparer le nombre de requêtes SQL par page entre l’ancien et le nouvel environnement à l’aide de Query Monitor.
- Mesurer le temps de réponse moyen sur un échantillon de pages représentatives avant de considérer la migration comme terminée.
En résumé
Un doublement homogène du temps de réponse après une migration d’hébergement pointe rarement vers le code applicatif lui-même, mais bien plus souvent vers une couche d’infrastructure oubliée lors du transfert, ici un cache d’objets persistant. Documenter la configuration complète de l’ancien environnement avant toute migration, cache d’objets inclus, évite ce type de régression silencieuse qui ne se traduit par aucune erreur visible, seulement par une lenteur diffuse.
