Un client nous a signalé qu’une page produit de son site e-commerce mettait plus de quatre secondes à s’afficher, uniquement en heures de pointe. Impossible d’installer une extension de profilage graphique en production sans risque, et l’accès à un environnement de recette identique n’existait pas. La solution la plus rapide a été d’utiliser wp profile, le paquet officiel de WP-CLI dédié au profilage en ligne de commande.
wp profile n’est pas installé par défaut avec WP-CLI : c’est un paquet séparé qu’on ajoute une seule fois par environnement. Il permet de mesurer le temps passé dans chaque étape du chargement de WordPress, dans chaque hook déclenché, et jusque dans chaque callback accroché à un hook donné — sans rien installer côté navigateur ni modifier le code.
Installer le paquet
L’installation se fait via le gestionnaire de paquets intégré à WP-CLI :
wp package install wp-cli/profile-command
wp profile stage --help
Le paquet ajoute trois sous-commandes principales : wp profile stage, wp profile hook et wp profile eval-file. Chacune zoome un cran plus profondément dans l’exécution.
Première passe : les stages
wp profile stage découpe le chargement d’une requête en grandes étapes : bootstrap (chargement du cœur et des extensions), main_query (résolution de la requête principale), template (chargement du gabarit) et quelques autres selon le contexte. C’est la première commande à lancer, car elle indique déjà dans quelle grande phase se situe le ralentissement.
wp profile stage --url=https://exemple.test/produit/exemple/
+-------------+--------+--------+--------+--------+
| stage | time | query | cache | hook |
+-------------+--------+--------+--------+--------+
| bootstrap | 0.812s | 12 | 45 | 231 |
| main_query | 2.914s | 38 | 12 | 97 |
| template | 0.401s | 9 | 88 | 156 |
+-------------+--------+--------+--------+--------+
Sur ce projet, l’essentiel du temps se trouvait dans main_query, ce qui a immédiatement écarté les hypothèses liées au gabarit ou aux extensions de mise en cache d’affichage, et pointé vers une extension exécutée pendant la résolution de la requête (comme un plugin de recommandation de produits ou un filtre sur pre_get_posts).
Deuxième passe : zoomer sur les hooks
wp profile stage accepte une option --fields pour affiner l’affichage, mais pour aller plus loin il faut passer à wp profile hook, qui liste chaque hook déclenché pendant l’étape ciblée, avec le temps cumulé de tous les callbacks qui y sont accrochés :
wp profile hook main_query --url=https://exemple.test/produit/exemple/ --order=desc
+---------------------+--------+--------+
| hook | time | count |
+---------------------+--------+--------+
| pre_get_posts | 2.203s | 4 |
| the_posts | 0.512s | 2 |
+---------------------+--------+--------+
Troisième passe : identifier le callback fautif
Une fois le hook identifié, wp profile hook <nom-du-hook> peut lister individuellement les callbacks accrochés à ce hook précis, avec leur temps d’exécution respectif. C’est à ce niveau qu’on trouve enfin le nom de la fonction ou de la méthode responsable, souvent rattachée à une extension identifiable par son préfixe :
wp profile hook pre_get_posts --url=https://exemple.test/produit/exemple/
+--------------------------------------+--------+
| callback | time |
+--------------------------------------+--------+
| WC_Recommandations::filtrer_requete | 2.198s |
| autre_plugin_ajuster_requete | 0.005s |
+--------------------------------------+--------+
Dans ce cas précis, un module de recommandations produit exécutait une sous-requête SQL non indexée à chaque affichage de fiche produit. La correction n’a pas nécessité de retirer l’extension : ajouter un index sur la colonne concernée a suffi à ramener le temps de main_query sous la demi-seconde.
Profiler un script isolé avec eval-file
Pour tester une hypothèse sans passer par une requête HTTP complète, wp profile eval-file exécute un fichier PHP arbitraire dans le contexte de WordPress chargé, et rapporte le même type de mesures. Utile pour comparer deux implémentations d’une fonction avant de choisir laquelle garder.
Les limites à connaître
- Le profilage ajoute lui-même un léger surcoût : les temps mesurés ne sont pas identiques à ceux d’une requête non profilée, mais les proportions relatives entre hooks restent fiables ;
- Comme toute commande WP-CLI,
wp profiles’exécute en ligne de commande et ne reproduit pas exactement le contexte d’une requête servie par le serveur web (absence de certains en-têtes, de sessions PHP actives) ; - Le paquet ne remplace pas un outil de profilage continu en production : c’est un outil de diagnostic ponctuel, pas un monitoring permanent.
Sur un parc de sites, on garde toujours
wp profile stagecomme premier réflexe avant d’ouvrir Query Monitor ou un profiler PHP plus lourd : c’est la commande la plus rapide à lancer en SSH, sans rien installer côté navigateur.
En résumé
wp profile ne remplace pas un vrai outil d’APM sur un projet critique, mais il rend accessible, en une poignée de commandes, un diagnostic qui demandait autrefois d’installer un profiler PHP complet. Pour un ralentissement ponctuel sur un site distant, c’est souvent la commande la plus rapide à sortir de la boîte à outils.
