Une agence pour laquelle j’interviens en revue technique m’a demandé une checklist type à faire signer aux équipes de développement avant chaque mise en production de refonte de thème. La demande venait d’un incident précis : un client avait vu son LCP passer de 1,8 à 4,1 secondes du jour au lendemain après une refonte visuelle jugée « juste esthétique » par l’équipe créative, sans qu’aucun contrôle de performance n’ait été fait avant bascule.
Voici la checklist utilisée depuis, resserrée aux points qui ont concrètement provoqué des régressions sur des projets réels. Elle ne couvre pas l’audit d’accessibilité, qui suit un protocole distinct.
1. Comparer le poids du DOM, pas seulement les images
Un thème plus « riche » visuellement ajoute souvent des conteneurs, des icônes SVG inline et des animations, ce qui alourdit le DOM sans que personne ne l’ait mesuré. Un DOM de plus de 1 500 nœuds dégrade le temps de calcul du style et impacte l’INP autant que le poids des images. Le contrôle : document.querySelectorAll('*').length exécuté dans la console sur l’ancien et le nouveau thème, sur le même gabarit d’article.
2. Vérifier les dimensions explicites sur chaque image
Depuis WordPress 5.5, l’ajout automatique des attributs width et height sur les images insérées via la bibliothèque de médias fonctionne bien, mais un nouveau thème introduit souvent de nouvelles zones d’affichage d’image (bannières, vignettes de mise en avant) où ces dimensions ne sont pas systématiquement transmises au gabarit. L’absence de dimensions explicites est la cause numéro un de régression du CLS constatée sur nos audits de refonte.
- Contrôler chaque appel à
the_post_thumbnail(): un second paramètre de taille enregistrée garantit des dimensions cohérentes - Vérifier les images de fond CSS (
background-image), qui échappent totalement au mécanisme natif de WordPress - Tester l’affichage avant chargement des polices web, qui peut décaler le texte si aucun
font-display: swapn’est défini
3. Rejouer Lighthouse sur tous les gabarits, pas seulement l’accueil
C’est l’erreur la plus commune que je corrige : valider une refonte uniquement sur la page d’accueil, alors que le gabarit d’article ou la page de catégorie concentre l’essentiel du trafic organique. La checklist impose un passage Lighthouse (ou son équivalent en ligne de commande) sur au minimum quatre gabarits : accueil, article, catégorie/archive, page de contact.
npx lighthouse https://staging.exemple.fr/mon-article/ --output=json --output-path=./rapport-article.json --only-categories=performance4. Auditer les polices web ajoutées
Un changement de charte graphique s’accompagne presque toujours d’un changement de police, souvent une police variable auto-hébergée plus lourde que l’ancienne. Contrôle : comparer le poids total des fichiers de police servis (avec l’onglet réseau filtré sur font) avant et après refonte, et vérifier qu’aucune police n’est chargée deux fois (une erreur classique quand l’ancien thème est désactivé mais que ses styles restent enregistrés dans la file d’attente).
5. Vérifier les scripts tiers réintroduits
Les refontes sont souvent l’occasion d’ajouter de nouveaux outils marketing (carte de chaleur, chat, pop-up de conversion). Chacun de ces scripts s’exécute sur le fil principal et peut dégrader l’INP. Contrôle : lister tous les scripts chargés via wp_enqueue_script() sans l’attribut defer ou async, avec une requête simple sur les handles enregistrés.
6. Contrôler le cache et la compression après bascule
Une refonte s’accompagne souvent d’un changement d’extension de cache ou de configuration serveur, et il arrive que la compression Gzip/Brotli ou l’en-tête de cache navigateur se perde dans la manipulation. Contrôle : vérifier l’en-tête content-encoding et cache-control sur les ressources statiques du nouveau thème.
7. Mesurer sur un échantillon d’URL réelles, pas une seule page de test
Je refuse systématiquement de valider une refonte sur une seule URL de démonstration : le rendu réel varie selon la longueur du contenu, le nombre d’images et la présence ou non d’une vidéo intégrée.
La checklist impose un échantillon d’au moins huit URL représentatives de la diversité éditoriale réelle du site avant signature du bon pour production.
En résumé
Une refonte de thème n’est jamais « juste esthétique » du point de vue des Core Web Vitals. Les sept points de cette checklist, testés sur un échantillon réel et pas sur une seule page vitrine, ont évité depuis leur mise en place toute régression majeure constatée après mise en production sur les projets suivis par cette agence.
