Auditer les problèmes de performance WordPress avec wp profile

La commande wp profile est un peu comme une alternative à New Relic, capable d’identifier précisément quels composants ralentissent votre site WordPress. Initialement disponible en tant que package premium via runcommand, il est désormais gratuit sur GitHub.

Si vous cherchez un hébergeur compatible avec l’installation de wp profile, jetez un œil à Kinsta et FastNyx.

J’utilise régulièrement wp profile pour diagnostiquer les problèmes de performance chez mes clients sur Codeable. Tous les développeurs WordPress devraient s’en servir ! Après avoir suivi ce guide, vous serez plus proche de la résolution de la lenteur de votre site WordPress.

Un site WordPress lent peut avoir mille causes : plugin trop lourd, thème bavard, requêtes SQL répétées, cache objet absent, option autoloadée énorme, appel HTTP externe, hook mal placé, ou simple hébergement à bout de souffle.

La mauvaise méthode consiste à désactiver des plugins au hasard et à espérer que le site accélère. La bonne méthode consiste à mesurer. C’est précisément là que wp profile devient très utile.

wp profile est une commande WP-CLI qui mesure les grandes étapes du chargement WordPress. Elle permet de repérer les stages, hooks, plugins et thèmes qui consomment le plus de temps. Ce n’est pas un profiler aussi profond que Blackfire, Xdebug ou New Relic, mais c’est souvent suffisant pour trouver où commencer.

À quoi sert wp profile ?

wp profile aide à répondre à une question simple : où WordPress perd-il du temps ?

La commande peut mesurer :

• les grandes étapes du chargement WordPress ;
• les hooks les plus coûteux ;
• le temps pris par les plugins ;
• le temps pris par le thème ;
• le nombre de requêtes SQL ;
• le temps passé en base de données ;
• le ratio de cache objet ;
• le nombre d’appels HTTP externes.

L’intérêt est énorme : vous obtenez une première carte du problème depuis le terminal, sans installer une extension de diagnostic dans un back-office déjà lent.

Sur un site client, c’est souvent mon premier réflexe après les vérifications serveur, les logs PHP et les en-têtes HTTP. En quelques commandes, on sait si le problème vient plutôt du bootstrap, du thème, d’un plugin, de MySQL ou d’un hook précis.

Ce que wp profile ne fait pas

wp profile ne remplace pas un vrai APM. Il ne vous donnera pas la pile complète de chaque requête SQL, la trace de chaque fonction PHP, ni l’analyse fine d’un appel réseau bloquant.

Il ne mesure pas non plus l’expérience navigateur complète : rendu CSS, JavaScript, images, polices, Core Web Vitals, LCP, CLS ou INP. Pour cela, il faut compléter avec des outils front-end comme WebPageTest, Lighthouse, Chrome DevTools ou les données terrain de Search Console.

En revanche, wp profile répond très bien à cette première question : WordPress lui-même est-il lent, et quelle partie du chargement coûte le plus cher ?

Prérequis

Pour utiliser wp profile, il vous faut :

• un accès SSH au serveur ;
• WP-CLI installé ;
• un utilisateur capable d’exécuter les commandes WordPress ;
• un site WordPress fonctionnel ;
• idéalement un environnement de staging pour les tests agressifs.

Depuis le dossier WordPress, vérifiez WP-CLI :

wp --info

Vérifiez ensuite que WordPress répond :

wp core version

Si vous êtes connecté en root, ajoutez --allow-root. Toutefois, sur un serveur propre, mieux vaut exécuter WP-CLI avec l’utilisateur système propriétaire des fichiers WordPress.

Installer wp profile

wp profile s’installe comme package WP-CLI :

wp package install wp-cli/profile-command

Si votre version WP-CLI refuse la version de développement, installez la version stable :

wp package install wp-cli/profile-command:@stable

Vérifiez ensuite que la commande est disponible :

wp profile --help

Pour mettre à jour les packages WP-CLI :

