Core Web Vitals : guide pratique pour améliorer LCP, FID et CLS

Comprendre les Core Web Vitals en 2026

En douze ans de développement web freelance, j’ai vu Google modifier ses critères de classement des dizaines de fois. Mais rarement un signal de ranking a été aussi concret et mesurable que les Core Web Vitals. Introduits en 2020, ils sont devenus un facteur de classement officiel en juin 2021 avec la mise à jour Page Experience. Depuis, ils n’ont cessé de gagner en importance.

Les Core Web Vitals se résument à trois métriques fondamentales qui couvrent les trois piliers de l’expérience utilisateur sur le web :

• LCP (Largest Contentful Paint) : mesure la vitesse de chargement perçue. Il correspond au moment où le plus grand élément visible dans le viewport (souvent une image hero ou un bloc de texte) est rendu à l’écran.
• CLS (Cumulative Layout Shift) : mesure la stabilité visuelle. Il quantifie les décalages de mise en page inattendus qui surviennent pendant le chargement de la page.
• INP (Interaction to Next Paint) : mesure la réactivité. Introduit en remplacement du FID (First Input Delay) en mars 2024, l’INP évalue le délai entre une interaction utilisateur (clic, touche, tap) et la mise à jour visuelle qui en résulte.

Pourquoi le FID a-t-il été remplacé ? Le FID ne mesurait que la première interaction, ce qui ne reflétait pas l’ensemble de l’expérience utilisateur. L’INP, lui, prend en compte toutes les interactions sur la durée de la visite, ce qui donne une image bien plus fidèle de la réactivité réelle perçue par vos visiteurs.

Seuils officiels des Core Web Vitals (Google, 2026)

Métrique	Bon (vert)	À améliorer (orange)	Mauvais (rouge)	Ce qu’elle mesure
LCP	≤ 2,5 s	2,5 s – 4,0 s	> 4,0 s	Vitesse de chargement perçue
CLS	≤ 0,1	0,1 – 0,25	> 0,25	Stabilité visuelle de la mise en page
INP	≤ 200 ms	200 ms – 500 ms	> 500 ms	Réactivité aux interactions utilisateur

Pour qu’une page soit considérée comme ayant de « bons » Core Web Vitals, elle doit atteindre le seuil vert pour les trois métriques, sur au moins 75 % des visites réelles (données de terrain, ou « field data »). C’est un point crucial : les données de laboratoire (Lighthouse) ne comptent pas directement pour le classement Google.

Comment mesurer vos Core Web Vitals

Avant d’optimiser quoi que ce soit, il faut mesurer. J’ai vu trop de développeurs se lancer dans des optimisations à l’aveugle, sans savoir quelle métrique posait réellement problème. Voici les outils que j’utilise quotidiennement :

Google Search Console (données de terrain)

C’est votre source de vérité. Le rapport « Expérience sur la page » (anciennement « Signaux Web essentiels ») dans la Search Console affiche les performances réelles de vos pages, basées sur les données du Chrome User Experience Report (CrUX). Il classe vos URLs en trois catégories : bonnes, à améliorer, mauvaises.

La limite : il faut un minimum de trafic pour que Google ait suffisamment de données. Pour les sites récents, vous devrez vous appuyer sur d’autres outils en complément.

PageSpeed Insights (lab + terrain)

L’outil PageSpeed Insights combine les données de terrain (CrUX, quand elles existent) et les données de laboratoire (Lighthouse). C’est l’outil le plus complet pour un diagnostic rapide. Il vous donne un score de 0 à 100, un détail par métrique, et surtout des recommandations concrètes classées par impact estimé.

Lighthouse (audit en local)

Intégré aux DevTools de Chrome (onglet Lighthouse), il permet de lancer un audit complet en local ou sur un serveur de staging. Attention : les scores Lighthouse varient selon votre machine, votre connexion et les extensions installées. Utilisez le mode incognito, fermez les autres onglets et lancez plusieurs audits pour obtenir une moyenne fiable.

Web Vitals Extension (monitoring temps réel)

L’extension Chrome « Web Vitals » affiche en temps réel les trois métriques CWV pendant votre navigation. Très utile pour identifier les pages problématiques lors d’un audit manuel.

