L’équipe Performance de WordPress, formée pour faire avancer les fonctionnalités de vitesse dans le cœur du logiciel, publie ses travaux avant leur intégration officielle sous forme d’une extension : Performance Lab. C’est l’occasion de tester, sur un site réel, des fonctionnalités qui atterriront peut-être dans une future version majeure, tout en mesurant leur effet avant de les généraliser.
Étape 1 : installer l’extension
wp plugin install performance-lab --activateUne fois activée, l’extension ajoute un écran dédié dans le tableau de bord, listant chaque module disponible avec une description de sa fonction et son statut (stable, expérimental).
Étape 2 : activer les modules un par un, jamais en bloc
La tentation est grande d’activer tous les modules d’un coup pour gagner du temps. C’est une erreur méthodologique : si un problème apparaît après coup, impossible de savoir lequel des modules en est la cause. La bonne méthode consiste à activer un module, mesurer, puis passer au suivant.
Module WebP Uploads
Ce module génère automatiquement une version WebP de chaque image téléversée, en plus du format d’origine, et sert la version WebP aux navigateurs compatibles via la balise <picture>. Sur un site avec beaucoup d’images, ce module réduit le poids moyen des images de 25 à 35 % sans aucune configuration supplémentaire.
wp plugin list --status=active --field=name | grep webp
Module Dominant Color
Ce module calcule et stocke la couleur dominante de chaque image lors de son téléversement, permettant d’afficher un aplat de couleur en attendant le chargement de l’image réelle, une alternative légère au flou de type LQIP. L’effet se mesure surtout sur la perception de fluidité du chargement plutôt que sur un score Lighthouse chiffré.
Module Enqueued Assets Health Check
Ce module ajoute un rapport dans le tableau de bord Site Health signalant les extensions qui chargent des CSS ou JS sur toutes les pages du site sans discernement, une source fréquente de poids inutile identifiée sans avoir à ouvrir Query Monitor manuellement.
Étape 3 : mesurer chaque module isolément
Pour chaque module activé, nous relançons un test Lighthouse sur les mêmes trois gabarits (accueil, article, page produit s’il y a lieu), en conservant une trace des scores avant et après :
| Module | LCP avant | LCP après | Poids images avant/après |
|---|---|---|---|
| WebP Uploads | 2,8 s | 2,3 s | 1,2 Mo → 0,8 Mo |
| Dominant Color | 2,3 s | 2,3 s | inchangé |
| Enqueued Assets Health Check | — | — | diagnostic seul, pas d’effet direct |
Ce que Performance Lab ne garantit pas
Ces modules sont expérimentaux par nature : leur comportement peut évoluer, voire disparaître, avant leur éventuelle intégration au cœur. Ils ne conviennent pas à un environnement de production critique sans une phase de test préalable en recette, ni à un site dont l’hébergeur ne supporte pas la génération d’images WebP côté serveur (le module dépend des bibliothèques GD ou Imagick disponibles).
- Activez un module à la fois, jamais plusieurs simultanément lors d’un premier test.
- Mesurez systématiquement avant et après sur les mêmes gabarits, dans les mêmes conditions réseau.
- Réservez les modules expérimentaux à un environnement de recette avant tout déploiement en production.
- Suivez les notes de version de l’extension : un module peut changer de comportement d’une mise à jour à l’autre.
Tester une fonctionnalité avant qu’elle n’arrive dans le cœur, c’est aussi l’occasion de remonter un retour utile à l’équipe qui la développe.
En résumé
Performance Lab offre un accès concret aux futures optimisations du cœur de WordPress, avec un rapport coût-bénéfice qui varie selon les modules : certains, comme la génération WebP automatique, apportent un gain mesurable immédiat ; d’autres restent plus discrets ou purement diagnostiques. La méthode de test, un module à la fois avec mesure systématique, compte autant que les modules eux-mêmes.