wp package update

Si vous administrez le serveur en root :

wp package update --allow-root

Comprendre les trois stages WordPress

La commande la plus utile pour commencer est :

wp profile stage

Elle découpe le chargement WordPress en trois étapes principales :

Stage	Ce qu’il représente	Lecture rapide
bootstrap	Chargement de WordPress, mu-plugins, plugins, thème et hooks initiaux.	Souvent lié aux plugins, au thème, aux options autoloadées ou au cache objet.
main_query	Transformation de l’URL demandée en requête principale WordPress.	Souvent lié à WP_Query, taxonomies, archives, recherche ou requêtes SQL.
template	Résolution du template, rendu du thème, hooks front-end et sortie HTML.	Souvent lié au thème, aux builders, aux hooks wp_head ou wp_footer.

Exemple :

wp profile stage --spotlight --orderby=time

Le flag --spotlight filtre les valeurs peu utiles et rend la sortie beaucoup plus lisible. Le tri par time permet d’aller directement vers ce qui coûte le plus cher.

Lire les colonnes importantes

La sortie de wp profile contient plusieurs colonnes. Voici celles à regarder en premier :

Colonne	Signification	Ce qu’il faut surveiller
time	Temps total consommé par l’étape, le hook ou le composant.	Votre premier indicateur pour classer les lenteurs.
query_time	Temps passé dans les requêtes SQL.	Élevé = MySQL, index, requêtes ou métadonnées à analyser.
query_count	Nombre de requêtes SQL.	Élevé = requêtes répétées, boucle mal optimisée ou plugin bavard.
cache_ratio	Rapport entre les lectures servies par cache objet et les lectures manquées.	Faible = cache objet absent, mal configuré ou peu efficace.
cache_hits	Lectures réussies dans le cache objet.	Utile pour vérifier l’intérêt d’un cache Redis/Memcached.
cache_misses	Lectures non trouvées dans le cache objet.	Trop élevé = données recalculées ou cache inefficace.
hook_time	Temps passé dans les hooks WordPress.	Élevé = callback ou plugin à identifier.
request_time	Temps passé dans des requêtes HTTP externes.	Élevé = API externe, licence, tracking, flux distant ou timeout.

Ne regardez pas une seule colonne isolément. Un plugin peut avoir un time élevé sans beaucoup de SQL. Dans ce cas, il peut faire du calcul PHP ou appeler une API. À l’inverse, un query_count élevé avec un query_time faible peut signaler une architecture bavarde, mais pas forcément le goulot d’étranglement principal.

Mesurer plusieurs fois avant de conclure

Un benchmark unique ne vaut pas grand-chose. Le serveur peut être froid, le cache vide, une tâche cron peut se lancer, ou une requête externe peut répondre lentement une seule fois.

Lancez donc plusieurs mesures :

for i in 1 2 3 4 5; do
  echo "Run $i"
  wp profile stage --spotlight --orderby=time
doneCode language: PHP (php)

Comparez ensuite les tendances. Si le même hook ou le même plugin revient à chaque fois, vous avez une piste solide. Si les résultats changent fortement, cherchez un cache froid, un cron, un appel externe ou une charge serveur irrégulière.

Profiler une URL précise

Par défaut, wp profile utilise l’URL d’accueil. Or une page d’accueil rapide ne prouve rien sur une boutique WooCommerce, une recherche, une archive produit ou une page de checkout.

Testez une URL précise avec --url :

wp profile stage --url="https://www.example.com/categorie/mon-article/" --spotlight --orderby=timeCode language: JavaScript (javascript)

Sur WooCommerce, testez plusieurs types de pages :

wp profile stage --url="https://www.example.com/boutique/" --spotlight --orderby=time
wp profile stage --url="https://www.example.com/categorie-produit/exemple/" --spotlight --orderby=time
wp profile stage --url="https://www.example.com/produit/exemple/" --spotlight --orderby=timeCode language: JavaScript (javascript)