API Performance Observer (monitoring custom)

Pour un suivi continu sur votre site en production, vous pouvez utiliser la bibliothèque web-vitals de Google pour collecter les métriques côté client et les envoyer vers votre analytics :

import {onLCP, onCLS, onINP} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });
  navigator.sendBeacon('/api/vitals', body);
}

onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);

Mon conseil : commencez toujours par la Search Console pour identifier les pages qui posent réellement problème en production, puis utilisez PageSpeed Insights pour obtenir des recommandations détaillées. Les outils de lab (Lighthouse, DevTools) servent ensuite à valider vos correctifs avant déploiement.

Optimiser le LCP : chargement rapide du contenu principal

Le LCP est souvent la métrique la plus problématique, notamment sur mobile. D’après mon expérience, environ 60 % des sites que j’audite échouent sur le LCP avant toute optimisation. La bonne nouvelle : les correctifs sont généralement bien identifiés et très efficaces.

Identifier l’élément LCP

La première étape consiste à identifier quel élément constitue le LCP de votre page. Dans les DevTools Chrome, onglet Performance, lancez un enregistrement et cherchez l’événement « Largest Contentful Paint ». Vous verrez l’élément HTML correspondant. C’est souvent :

• Une image hero (cas le plus fréquent)
• Un bloc de texte <h1> ou un paragraphe volumineux
• Une vidéo en arrière-plan
• Une image de fond CSS (background-image)

Optimiser les images (impact majeur)

Si votre élément LCP est une image, voici la checklist que j’applique systématiquement :

Format moderne : convertissez vos images en WebP ou AVIF. Le gain de poids est considérable (30 à 50 % par rapport au JPEG, 80 % par rapport au PNG) sans perte de qualité perceptible.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="630"
       fetchpriority="high" decoding="async">
</picture>

Attribut fetchpriority= »high » : cet attribut indique au navigateur de prioriser le téléchargement de l’image LCP. C’est un gain rapide et significatif, supporté par tous les navigateurs modernes depuis 2023.

Preload de l’image LCP : pour aller encore plus loin, ajoutez un <link rel="preload"> dans le <head> :

<link rel="preload" as="image" href="hero.webp" type="image/webp"
      fetchpriority="high">

Dimensions explicites : spécifiez toujours width et height sur vos images. Cela permet au navigateur de réserver l’espace avant le chargement, ce qui améliore à la fois le LCP et le CLS.

Dimensionnement approprié : ne servez pas une image de 3000 px sur un viewport de 375 px. Utilisez srcset et sizes pour servir la bonne taille :

<img src="hero-800.webp"
     srcset="hero-400.webp 400w,
             hero-800.webp 800w,
             hero-1200.webp 1200w"
     sizes="(max-width: 768px) 100vw, 1200px"
     alt="Description" width="1200" height="630"
     fetchpriority="high">

Optimiser le texte LCP

Si votre élément LCP est un bloc de texte (ce qui est fréquent sur les pages sans image hero), le principal levier est le chargement des polices. Un texte rendu avec une police web qui arrive tardivement retarde le LCP. J’y reviens en détail dans la section sur les polices.

Maîtriser le CLS : stabilité visuelle de vos pages

Le CLS mesure les décalages de mise en page inattendus. Vous connaissez la situation : vous êtes en train de lire un article, vous allez cliquer sur un lien, et soudain tout se décale parce qu’une publicité ou une image vient de se charger. C’est exactement ce que le CLS pénalise.

Les causes les plus fréquentes de CLS

Voici les problèmes que je rencontre le plus souvent lors de mes audits :

• Images sans dimensions : le navigateur ne connaît pas la taille de l’image avant son chargement et ne peut pas réserver l’espace.
• Publicités et iframes dynamiques : les espaces publicitaires qui s’insèrent dans le flux sans réservation préalable.
• Polices web (FOUT/FOIT) : le changement de police entre la police système et la police web provoque un repositionnement du texte.
• Contenu injecté dynamiquement : des éléments ajoutés au DOM après le chargement initial (bannières cookies, popups, barres de notification).
• Animations CSS non composites : des animations qui modifient width, height, top ou left au lieu d’utiliser transform.

