WP Performance (backend uniquement)

Quand utiliser cette skill

Utilise cette skill quand :

• un site/page/endpoint WordPress est lent (TTFB frontend, admin, REST, WP-Cron)
• tu as besoin d'un plan de profilage et de recommandations d'outils (WP-CLI profile/doctor, Query Monitor, Xdebug/XHProf, APMs)
• tu optimises des requêtes BD, des options autoloadées, le object caching, les tâches cron, ou les appels HTTP distants

Cette skill suppose que l'agent ne peut pas utiliser une interface navigateur. Préfère WP-CLI, les logs et les requêtes HTTP.

Entrées requises

• Environnement et sécurité : dev/staging/prod, toute restriction (pas d'écritures, pas d'installation de plugins).
• Comment cibler l'installation :
  • racine WP --path=<path>
  • (multisite/ciblage de site) --url=<url>
• Le symptôme de performance et sa portée :
  • quelle URL/route REST/écran admin
  • quand cela se produit (toujours vs sporadique ; connecté vs déconnecté)

Procédure

0) Garde-fous : mesurer d'abord, éviter les opérations risquées

1. Confirme si tu peux exécuter des opérations d'écriture (installation de plugins, changements de config, flush de cache).
2. Choisis une cible reproductible (URL ou route REST) et capture une baseline :
   • TTFB/temps avec curl si possible
   • profilage WP-CLI si disponible

Consulte :

• references/measurement.md

1) Générer un rapport de performance backend uniquement (déterministe)

Exécute :

• node skills/wp-performance/scripts/perf_inspect.mjs --path=<path> [--url=<url>]

Cela détecte :

• la disponibilité de WP-CLI et la version du noyau
• si wp doctor / wp profile sont disponibles
• la taille des options autoloadées (si possible)
• la présence d'un drop-in object-cache

2) Gains rapides : exécuter les diagnostics avant le profilage approfondi

Si tu as accès à WP-CLI, préfère :

• wp doctor check

Cela détecte les pièges courants en production (surcharge d'autoload, SAVEQUERIES/WP_DEBUG, nombre de plugins, mises à jour).

Consulte :

• references/wp-cli-doctor.md

3) Profilage approfondi (pas de navigateur requis)

Ordre préféré :

1. wp profile stage pour voir où le temps s'écoule (bootstrap/main_query/template).
2. wp profile hook (optionnellement avec --url=) pour trouver les hooks/callbacks lents.
3. wp profile eval pour des chemins de code ciblés.

Consulte :

• references/wp-cli-profile.md

4) Query Monitor (utilisation backend uniquement)

Query Monitor est normalement piloté par l'interface, mais peut être utilisé sans interface via les en-têtes de réponse de l'API REST et les réponses _envelope :

• Authentifie-toi (nonce ou Application Password).
• Demande des réponses REST et inspecte les en-têtes (x-qm-*) et/ou la propriété qm en utilisant ?_envelope.

Consulte :

• references/query-monitor-headless.md

5) Corriger par catégorie (choisir le principal goulot d'étranglement)

Utilise la sortie du profilage pour choisir une catégorie de goulot d'étranglement primaire :

• Requêtes BD → réduire le nombre de requêtes, corriger les patterns N+1, améliorer les index, éviter les requêtes meta coûteuses.
  • references/database.md
• Options autoloadées → identifier les plus grandes options autoloadées et arrêter d'autocharger les gros blobs.
  • references/autoload-options.md
• Absence de hits du object cache → introduire du cache ou corriger l'utilisation des clés/groupes de cache ; ajouter un persistent object cache si approprié.
  • references/object-cache.md
• Appels HTTP distants → ajouter des délais d'expiration, du cache, du batching ; éviter d'appeler les APIs distantes à chaque requête.
  • references/http-api.md
• Cron → réduire les pics dus maintenant, dédupliquer les événements, déplacer les tâches lourdes hors des chemins de requête.
  • references/cron.md

6) Vérifier (répéter la même mesure)

• Réexécute le même wp profile / wp doctor / requête REST.
• Confirme le delta de performance et que le comportement est inchangé.
• Si la correction est risquée, déploie derrière un feature flag ou un déploiement par étapes si possible.

Améliorations de performance WordPress 6.9

Sois conscient de ces changements 6.9 lors du profilage :

CSS à la demande pour les thèmes classiques :

• Les thèmes classiques reçoivent maintenant le chargement du CSS à la demande (auparavant seuls les thèmes de bloc avaient ceci).
• Réduit la charge CSS de 30-65% en chargeant uniquement les styles pour les blocs réellement utilisés sur la page.
• Si tu profilees un thème classique, cela devrait déjà aider.

Thèmes de bloc sans ressources bloquantes de rendu :

• Les thèmes de bloc qui ne définissent pas de feuilles de styles personnalisées (comme Twenty Twenty-Three/Four) peuvent maintenant charger avec zéro CSS bloquant le rendu.
• Les styles proviennent des styles globaux (theme.json) et des styles de bloc séparés, tous intégrés.
• Cela améliore significativement le LCP (Largest Contentful Paint).

Limite du CSS intégré augmentée :

• Le seuil pour intégrer les petites feuilles de styles a été augmenté, réduisant les ressources bloquantes de rendu.

Référence : https://make.wordpress.org/core/2025/11/18/wordpress-6-9-frontend-performance-field-guide/

Vérification

• Les chiffres de baseline vs après sont capturés (même environnement, même URL/route).
• wp doctor check est propre (ou amélioré) le cas échéant.
• Pas de nouvelles erreurs ou avertissements PHP dans les logs.
• Aucun flush de cache n'est requis pour la correction (le flush de cache doit être le dernier recours).

Modes d'échec / débogage

• « Aucun changement » après les modifications de code :
  • tu as mesuré une URL/site différente (désaccord --url), les caches ont masqué les résultats, ou le cache opcode est obsolète
• Les données de profilage sont bruyantes :
  • élimine les tâches de fond, teste avec des caches préchauffés, exécute plusieurs échantillons
• SAVEQUERIES/Query Monitor cause une surcharge :
  • ne l'exécute pas en production sauf approbation explicite

Escalade

• Si c'est la production et tu n'as pas d'approbation explicite, ne fais pas :
  • installer de plugins, activer SAVEQUERIES, exécuter des tests de charge, ou flush de caches pendant le trafic
• Si tu as besoin d'un profilage au niveau système (APM, extensions PHP profiler), coordonne avec ops/hosting.