Évitez de tirer des conclusions depuis une seule URL. Un site WordPress peut être rapide sur les articles, mais lent sur les archives, la recherche ou les catégories produits.

Analyser le bootstrap

Si bootstrap est lent, WordPress perd du temps avant même de traiter la requête principale. C’est souvent le signe d’un plugin lourd, d’un mu-plugin coûteux, d’options autoloadées trop volumineuses, ou d’un cache objet absent.

Analysez ce stage :

wp profile stage bootstrap --spotlight --orderby=time

Les hooks à surveiller dans cette zone :

• muplugins_loaded ;
• plugins_loaded ;
• setup_theme ;
• after_setup_theme ;
• init ;
• wp_loaded.

Si plugins_loaded ou init explose, cherchez un plugin qui charge trop tôt, ajoute trop de hooks, fait des requêtes SQL au chargement global, ou appelle une API externe à chaque page. Oui, certains plugins font ça. Non, ils ne devraient pas.

Analyser la requête principale

Si main_query est lent, le problème vient souvent de la manière dont WordPress construit la requête principale.

wp profile stage main_query --spotlight --orderby=time

Sur un site classique, regardez :

• les archives avec beaucoup de contenus ;
• les recherches internes ;
• les taxonomies produits ;
• les requêtes avec meta_query ;
• les requêtes avec orderby=meta_value ;
• les filtres produits ;
• les requêtes générées par les plugins SEO, facettes ou builders.

Un query_count élevé n’est pas toujours catastrophique. Mais un query_time élevé sur une archive indique souvent une requête mal indexée, une table trop grosse, ou une logique de filtrage coûteuse.

Analyser le template

Si template est lent, le problème se situe souvent dans le thème, le builder, les hooks front-end, les shortcodes ou les blocs dynamiques.

wp profile stage template --spotlight --orderby=time

Les hooks à surveiller :

• template_redirect ;
• wp ;
• wp_head ;
• loop_start ;
• the_content ;
• wp_footer.

Un wp_head lourd peut venir de scripts, de balises SEO, de pixels, de préchargements mal gérés ou d’un plugin qui injecte trop de choses partout. Un the_content lent peut venir de shortcodes, blocs dynamiques, embeds, galeries, tables des matières ou filtres de contenu trop ambitieux.

Trouver les hooks les plus lents

Pour afficher les hooks les plus coûteux :

wp profile hook --spotlight --orderby=time

Pour analyser un hook précis :

wp profile hook init --orderby=time
wp profile hook wp_head --orderby=time
wp profile hook the_content --orderby=time

Cette commande devient très utile quand vous savez déjà quel hook ralentit la page. Elle aide à descendre d’un niveau pour repérer les callbacks coûteux.

Si le hook lent appartient à un plugin, vérifiez d’abord si le plugin doit vraiment exécuter ce code sur toutes les pages. Beaucoup de gains viennent d’une optimisation simple : charger une fonctionnalité uniquement là où elle sert.

Trouver les plugins les plus lents

Pour profiler les plugins :

wp profile plugin --spotlight --orderby=time

Cette commande vous donne une première idée des extensions les plus coûteuses pendant le chargement WordPress.

Ensuite, comparez avec et sans un plugin suspect :

wp profile stage --url="https://www.example.com/page-lente/" --spotlight --orderby=time

wp profile stage --url="https://www.example.com/page-lente/" --spotlight --orderby=time --skip-plugins=plugin-suspect/plugin-suspect.phpCode language: JavaScript (javascript)

Pour tester sans aucun plugin classique :

wp profile stage --url="https://www.example.com/page-lente/" --skip-plugins --spotlight --orderby=timeCode language: JavaScript (javascript)

Attention : --skip-plugins ne désactive pas les mu-plugins. C’est une bonne chose, car les mu-plugins font souvent partie de l’infrastructure du site. Mais cela veut aussi dire qu’un mu-plugin lent restera présent dans vos mesures.