Correctifs concrets pour le CLS

Réserver l’espace pour les images :

/* Ratio d'aspect automatique via les attributs HTML */
img {
  max-width: 100%;
  height: auto;
}

/* Ou via aspect-ratio CSS pour les conteneurs */
.hero-wrapper {
  aspect-ratio: 16 / 9;
  overflow: hidden;
}

/* Réserver l'espace pour les iframes (pub, vidéo) */
.ad-slot {
  min-height: 250px;
  width: 100%;
}

Polices web sans décalage :

@font-face {
  font-family: 'MaPolice';
  src: url('mapolice.woff2') format('woff2');
  font-display: swap;
  /* swap : affiche la police système immédiatement,
     puis bascule quand la web font est prête */
}

/* Alternative : optional (pas de changement si la police
   n'est pas chargée assez vite) */
@font-face {
  font-family: 'MaPoliceSecondaire';
  src: url('secondaire.woff2') format('woff2');
  font-display: optional;
}

Bannières et contenus dynamiques : réservez toujours un espace fixe pour les éléments qui apparaissent après le chargement. Pour une bannière cookie, utilisez une position fixed ou sticky qui ne décale pas le contenu existant.

Animations performantes : utilisez exclusivement transform et opacity pour vos animations. Ces propriétés sont gérées par le GPU et ne provoquent pas de reflow :

/* Mauvais : provoque un CLS */
.element {
  transition: top 0.3s, left 0.3s;
}

/* Bon : aucun impact sur le CLS */
.element {
  transition: transform 0.3s, opacity 0.3s;
  will-change: transform;
}

Améliorer l’INP : réactivité aux interactions

L’INP (Interaction to Next Paint) est la métrique la plus récente et souvent la moins bien comprise. Elle mesure le temps entre une interaction utilisateur (clic, touche clavier, tap sur mobile) et le moment où le navigateur affiche la mise à jour visuelle correspondante.

Contrairement au FID qui ne mesurait que le délai de la première interaction, l’INP prend en compte toutes les interactions tout au long de la visite. La valeur rapportée correspond au pire percentile (p98 en réalité, pour exclure les outliers).

Les causes d’un mauvais INP

• JavaScript lourd sur le thread principal : des scripts qui bloquent le thread principal pendant plus de 50 ms (les fameuses « long tasks »).
• Gestionnaires d’événements coûteux : des handlers de clic ou de scroll qui effectuent des calculs lourds ou des manipulations DOM massives.
• Scripts tiers : analytics, chat en ligne, publicités, widgets sociaux qui monopolisent le thread principal.
• Frameworks JS non optimisés : React, Vue ou Angular avec des re-renders inutiles ou des composants trop volumineux.

Optimiser l’INP en pratique

Différer les tâches lourdes avec requestIdleCallback ou scheduler.yield() :

// Découper une tâche longue en morceaux
async function processLargeList(items) {
  for (const item of items) {
    processItem(item);
    // Rendre la main au navigateur entre chaque item
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield();
    }
  }
}

// Alternative avec requestIdleCallback
function deferNonCriticalWork(callback) {
  if ('requestIdleCallback' in window) {
    requestIdleCallback(callback, { timeout: 2000 });
  } else {
    setTimeout(callback, 100);
  }
}

Optimiser les gestionnaires d’événements :

// Mauvais : manipulation DOM synchrone lourde
button.addEventListener('click', () => {
  const results = heavyComputation(data);
  container.innerHTML = renderResults(results);
});

// Bon : feedback visuel immédiat, calcul différé
button.addEventListener('click', () => {
  // Feedback immédiat
  button.textContent = 'Chargement...';
  button.disabled = true;

  // Calcul différé
  requestAnimationFrame(() => {
    const results = heavyComputation(data);
    container.innerHTML = renderResults(results);
    button.textContent = 'Rechercher';
    button.disabled = false;
  });
});

Débouncer les événements fréquents : pour les handlers de scroll, resize ou input, utilisez un debounce ou un throttle pour limiter la fréquence d’exécution.

Optimisation côté serveur : TTFB, cache et CDN

