La performance WordPress dépend de deux familles de problèmes différentes. Le TTFB concerne surtout le temps de réponse serveur; l’INP mesure la réactivité après une interaction dans le navigateur. Réduire un chargement PHP inutile peut aider le serveur, mais ne corrige pas automatiquement un script JavaScript lourd ou une interface bloquée côté client.
Ce guide évite les promesses liées à une version précise de PHP. Il propose une méthode qui reste valable quelle que soit votre stack: mesurer, identifier le travail inutile, différer ce qui peut l’être et recontrôler le résultat.
Distinguer TTFB et INP
| Signal | Où se trouve le problème | Pistes de diagnostic |
|---|---|---|
| TTFB élevé | serveur, PHP, base, cache, réseau | logs, APM, requêtes SQL, workers PHP |
| INP élevé | navigateur, JavaScript, rendu, événements | Chrome DevTools, Performance, scripts tiers |
| Les deux | parcours complet | thème, extensions, données, hébergement |
Ne modifiez pas PHP pour résoudre un problème qui apparaît uniquement après un clic dans le navigateur. Inversement, ne réduisez pas les scripts front-end pour masquer une base de données saturée.
Réduire le travail PHP inutile
Le principe du chargement différé est simple: ne créez pas un objet, une requête ou un SDK avant qu’un parcours en ait réellement besoin. Dans un plugin WordPress, cela peut concerner un client API externe, une analyse IA, un export ou un traitement d’image.
Avant de modifier le code, relevez :
- les extensions chargées sur chaque type de page ;
- les appels HTTP sortants ;
- les requêtes SQL lentes ;
- la mémoire par requête ;
- les hooks qui s’exécutent même sur des pages sans rapport avec la fonction.
Déplacez ensuite le chargement d’un service vers le hook ou l’action qui en a besoin. Gardez une condition claire et testez les cas où l’extension est désactivée ou la clé API absente.
Exemple de structure de plugin
add_action('admin_post_mon_export', function () {
$client = new ClientExterne();
$result = $client->runExport();
wp_safe_redirect(add_query_arg('export', $result ? 'ok' : 'error', admin_url()));
exit;
});Ici, le client externe n’est créé que lorsqu’un administrateur déclenche l’export. Ce n’est pas une optimisation magique: elle doit être mesurée sur le parcours concerné et ne doit pas empêcher les contrôles de sécurité ou les tâches planifiées légitimes.
Améliorer l’INP côté navigateur
Pour l’INP, recherchez les tâches JavaScript longues, scripts tiers, événements coûteux et changements de mise en page. Les actions utiles sont souvent :
- différer les scripts non critiques ;
- découper les traitements longs ;
- réduire les bibliothèques inutilisées ;
- éviter les écouteurs globaux coûteux ;
- tester les formulaires, filtres et menus sur mobile.
Protocole de mesure
- Choisissez un parcours concret: page produit, recherche, formulaire ou administration.
- Mesurez avant modification avec les mêmes conditions.
- Modifiez un seul élément.
- Vérifiez l’absence d’erreur dans les logs et la console.
- Rejouez le même parcours sur mobile et ordinateur.
- Conservez la modification seulement si elle améliore une mesure définie sans dégrader une fonction.
Sécurité et maintenance
Un plugin qui charge moins de code reste un plugin à maintenir. Mettez à jour WordPress, PHP et les extensions après test de compatibilité. Un scanner de sécurité WordPress peut compléter cette maintenance en recherchant les fichiers inattendus, portes dérobées et code injecté sans installer de plugin sur le site à analyser.
Pour aller plus loin
- Scanner de malwares WordPress externe
- Maintenance WordPress et surveillance
- Configurer PHP, MySQL et MariaDB