Ne désactivez pas les plugins directement en production pour “tester vite fait”. Utilisez plutôt --skip-plugins avec WP-CLI, ou travaillez sur staging. Le site public vous dira merci. Les clients aussi.

Trouver un thème lent

Pour mesurer le thème :

wp profile theme --spotlight --orderby=time

Vous pouvez aussi comparer avec le thème désactivé côté WP-CLI :

wp profile stage --url="https://www.example.com/page-lente/" --skip-themes --spotlight --orderby=timeCode language: JavaScript (javascript)

Si le site accélère fortement avec --skip-themes, cherchez du côté des templates, shortcodes, hooks, blocs dynamiques, requêtes personnalisées et fonctions appelées dans le thème.

Sur un thème maison, vérifiez en priorité les boucles imbriquées, les WP_Query sans cache, les appels répétés à get_post_meta(), les requêtes directes non indexées et les appels API dans le rendu front-end.

Exporter les résultats en CSV ou JSON

Pour comparer des mesures, exportez-les. C’est plus propre que de copier un tableau depuis le terminal.

wp profile stage --spotlight --orderby=time --format=json > profile-stage.json
wp profile hook --spotlight --orderby=time --format=csv > profile-hooks.csv
wp profile plugin --spotlight --orderby=time --format=csv > profile-plugins.csv

Vous pouvez ensuite garder ces fichiers comme preuve avant/après, surtout dans un audit client. C’est plus crédible que “j’ai l’impression que ça va mieux”.

Comparer avant et après une optimisation

Une optimisation sérieuse se mesure avant et après.

Avant modification :

wp profile stage --url="https://www.example.com/page-lente/" --spotlight --orderby=time --format=json > before-stage.json
wp profile plugin --url="https://www.example.com/page-lente/" --spotlight --orderby=time --format=json > before-plugins.jsonCode language: JavaScript (javascript)

Après modification :

wp profile stage --url="https://www.example.com/page-lente/" --spotlight --orderby=time --format=json > after-stage.json
wp profile plugin --url="https://www.example.com/page-lente/" --spotlight --orderby=time --format=json > after-plugins.jsonCode language: JavaScript (javascript)

Ensuite, comparez les résultats. Le but n’est pas seulement de faire baisser un nombre. Le but est de confirmer que la correction cible bien le goulot d’étranglement.

Diagnostiquer un cache objet inefficace

La colonne cache_ratio donne une indication utile. Si elle reste faible sur des pages dynamiques, WordPress rate beaucoup d’objets en cache.

Commencez par vérifier si un cache objet persistant est actif :

wp eval 'var_dump( wp_using_ext_object_cache() );'Code language: JavaScript (javascript)

Si la réponse est bool(false), WordPress n’utilise probablement pas de cache objet persistant comme Redis ou Memcached.

Sur un WooCommerce ou un gros site dynamique, Redis peut aider. J’ai détaillé l’installation ici : installer Redis pour accélérer WordPress sous Debian.

Attention toutefois : Redis ne remplace pas un cache page. Il complète la pile, notamment pour l’administration, les pages dynamiques, les métadonnées et les requêtes répétitives.

Repérer un problème de base de données

Si query_time est élevé, la lenteur vient probablement de MySQL ou MariaDB. Si query_count est élevé mais query_time reste faible, le site est peut-être bavard, mais pas encore bloqué par la base.

Dans ce cas, vérifiez aussi :

• la taille des tables ;
• les options autoloadées ;
• les métadonnées orphelines ;
• les index manquants ;
• les tables WooCommerce ;
• les requêtes sur wp_postmeta ;
• les plugins de recherche ou de filtres ;
• les tâches cron et actions planifiées.

Pour commencer l’audit côté base :

wp db size --tables --human-readable

Pour inspecter les options autoloadées les plus lourdes :

wp db query "
SELECT option_name, autoload, LENGTH(option_value) AS size
FROM $(wp db prefix)options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 30;
"Code language: PHP (php)