Le TTFB (Time to First Byte) n’est pas un Core Web Vital en soi, mais il impacte directement le LCP. Si votre serveur met 2 secondes à répondre, votre LCP ne pourra jamais descendre sous 2,5 secondes. C’est mathématique.

Réduire le TTFB

D’après mes audits, un TTFB acceptable se situe sous 800 ms, et un bon TTFB sous 200 ms. Voici les leviers :

Cache serveur : pour WordPress, un cache objet (Redis, Memcached) combiné à un cache page (Nginx FastCGI cache, Varnish) fait des miracles. Sur mes propres sites, le passage de PHP dynamique à Nginx FastCGI cache a réduit le TTFB de 1,2 s à 45 ms.

# Nginx FastCGI cache (configuration minimale)
fastcgi_cache_path /var/cache/nginx levels=1:2
    keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ .php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

CDN (Content Delivery Network) : un CDN comme Cloudflare, Bunny ou KeyCDN place vos ressources statiques (images, CSS, JS) sur des serveurs répartis dans le monde. Résultat : un visiteur à Marseille charge vos images depuis un serveur à Marseille, pas depuis votre VPS à Paris. Le gain est d’autant plus important sur mobile, où la latence réseau est plus élevée.

Compression : activez Brotli (ou Gzip en fallback) pour compresser les réponses HTML, CSS et JS. Brotli offre 15 à 20 % de compression supplémentaire par rapport à Gzip.

# Nginx Brotli
brotli on;
brotli_types text/html text/css application/javascript application/json;
brotli_comp_level 6;

HTTP/2 et HTTP/3 : assurez-vous que votre serveur supporte HTTP/2 au minimum (multiplexage des requêtes sur une seule connexion TCP). HTTP/3 (QUIC) améliore encore les performances sur les connexions instables, fréquentes en mobile.

Headers de cache navigateur

Configurez des headers Cache-Control appropriés pour que les ressources statiques soient mises en cache par le navigateur :

