# Checklist Core Web Vitals pour un site WordPress avant refonte de thème

> Avant de valider une refonte de thème, une série de contrôles Core Web Vitals évite de découvrir la régression une fois le site en production.

- Auteur : Clément Hadrot
- Publié le : 2022-09-27
- Mis à jour le : 2022-09-27
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/checklist-core-web-vitals-avant-refonte-theme/

## L’essentiel

- Comparer le poids du DOM avant/après, pas seulement les images
- Vérifier les dimensions explicites sur chaque bloc image et intégration
- Rejouer Lighthouse sur les gabarits, pas seulement la page d'accueil

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

> L'essentiel à retenir : Comparer le poids du DOM avant/après, pas seulement les images ; Vérifier les dimensions explicites sur chaque bloc image et intégration ; Rejouer Lighthouse sur les gabarits, pas seulement la page d'accueil

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: swap` n'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=performance
```

## 4. 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.