Si la base est gonflée ou mal structurée, lisez aussi nettoyer et optimiser la base de données WordPress et réparer wp_options sans clé primaire ni unique key.

Repérer les appels HTTP externes

La colonne request_time indique le temps passé dans les requêtes HTTP externes. Si elle grimpe, WordPress attend probablement une API distante.

Les causes fréquentes :

• vérification de licence plugin ;
• API marketing ;
• service anti-spam ;
• flux RSS distant ;
• géolocalisation ;
• webhook mal configuré ;
• appel vers un service lent ou indisponible.

Un appel externe ne devrait presque jamais bloquer le rendu d’une page publique. Quand c’est possible, mettez en cache la réponse, déplacez l’appel dans une tâche cron, ou ajoutez un timeout court.

Comparer avec Query Monitor, New Relic et Xdebug

wp profile donne une vue rapide depuis WP-CLI. Ensuite, selon le problème, vous pouvez compléter.

Outil	Usage idéal	Limite
wp profile	Trouver vite la zone lente depuis le terminal.	Moins détaillé qu’un profiler applicatif complet.
Query Monitor	Inspecter requêtes, hooks, templates et erreurs depuis l’admin.	Ajoute un plugin et dépend d’un site accessible.
New Relic	Observer un site en production sur la durée.	Demande une intégration hébergeur ou serveur.
Blackfire	Profiler finement du code PHP et comparer des scénarios.	Demande une configuration dédiée.
Xdebug	Déboguer et profiler en profondeur en environnement dev.	Trop lourd pour une prod classique.

Mon workflow préféré : wp profile pour trouver la zone, logs serveur pour confirmer, Query Monitor ou APM pour creuser, puis patch ciblé. Pas de chasse aux sorcières plugin par plugin. On mesure, puis on coupe.

Plan d’action après un audit wp profile

Une fois les résultats obtenus, classez les problèmes par impact.

1. Identifiez le stage le plus lent.
2. Repérez le hook, plugin ou thème responsable.
3. Comparez plusieurs runs pour confirmer.
4. Testez avec --skip-plugins ou --skip-themes.
5. Vérifiez si la lenteur vient de PHP, SQL, cache ou HTTP externe.
6. Corrigez la cause la plus coûteuse.
7. Mesurez à nouveau.
8. Documentez le gain obtenu.

Selon les résultats, les corrections typiques sont :

• désactiver une fonctionnalité plugin inutile ;
• remplacer un plugin trop lourd ;
• charger un code uniquement sur les pages nécessaires ;
• ajouter un cache objet persistant ;
• corriger une requête SQL ou ajouter un index ;
• réduire les options autoloadées ;
• mettre en cache un appel externe ;
• optimiser le thème ou un shortcode ;
• déplacer une opération dans WP-Cron ou Action Scheduler.

Exemple de diagnostic rapide

Imaginez cette sortie simplifiée :

stage       time     query_time  query_count  cache_ratio  hook_time
bootstrap   1.240s   0.050s      80           42%          1.100s
main_query  0.080s   0.040s      12           75%          0.010s
template    0.300s   0.030s      40           80%          0.250sCode language: CSS (css)

Ici, le problème principal est bootstrap. Le temps SQL reste limité, mais le hook_time est élevé et le cache_ratio est faible. Je regarderais d’abord les plugins chargés trop tôt, les mu-plugins, les options autoloadées et la présence d’un cache objet persistant.

Autre exemple :

stage       time     query_time  query_count  cache_ratio  hook_time
bootstrap   0.250s   0.020s      45           92%          0.100s
main_query  1.800s   1.600s      25           85%          0.050s
template    0.200s   0.040s      30           90%          0.120sCode language: CSS (css)

Ici, la requête principale est clairement lente. Je chercherais une archive, une recherche, une taxonomie, une requête meta, un filtre WooCommerce ou un index manquant.

Erreurs fréquentes avec wp profile

