Deux hypothèses circulaient dans l’équipe avant d’ouvrir l’outil de profilage : soit les images haute définition des réalisations plombaient le temps de chargement, soit le thème sur mesure du cabinet d’architecture contenait une requête mal écrite quelque part. La page de références, présentant une trentaine de projets avec photos, listait ses contenus dans un temps de génération nettement supérieur aux autres pages du site, sans qu’aucune des deux hypothèses ne soit vérifiée avant d’y regarder de plus près.
Première étape : activer Query Monitor et lire le tableau de bord
L’extension Query Monitor, une fois activée, ajoute une barre d’administration donnant accès au détail de chaque requête exécutée pour construire la page, avec son origine dans le code, son temps d’exécution et le nombre de fois où elle a été appelée. Sur la page de références en question, le compteur affichait cent quatre-vingt-sept requêtes SQL exécutées, un chiffre très supérieur à la moyenne des autres pages du site, qui se situaient plutôt autour de quarante requêtes.
Ce chiffre à lui seul orientait déjà le diagnostic loin des images : un poids d’image élevé ralentit le chargement côté navigateur, pas le nombre de requêtes exécutées côté serveur avant l’envoi de la page.
Deuxième étape : identifier la requête répétée
L’onglet des requêtes groupées par origine de Query Monitor a révélé qu’une même requête, récupérant les champs personnalisés d’une réalisation architecturale (surface, année, lieu, matériaux), s’exécutait une fois par projet affiché sur la page, soit une trentaine de fois pour une information qui aurait pu être récupérée en une seule requête groupée.
Le code du thème appelait get_field() à l’intérieur de la boucle d’affichage des projets, pour chaque champ personnalisé pris individuellement, sans qu’aucun mécanisme de préchargement des champs n’ait été mis en place au début de la boucle.
Le correctif appliqué
// Avant la boucle d'affichage : précharger les champs de tous les projets
$ids_projets = wp_list_pluck( $projets, 'ID' );
update_meta_cache( 'post', $ids_projets );
foreach ( $projets as $projet ) {
$surface = get_field( 'surface_m2', $projet->ID );
$annee = get_field( 'annee_livraison', $projet->ID );
$lieu = get_field( 'lieu', $projet->ID );
// affichage...
}
L’appel à update_meta_cache() avant la boucle charge en une seule requête l’ensemble des métadonnées des projets listés, que les appels ultérieurs à get_field() viennent ensuite lire directement depuis le cache, sans nouvelle requête à la base de données.
Résultat après correction
Le nombre de requêtes SQL est passé de cent quatre-vingt-sept à vingt-deux pour la même page, ramenant son temps de génération dans la moyenne des autres pages du site. Les images, dont on soupçonnait initialement la responsabilité, n’ont nécessité aucune intervention : leur poids restait comparable à celui d’autres pages du site qui, elles, ne présentaient aucun ralentissement particulier.
- Ne jamais corriger avant de mesurer : l’intuition initiale désignait la mauvaise cause.
- Regarder en priorité les requêtes répétées, pas seulement les requêtes individuellement longues.
- Précharger systématiquement les métadonnées avant toute boucle affichant plusieurs éléments avec des champs personnalisés.
Ce que Query Monitor a également révélé en passant
L’exploration de l’onglet des hooks exécutés a montré, au passage, qu’un second problème mineur cohabitait avec le premier : une feuille de style additionnelle chargée sur toutes les pages du site alors qu’elle ne servait qu’à la page de références elle-même. Ce point n’expliquait qu’une fraction négligeable du ralentissement, mais sa correction, une fois repérée, ne coûtait rien à appliquer et a été traitée dans la foulée.
Cet à-côté illustre un bénéfice secondaire du profilage systématique : au-delà de la cause principale recherchée, l’outil expose souvent d’autres petites anomalies qu’une revue de code classique aurait laissées passer faute d’attirer l’attention.
Un profilage qui commence par confirmer une intuition n’est pas un profilage : c’est une confirmation de biais avec un outil en plus.
En résumé
Ce que le design du site suggérait comme cause probable — des images lourdes — n’avait rien à voir avec le ralentissement réel, provoqué par une boucle de requêtes répétées inutilement. Query Monitor a permis de trancher en quelques minutes ce qu’une discussion d’équipe n’aurait pas résolu avec certitude, et le correctif, une fois la cause identifiée, tenait en deux lignes de code ajoutées avant la boucle.
