Symptôme : le rapport Search Console d’un site associatif signalait, semaine après semaine, une majorité de pages classées en « Nécessite une amélioration » sur le critère CLS, alors que le contenu lui-même n’affichait ni image ni publicité problématique à l’œil nu. Le score moyen relevé dans le rapport d’expérience sur le terrain dépassait 0,3, loin du seuil recommandé de 0,1.
Ce type d’écart entre une observation visuelle qui semble normale et un score dégradé pointe presque toujours vers un élément qui apparaît après le premier rendu de la page, sans que l’espace qu’il occupera ait été réservé à l’avance.
Diagnostic : localiser l’élément responsable
L’onglet Performance des Chrome DevTools, en enregistrant le chargement complet d’une page, affiche une section dédiée aux décalages de mise en page (« Layout Shifts »), avec pour chacun l’élément DOM précis impliqué et le score de décalage associé. Sur ce site, un seul événement expliquait la quasi-totalité du score CLS mesuré : l’apparition du bandeau de consentement RGPD, injecté par un script tiers environ 800 millisecondes après le chargement initial de la page.
Ce bandeau s’affichait en bas de page dans une bannière fixe, mais son insertion dans le DOM ajoutait une marge basse au corps de la page via un script JavaScript qui modifiait dynamiquement le padding-bottom du body, provoquant un décalage vertical de tout le contenu visible à ce moment précis.
Pourquoi le report du script aggrave le problème
Le script de consentement était volontairement chargé de façon différée, après les scripts jugés plus prioritaires, dans un souci louable de ne pas retarder l’affichage initial. Ce choix, pertinent pour le LCP, se retournait contre le CLS : plus un élément apparaît tard après le premier rendu, plus il a de chances de décaler du contenu que l’utilisateur a déjà commencé à lire ou avec lequel il a peut-être déjà commencé à interagir.
Correctif : réserver l’espace en CSS
Plutôt que d’accélérer le chargement du script, ce qui aurait simplement déplacé le problème plus tôt sans le résoudre, le correctif a consisté à réserver dès le premier rendu, via CSS pur, l’espace que le bandeau occuperait une fois affiché :
body {
padding-bottom: 64px;
}
#bandeau-consentement {
position: fixed;
bottom: 0;
left: 0;
right: 0;
min-height: 64px;
}Cette marge basse est désormais présente dès le premier rendu, que le script de consentement ait déjà chargé le bandeau ou non. Quand le bandeau apparaît ensuite, il occupe un espace déjà réservé et ne provoque plus aucun décalage du contenu au-dessus de lui.
Un ajustement complémentaire a consisté à fixer une hauteur minimale identique en CSS sur le conteneur du bandeau lui-même, pour les cas où son contenu textuel varie selon la langue du visiteur, certaines traductions étant plus longues que d’autres et risquant de faire varier la hauteur réelle du bandeau une fois affiché.
Vérification après correctif
Après déploiement, le score CLS mesuré en laboratoire avec Lighthouse est passé de 0,34 à 0,02. Les données de terrain remontées dans Search Console ont confirmé l’amélioration après une quinzaine de jours, délai habituel pour que le rapport d’expérience se mette à jour avec suffisamment de visites réelles.
- Vérifier le CLS avec les DevTools avant toute hypothèse, plutôt que de deviner l’origine du décalage.
- Réserver l’espace en CSS pur, sans dépendre du moment où un script tiers s’exécute.
- Tester sur plusieurs langues ou variantes de contenu si le texte de l’élément différé peut varier en longueur.
Ce que ce correctif ne couvre pas
Ce cas ne traite pas les décalages provoqués par des publicités ou des vidéos intégrées, qui suivent une logique de réservation d’espace différente, notamment via l’attribut aspect-ratio plutôt qu’une marge fixe. Le principe reste toutefois le même : anticiper la place d’un élément avant qu’il n’apparaisse, plutôt que de laisser le navigateur recalculer la mise en page après coup.
En résumé
Un bandeau de consentement RGPD différé est une cause fréquente et sous-estimée de mauvais score CLS sur les sites WordPress soumis au RGPD. La solution ne demande ni extension supplémentaire ni changement de stratégie de chargement, seulement quelques lignes de CSS qui réservent l’espace dès le premier rendu de la page.