La commande wp profile n’existe pas

Le package n’est pas installé. Installez-le :

wp package install wp-cli/profile-command:@stable

Puis vérifiez :

wp profile --help

WP-CLI manque de mémoire pendant l’installation

Augmentez temporairement la mémoire PHP côté CLI :

php -d memory_limit=512M "$(which wp)" package install wp-cli/profile-command:@stableCode language: JavaScript (javascript)

Si which wp ne fonctionne pas, utilisez le chemin complet vers votre binaire WP-CLI.

Les résultats changent à chaque run

C’est normal dans une certaine mesure. Lancez plusieurs mesures. Si les écarts sont énormes, vérifiez les caches, WP-Cron, la charge serveur et les appels externes.

Le résultat en CLI ne correspond pas au navigateur

WP-CLI ne reproduit pas parfaitement un navigateur. Il ne mesure pas le rendu front-end, les scripts, les images ou les conditions exactes d’un visiteur. Utilisez --url, testez plusieurs pages, puis complétez avec des outils front-end.

Besoin d’aide pour auditer un WordPress lent ?

Checklist d’audit avec wp profile

• Vérifier que WP-CLI fonctionne.
• Installer wp-cli/profile-command:@stable.
• Tester la page d’accueil avec wp profile stage.
• Tester une URL lente avec --url.
• Lancer plusieurs runs avant de conclure.
• Comparer bootstrap, main_query et template.
• Analyser les hooks avec wp profile hook.
• Analyser les plugins avec wp profile plugin.
• Comparer avec --skip-plugins et --skip-themes.
• Surveiller query_time, query_count, cache_ratio et request_time.
• Exporter les résultats avant/après.
• Corriger un problème à la fois.
• Mesurer à nouveau après chaque optimisation importante.

FAQ : wp profile et performance WordPress

wp profile remplace-t-il New Relic ou Blackfire ?

Non. wp profile sert surtout à repérer rapidement la zone lente dans WordPress. New Relic, Blackfire ou Xdebug vont plus loin pour analyser les traces applicatives, le code PHP et le comportement en production.

Quelle commande lancer en premier ?

Commencez par wp profile stage --spotlight --orderby=time. Cette commande montre si le problème vient plutôt du bootstrap, de la requête principale ou du rendu du template.

Pourquoi faut-il lancer wp profile plusieurs fois ?

Parce qu’un run isolé peut être faussé par un cache froid, WP-Cron, une charge serveur temporaire ou un appel externe lent. Plusieurs mesures donnent une tendance plus fiable.

Comment tester une page précise ?

Utilisez --url. Par exemple : wp profile stage --url="https://www.example.com/page-lente/" --spotlight --orderby=time.

Comment savoir si un plugin ralentit WordPress ?

Lancez wp profile plugin --spotlight --orderby=time, puis comparez la même URL avec --skip-plugins=plugin/plugin.php. Si le temps baisse nettement, le plugin mérite une analyse plus poussée.

Que signifie un query_time élevé ?

Un query_time élevé indique que WordPress passe beaucoup de temps dans MySQL ou MariaDB. Il faut alors inspecter les requêtes, les index, les tables volumineuses, les options autoloadées et les plugins qui interrogent trop la base.

Que signifie un request_time élevé ?

Un request_time élevé indique souvent qu’un plugin ou le thème attend une réponse HTTP externe : API, licence, flux distant, service marketing ou webhook. Ces appels doivent être mis en cache ou déplacés hors du rendu public.

Sources

• Documentation WP-CLI : wp profile
• Documentation WP-CLI : wp profile stage
• GitHub : wp-cli/profile-command
• Documentation WP-CLI : wp cache
• SkyMinds : installer Redis pour accélérer WordPress sous Debian
• SkyMinds : nettoyer et optimiser la base de données WordPress
• SkyMinds : réparer wp_options sans clé primaire ni unique key
• SkyMinds : mettre en cache WordPress pour accélérer son site

Report a typo