# Nginx : cache longue durée pour les ressources statiques
location ~* .(js|css|png|jpg|jpeg|gif|webp|avif|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

CSS et JavaScript : le chemin critique du rendu

Le CSS et le JavaScript sont les deux principaux responsables du blocage du rendu (render-blocking). Un fichier CSS de 200 Ko ou un bundle JS de 500 Ko chargé dans le <head> retarde directement le LCP.

Optimiser le CSS

CSS critique en ligne : extrayez le CSS nécessaire au rendu au-dessus de la ligne de flottaison (above the fold) et injectez-le directement dans le <head> via une balise <style>. Le reste du CSS est chargé de manière asynchrone :

<head>
  <!-- CSS critique inline -->
  <style>
    /* Uniquement le CSS pour le viewport initial */
    body { font-family: Inter, sans-serif; margin: 0; }
    .header { background: #0F172A; color: #fff; }
    .hero { max-width: 1200px; margin: 0 auto; }
  </style>

  <!-- CSS non-critique chargé en async -->
  <link rel="preload" href="style.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="style.css"></noscript>
</head>

Minification : minifiez vos fichiers CSS en production. Un outil comme cssnano ou lightningcss réduit la taille de 20 à 40 %.

Supprimer le CSS inutilisé : des outils comme PurgeCSS ou le Coverage Panel des DevTools Chrome vous permettent d’identifier et supprimer le CSS mort. Sur un site WordPress avec un thème premium, il n’est pas rare de trouver 70 à 80 % de CSS inutilisé.

Optimiser le JavaScript

Attributs defer et async : tout script non critique doit être chargé avec defer (exécuté après le parsing HTML, dans l’ordre) ou async (exécuté dès que téléchargé, sans garantie d’ordre) :

<!-- Script critique : dans le head, defer -->
<script src="app.js" defer></script>

<!-- Script non critique : async ou en fin de body -->
<script src="analytics.js" async></script>

<!-- Scripts tiers : chargement différé -->
<script>
  // Charger le chat uniquement après interaction utilisateur
  window.addEventListener('scroll', function loadChat() {
    const s = document.createElement('script');
    s.src = 'https://chat-widget.com/loader.js';
    document.body.appendChild(s);
    window.removeEventListener('scroll', loadChat);
  }, { once: true });
</script>

Code splitting : si vous utilisez un bundler (Webpack, Vite, Rollup), découpez votre code en chunks chargés à la demande. Chaque page ne doit charger que le JavaScript dont elle a réellement besoin.

Tree shaking : importez uniquement les fonctions dont vous avez besoin, pas des bibliothèques entières :

// Mauvais : importe toute la bibliothèque (300 Ko)
import _ from 'lodash';
_.debounce(fn, 300);

// Bon : importe uniquement la fonction (4 Ko)
import debounce from 'lodash/debounce';
debounce(fn, 300);

Polices web

Les polices web sont souvent un facteur sous-estimé du LCP. Voici ma méthode :

<!-- Preconnect au serveur de polices -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Preload de la police principale (woff2 uniquement) -->
<link rel="preload" as="font" type="font/woff2"
      href="/fonts/inter-v12-latin-regular.woff2" crossorigin>

<!-- font-display: swap ou optional -->

Mon conseil : hébergez vos polices localement plutôt que d’utiliser Google Fonts. Vous économisez une connexion DNS + TLS, et vous contrôlez le cache. L’outil google-webfonts-helper facilite le téléchargement et la génération du CSS.

Lazy loading et preload : charger au bon moment

L’art de l’optimisation web, c’est de charger chaque ressource exactement au bon moment. Ni trop tôt (gaspillage de bande passante), ni trop tard (dégradation de l’expérience).

Lazy loading natif

L’attribut loading="lazy" est supporté nativement par tous les navigateurs modernes. Il retarde le chargement des images et iframes hors du viewport initial :

<!-- Image DANS le viewport : NE PAS lazy-loader -->
<img src="hero.webp" alt="..." width="1200" height="630"
     fetchpriority="high">

<!-- Image HORS du viewport : lazy load -->
<img src="illustration.webp" alt="..." width="800" height="450"
     loading="lazy" decoding="async">

<!-- Iframe (vidéo, carte) : toujours lazy -->
<iframe src="https://www.youtube.com/embed/..." loading="lazy"
        width="560" height="315"></iframe>

Règle d’or : ne mettez jamais loading="lazy" sur votre image LCP (celle au-dessus de la ligne de flottaison). C’est contre-productif : vous retarderiez le chargement de l’élément le plus important de la page.

Preload, prefetch, preconnect

Ces trois directives de priorité servent des usages distincts :

• preload : charge une ressource nécessaire à la page actuelle, avec haute priorité. À utiliser pour l’image LCP, la police principale, le CSS critique.
• prefetch : charge une ressource qui sera probablement nécessaire lors de la navigation suivante, avec basse priorité. À utiliser pour les pages les plus probables (page suivante d’une pagination, par exemple).
• preconnect : établit la connexion (DNS + TCP + TLS) vers un domaine tiers, sans télécharger de ressource. À utiliser pour les CDN, les domaines de polices, les APIs tierces.

<head>
  <!-- Preconnect aux domaines tiers critiques -->
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>

  <!-- Preload de l'image LCP -->
  <link rel="preload" as="image" href="hero.webp"
        type="image/webp" fetchpriority="high">

  <!-- Prefetch de la page suivante probable -->
  <link rel="prefetch" href="/page-2/">
</head>

Attention à ne pas abuser du preload. Chaque preload consomme de la bande passante et peut retarder d’autres ressources. Limitez-vous à 2 ou 3 preloads maximum par page.

Checklist complète d’optimisation CWV

Voici la checklist que j’utilise pour chaque projet client. Elle couvre les trois métriques et les optimisations les plus impactantes, classées par priorité :

Checklist d’optimisation Core Web Vitals par priorité

Priorité	Action	Métrique ciblée	Impact estimé	Difficulté
1	Activer le cache serveur (FastCGI, Redis)	LCP	Très élevé	Moyenne
2	Optimiser et compresser les images (WebP/AVIF)	LCP	Très élevé	Faible
3	Ajouter width/height sur toutes les images	CLS	Élevé	Faible
4	Preload de l’image LCP + fetchpriority= »high »	LCP	Élevé	Faible
5	Defer/async sur tous les scripts non critiques	LCP, INP	Élevé	Faible
6	Héberger les polices localement + font-display: swap	LCP, CLS	Moyen	Faible
7	Activer Brotli/Gzip	LCP	Moyen	Faible
8	Lazy loading natif sur images/iframes hors viewport	LCP (indirect)	Moyen	Faible
9	Mettre en place un CDN	LCP	Moyen à élevé	Moyenne
10	Extraire le CSS critique en inline	LCP	Moyen	Moyenne
11	Supprimer le CSS/JS inutilisé	LCP, INP	Moyen	Moyenne
12	Réserver l’espace pour les pubs/iframes	CLS	Moyen	Faible
13	Découper les long tasks JS (yield/rAF)	INP	Élevé	Élevée
14	Différer les scripts tiers (analytics, chat)	INP, LCP	Moyen	Moyenne
15	Activer HTTP/2 ou HTTP/3	LCP	Moyen	Faible

Mon conseil : n’essayez pas de tout faire en une fois. Commencez par les cinq premières actions, mesurez l’impact, puis passez à la suite. Les gains les plus importants viennent presque toujours du cache serveur et de l’optimisation des images.

FAQ : questions fréquentes sur les Core Web Vitals

{ « @context »: « https://schema.org », « @type »: « FAQPage », « mainEntity »: [ { « @type »: « Question », « name »: « Les Core Web Vitals sont-ils un facteur de classement important en 2026 ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Oui, les Core Web Vitals restent un signal de classement officiel de Google. Cependant, il ne faut pas surestimer leur poids par rapport au contenu et aux backlinks. En pratique, les CWV font la différence entre deux pages de qualité comparable. Si votre contenu est excellent mais vos CWV sont mauvais, vous ne serez pas fortement pénalisé. En revanche, si deux pages se valent en contenu, celle avec de meilleurs CWV sera favorisée. » } }, { « @type »: « Question », « name »: « Quelle est la différence entre données de terrain (field) et données de laboratoire (lab) ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Les données de terrain proviennent d’utilisateurs réels qui visitent votre site avec Chrome (collectées via le Chrome User Experience Report). Les données de laboratoire sont produites par des outils comme Lighthouse dans un environnement contrôlé. Google utilise exclusivement les données de terrain pour le classement. » } }, { « @type »: « Question », « name »: « Le FID existe-t-il encore ou a-t-il été complètement remplacé par l’INP ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Le FID (First Input Delay) a été officiellement remplacé par l’INP (Interaction to Next Paint) en mars 2024. Le FID n’est plus un Core Web Vital et n’est plus utilisé comme signal de classement. L’INP est plus exigeant car il mesure toutes les interactions de la visite, pas seulement la première. » } }, { « @type »: « Question », « name »: « Comment améliorer le LCP sur un site WordPress sans compétences techniques ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Trois actions accessibles à tous : installez un plugin d’optimisation d’images comme EWWW ou ShortPixel, activez un plugin de cache comme WP Super Cache, et utilisez un CDN gratuit comme Cloudflare. Ces trois mesures suffisent souvent à passer sous les 2,5 secondes de LCP. » } }, { « @type »: « Question », « name »: « Un score Lighthouse de 100 garantit-il de bons Core Web Vitals en production ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Non, absolument pas. Le score Lighthouse est mesuré en conditions de laboratoire. En production, vos visiteurs utilisent des appareils et des connexions très différentes. Fiez-vous aux données de la Search Console plutôt qu’aux scores Lighthouse. » } }, { « @type »: « Question », « name »: « Comment diagnostiquer la cause exacte d’un mauvais CLS sur une page ? », « acceptedAnswer »: { « @type »: « Answer », « text »: « Ouvrez les DevTools Chrome, onglet Performance, et activez l’option Layout Shift Regions. Rechargez la page : les zones qui se décalent seront surlignées en bleu. Vous pouvez aussi utiliser l’onglet Performance Insights qui identifie directement les éléments responsables du CLS. » } } ] }

Articles liés

• Comparatif hébergeur web 2026 : quel impact sur les performances
• Combien coûte un site internet : budget et optimisations
• Diagnostic de performance web : testez votre site gratuitement

Ressources externes de référence

• Web Vitals : métriques essentielles pour un site sain (web.dev, documentation officielle Google)
• Core Web Vitals et classement Google (Google Search Central)