Les trois Core Web Vitals en 2026

Google mesure trois métriques de terrain principales pour l'expérience de page. Chacune a un seuil pour une performance "Bonne" :

• Largest Contentful Paint (LCP) — délai de rendu du plus grand élément visible. Bon : inférieur à 2,5 secondes.
• Interaction to Next Paint (INP) — réactivité à toutes les interactions utilisateur (a remplacé FID en mars 2024). Bon : inférieur à 200 ms.
• Cumulative Layout Shift (CLS) — stabilité visuelle pendant le chargement. Bon : inférieur à 0,1.

Une bannière de consentement qui bloque le rendu, exécute du JavaScript lourd au chargement, ou injecte des changements de mise en page tardifs peut pousser l'un de ces scores dans la zone "Doit être amélioré" ou "Mauvais" — et Google utilise des données de terrain sur 28 jours provenant de vrais utilisateurs Chrome, de sorte que les problèmes transitoires deviennent des signaux de classement persistants.

Comment les bannières de consentement nuisent au LCP

Le Largest Contentful Paint se déclenche généralement sur une image principale ou un titre. Plusieurs modèles de consentement le retardent inutilement :

Scripts CMP bloquant le rendu

Charger le CMP de manière synchrone depuis l'en-tête du document arrête l'analyse HTML jusqu'à ce que le script soit téléchargé et exécuté. Si le CMP est hébergé sur un CDN lent ou en cache froid, vous pouvez ajouter 200 à 800 ms au LCP globalement.

Bannière couvrant l'image principale

Si la bannière de consentement est positionnée comme une superposition modale couvrant l'élément LCP, les navigateurs mesureront quand même le LCP à partir de l'élément couvert. Cependant, si la bannière est le plus grand élément peint, elle devient le candidat LCP — et si elle est rendue via JavaScript après le chargement de la page, le LCP est artificiellement élevé.

Correction : chargement asynchrone avec un petit bootstrap inline

Chargez le CMP complet de manière asynchrone (`async` ou `defer`), avec seulement un petit script inline pour l'affichage initial de la bannière. Visez un bootstrap inférieur à 5 Ko compressé. La logique de comportement complète, les listes de fournisseurs et le chrome de l'interface peuvent se charger de façon différée après la première peinture.

Comment les bannières de consentement nuisent à l'INP

L'Interaction to Next Paint mesure le pire temps de réponse sur tous les clics, tapotements et pressions de touches pendant une session. Les interactions de consentement aux cookies sont souvent la première interaction d'un utilisateur — donc un bouton Accepter lent ruine le score.

Travail lourd sur l'acceptation

De nombreux CMP exécutent un travail synchrone sur l'acceptation : chargement de plus de 40 scripts de fournisseurs, écriture dans localStorage, déclenchement d'événements dataLayer, activation des mises à jour du mode de consentement Google. Si cela dépasse 200 ms, l'INP en souffre.

Correction : mettre le travail en file d'attente après la peinture

Au clic Accepter, masquez immédiatement la bannière et planifiez le travail lourd avec `requestIdleCallback` ou `setTimeout(0)`. L'utilisateur voit la bannière disparaître instantanément ; les scripts des fournisseurs se chargent en arrière-plan sans bloquer l'interaction.

Comment les bannières de consentement nuisent au CLS

Le Cumulative Layout Shift suit les mouvements visuels inattendus. Les bannières sont une source classique de CLS lorsqu'elles sont injectées dans le DOM après que le contenu a été peint.

Injection tardive de la bannière

Si la bannière apparaît 800 ms après le LCP, elle pousse le contenu vers le bas et génère un changement de mise en page. Même une petite bannière peut déclencher un score CLS supérieur à 0,1 si elle affecte une grande partie de la fenêtre d'affichage.

Nouveau rendu du widget de préférences de cookies

Les widgets de préférences de pied de page qui chargent les logos des fournisseurs de manière asynchrone peuvent refluer l'ensemble du pied de page plusieurs fois, aggravant le CLS.

Correction : réserver l'espace dès le départ

Utilisez CSS pour réserver l'espace de la bannière dès la toute première peinture — espace réservé à hauteur fixe, `min-height` sur le pied de page, ou une bannière fixée en bas qui ne pousse pas le contenu. Les CMP modernes devraient proposer une configuration sans CLS prête à l'emploi.

Google Consent Mode V2 et performances

Le Consent Mode V2 permet aux balises Google de s'exécuter dans un état sans cookies avant le consentement, en transmettant des signaux via `gtag('consent', 'default', {...})`. C'est idéal pour la continuité de la mesure, mais la bibliothèque gtag.js elle-même pèse 50 à 90 Ko. Chargez-la de manière asynchrone et définissez les valeurs par défaut aussi tôt que possible pour éviter les conditions de course.

• Définir les valeurs par défaut avant le chargement de gtag — placez l'appel de consentement par défaut dans l'en-tête, avant le script gtag.js.
• Utiliser `analytics_storage: 'denied'` par défaut — minimise les données collectées avant le consentement.
• Mettre à jour lors de l'acceptation via requestIdleCallback — évitez de bloquer le thread principal.

Mesurer l'impact du CMP sur les Core Web Vitals

Ne supposez pas — mesurez. Utilisez ces outils pour quantifier l'impact de votre bannière :

• PageSpeed Insights — données de terrain du rapport Chrome UX plus audit Lighthouse en laboratoire. Comparez les scores avec et sans le script CMP.
• Extension Chrome Web Vitals — superposition LCP, INP, CLS en temps réel lors des tests locaux.
• WebPageTest.org — vue en pellicule et cascade montrant exactement quand la bannière s'affiche et ce qu'elle bloque.
• Rapport Core Web Vitals de la Search Console — données de terrain sur 28 jours regroupées par modèle d'URL. Vérifiez si les pages de destination avec votre bannière obtiennent des scores différents des pages sans bannière.

Comment FlexyConsent reste rapide