Mis à jour le 12/06/2026
Les Core Web Vitals (Signaux Web Essentiels en français) sont des indicateurs de performance d’un site web, développés par Google. Ils servent à mesurer la vitesse d’affichage, la stabilisation visuelle et l’interactivité d’une page au moment où un utilisateur arrive dessus.
Ils offrent ainsi une analyse plus fine des temps de chargement d’un site internet.
| Indicateur | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP | < 2,5 s | 2,5 – 4 s | > 4 s |
| INP | < 200 ms | 200 – 500 ms | > 500 ms |
| CLS | < 0,1 | 0,1 – 0,25 | > 0,25 |
Quels indicateurs constituent les Core Web Vitals ?
Les Core Web Vitals sont au nombre de trois. Ils ont été définis en fonction de leur impact direct sur l’expérience utilisateur.
Largest Contentful Paint (LCP) : affichage du contenu général
Le Largest Contentful Paint (LCP) désigne le temps d’affichage que requiert le plus grand élément visible dans la fenêtre d’affichage (image ou bloc de texte principal) et qui ne nécessite pas de faire défiler pour apparaître à l’écran.
Le Largest Contentful Paint concerne principalement :
- les éléments graphiques ;
- les textes ;
- les miniatures de vidéo ;
- l’arrière-plan.
À titre indicatif, une bonne valeur LCP sera inférieure à 2,5 secondes. Entre 2,5 et 4 secondes, ce n’est pas encore une catastrophe, mais il sera judicieux de ne pas s’en contenter. Au-delà de 4 secondes, il devient urgent de faire quelque choses.
Nota Bene : à 5 secondes et plus, Google considère que la moitié des clics obtenus finiront en rebond vers le moteur de recherche.
Cumulative Layout Shift (CLS) : décalage cumulatif de mise en page
Le Cumulative Layout Shift est plus simple à comprendre qu’il n’y paraît. Il s’agit d’un indicateur de stabilité de la page, au sens où les éléments qui la constituent ne changent pas de position après un premier temps d’affichage (texte qui se masque, bouton qui se décale, image poussée vers le bas, etc.). En effet, une page qui met du temps à se stabiliser peut s’avérer très frustrante pour l’utilisateur (lecture interrompue, missclicks, etc.) !
Le CLS se mesure via un score allant de 0 à 1. Une valeur optimale sera inférieure à 0,1.
Nota Bene : dans les exemples de frustrations très communes, on a l’affichage intempestif d’une annonce publicitaire qui va déplacer du contenu ou même provoquer un clic au mauvais endroit, ce qui ouvrira une page non-désirée…
Autres metrics à connaître
Si vous vous intéressez aux Core Web Vitals, sachez que ce ne sont pas les seuls indicateurs de performances pris en compte par Google pour estimer la bonne expérience utilisateur des personnes qui ont cliqué sur une de vos URLs.
Les métriques ci-dessous complètent les Core Web Vitals et permettent d’analyser plus finement les performances de chargement et d’interactivité d’une page:
First Contentful Paint (FCP)
Le First Contentful Paint (FCP) mesure le temps nécessaire pour que le premier élément de contenu (texte, image, SVG, etc.) s’affiche à l’écran. Il donne une première indication de la vitesse de chargement perçue par l’utilisateur.
Un bon score FCP est de 1,8 secondes ou moins.
Total Blocking Time (TBT)
Le Total Blocking Time (ou temps de blocage total) mesure la somme des périodes durant lesquelles le thread principal est bloqué et ne peut pas répondre aux interactions utilisateur (au-delà de 50 millisecondes).
Cette métrique est principalement utilisée dans les outils de test comme Lighthouse et permet d’identifier les problèmes liés à l’exécution de scripts JavaScript.
Time to First Byte (TTFB)
Le Time to First Byte désigne le délai entre la requête envoyée par le navigateur et la réception du premier octet de réponse du serveur. Ce temps inclut :
- la phase de redirection ;
- l’établissement de la connexion TLS ;
- la recherche DNS ;
- le temps de traitement serveur.
Un TTFB rapide est essentiel pour garantir de bonnes performances globales, même si aucun seuil officiel strict n’est défini par Google.
Pourquoi est-il important d’optimiser les Core Web Vitals ?
En premier lieu, travailler ses Core Web Vitals (et les autres indicateurs autour), permet d’amoindrir le temps de chargement, ce qui permet aux robots d’indexation (crawlers) d’aller plus vite et d’économiser du budget crawl. Dans l’absolu, cela signifie indexer plus de pages à chacun de leur passage.
Ensuite (et surtout), il s’agit d’améliorer l’UX (User eXperience) de navigation, en rendant ce temps de chargement le plus fluide possible, afin de faire baisser le taux de rebond, lequel va doubler entre 1 et 5 secondes d’attente. Or, c’est peut-être les prospects les plus impatients qui sont les plus prompts à l’engagement et à la conversion !
Enfin, sur le strict plan du “ranking”, John Mueller rappelle qu’un contenu de qualité prime largement sur ces trois indicateurs. Ce qui signifie qu’à équivalence en authority score et en qualité des contenus, les Core Web Vitals pourront faire la différence entre deux domaines du même secteur d’activité.
Quels outils pour auditer ses Core Web Vitals ?
Plusieurs outils peuvent vous renseigner sur vos Core Web Vitals, à commencer par la plateforme PageSpeed Insights, sur laquelle vous pouvez copier-coller n’importe quelle URL valide. Ses principales alternatives sont :
- GTMetrix (gratuit) ;
- Webpagetest.org (gratuit) ;
- Fasterize (payant) ;
- Dareboost (payant).
Nous vous recommandons néanmoins d’utiliser un outil de suivi avec lequel vous avez l’habitude de travailler, comme la Google Search Console, qui embarque son propre rapport Core Web Vitals, pour version mobile comme pour desktop (ordinateur), en plus de celui dédié à l’expérience utilisateur Chrome (CrUX). Vous pouvez ainsi surveiller vos metrics par groupes d’URLs et vous aviser des optimisations propres à chaque indicateur.
Sa meilleure alternative est sans doute Lighthouse, un outil open-source qui intègre des paramètres tels que l’accessibilité et le SEO. Nous vous conseillons d’essayer en installant l’extension, que vous pourrez utiliser sur n’importe quelle page juste avec le clic droit > inspecter > Lighthouse.
Comment faire pour améliorer ses Core Web Vitals ?
En règle générale, les leviers d’optimisation concernent la partie développement de votre staff.
Quelles optimisations pour le LCP ?
Si vous remarquez une lenteur au niveau de votre LCP, vous pouvez :
- passer à un hébergeur plus rapide et/ou utiliser un CDN;
- détecter d’éventuels blocages au niveau CSS et JavaScript, et désactiver certaines balises sans conséquence sur votre site, ainsi que les scripts d’applications tierces ;
- vérifier le poids et les dimensions de vos images, les compresser et passer en Lazy Load, pour ne charger les images sous la ligne de flottaison qu’au moment du scroll ;
- activer la mise en cache pour les visiteurs déjà venus sur votre site.
Quelles optimisations pour l’INP ?
Pour minimiser le délai de première interaction avec l’internaute, vous pouvez :
- réduire JavaScript bloquant
- fractionner les longues tâches
- limiter les scripts tiers
- améliorer la gestion des événements (event handlers)
Quelles optimisations pour le CLS ?
Afin d’éviter les déplacements intempestifs de contenus, il convient de :
- gérer les scripts et animations qui retardent la stabilisation des contenus ;
- vérifier que vos blocs, textes, images, vidéos, iframes, et autres modules sont aux bonnes dimensions pour l’écran de l’utilisateur (desktop et mobile) ;
- paramétrer les encarts publicité avec des emplacements dédiés et UX friendly ;
- placer certains éléments moins importants sous la ligne de flottaison, afin qu’on ne voie pas les éléments se décaler.
Pour finir…
Les Core Web Vitals sont à la page de destination ce que les boutons sont à la chemise : ils en représentent un faible pourcentage, mais mieux vaut ne pas les négliger ! Bien sûr, on ne va pas s’y intéresser comme facteur de ranking (bien qu’ils y participent, plus ou moins directement) mais comme un critère de convivialité de la page.
À ce titre, nul besoin de passer tout votre temps sur les indicateurs chiffrés ci-dessus : naviguez vous-même sur votre site et relevez les points de friction qui surviennent pendant le temps de chargement. Ce n’est qu’ensuite que vous pourrez creuser pour lancer un chantier d’optimisations concrètes !
Comment les Core Web Vitals sont devenus un enjeu clé pour l’optimisation SEO ?
Maître en la matière, Google continue de stimuler la concurrence en modifiant régulièrement les règles du jeu SEO. Dans ses dernières actus, le célèbre moteur de recherche a ainsi fait apparaître de nouvelles cartes stratégiques pour le niveau de positionnement d’un site : les Core Web Vitals.
En quoi ce nom peut-il faire peur ?
Probablement à cause du terme “Vitals”, qui, associé à “Core” signifie “l’essentiel”. Dès lors, combien de sites risquent de tomber s’ils ne réussissent pas le test des Core Web Vitals ? On vous rassure : comme souvent, tout est histoire de contexte.
En effet, Google affiche pour objectif premier la satisfaction de ses utilisateurs. Aussi doit-il lui délivrer la meilleure réponse à ses besoins en un minimum de temps. En conséquence, le plus performant des moteurs de recherche se met constamment à jour, entraînant dans son sillage tous les sites qu’il indexe pour notre usage.
C’est donc s’astreindre au même degré d’exigence UX que Google qui permettra aux administrateurs de sites web de rester compétitif en SEO. C’est de cette savante alchimie qu’est issu le terme “SXO”.
Toutefois, les Core Web Vitals semblent davantage servir à nous mettre sur la voie que planer telles des épées de Damoclès sur le monde du web. Examinons donc leur ADN, notamment à travers les branches LCP, CLS et FID…
LCP : Largest Contentful Paint
On pourrait traduire Largest Contentful Paint par “la plus grosse partie de l’affichage du contenu”. En fait, il s’agit d’un indicateur de vitesse de chargement de la page, comme il en existait déjà plein avant lui.
Par exemple, le First Content Paint (FCP) mesure le temps qui sépare un clic de l’apparition du tout premier élément qui s’affiche sur la page.
Cependant, une telle mesure est assez peu représentative de l’expérience utilisateur. En effet, si le premier élément qui s’affiche est inutile (écran d’accueil, barre de chargement), l’internaute n’aura toujours rien à faire ni rien à lire.
C’est pourquoi il est bien meilleur de se focaliser sur le temps d’affichage de la majorité du contenu d’une page web (LCP), à savoir tout ce qui implique une interaction autre que la patience.
Car en UX, il faut toujours chercher le ressenti de l’utilisateur !
Les directives de Google pour baisser votre taux de rebond
En matière de LCP (qu’il s’agisse de textes, d’images ou encore de vidéos), Google divise les sites en trois catégories :
- Performant : le LCP est atteint au bout de 2,5 secondes ou moins ;
- Perfectible : l’affichage de la majorité du contenu prend entre 2,5 et 4 secondes ;
- Mauvais : passé le seuil des cinq secondes de chargement, Google estime que trop d’internautes auront déjà fait machine arrière face à ce point noir.
On déteste tous le dilemme de l’ascenseur qui n’arrive pas : si neuf autres ascenseurs étaient disponibles, qui n’en essaierait pas rapidement un autre ?
Appliqué au monde virtuel, c’est le fameux taux de rebond…
Quand votre ascenseur est le plus lent de tous, Google le positionnera logiquement au fond du couloir de sa SERP.
Quel genre de site web aura besoin d’une mise à jour LCP ?
En règle générale, les sites qui contiennent des pages peu lourdes, sans fonctionnalités particulières, avec une majorité de textes, devraient passer haut la main leur test LCP.
En revanche, ceux qui intègrent du contenu multimédia, des boutons d’action par douzaines et des farandoles d’animation risquent de devoir procéder à un certain nombre d’optimisations.
La taille des éléments : un facteur déterminant du traitement d’une page web
C’est mécanique : un élément lourd est plus difficile à charger, et peut donc ralentir l’affichage général. Il peut donc s’avérer productif de vous questionner sur les composants les plus lourds de votre contenu. Cela étant, il convient d’observer certains principes :
- on ne prend en compte que ce qui est directement visible par l’utilisateur. Ainsi, les débordements hors de l’écran et les fenêtres tronquées n’entrent pas en ligne de compte dans l’estimation de la taille ;
- les images redimensionnées conservent la plus petite taille entre leur format initial (taille intrinsèque) et le nouveau ;
- les passages écrits ont pour équivalent la taille de leur nœud de texte, à savoir le rectangle qui les contient ;
- on ne tient pas compte des marges ou des bordures ;
- les LCP ignorent les modifications de la taille ou de la position d’un élément. Ce qui apparaît, disparaît de la fenêtre d’affichage, ou change de dimension ne modifie donc pas la taille signalée initialement ;
Astuces techniques pour améliorer votre score LCP
Il existe plusieurs leviers relativement simples pour contrôler un peu mieux le temps d’affichage, et ainsi améliorer votre score LCP :
- vérifier la performance de son hébergeur ;
- trouver les scripts tiers inutiles et les supprimer : chacun d’eux vous fera gagner en moyenne 34 ms ;
- utiliser le “chargement paresseux”, afin que les éléments hors écran ne chargent que lorsque l’utilisateur fait défiler la page web ;
- ôter ou optimiser les éléments résolument trop lourds relativement à ce qu’ils apportent au contenu ;
- réduire son CSS (Cascading Style Sheets, c’est un langage informatique qui décrit la présentation des documents HTML et XML) et optimiser JavaScript.
Une fois que vous avez bien fait le ménage pour le LCP, vous pourrez passer au First Imput Delay…
Qu’est-ce que le First Input Delay (FID)?
Sous la traduction un peu barbare “délai de première imputation” ou plus couramment “délai de première saisie (ou entrée)”, l’on retrouve un principe amplement lié à une bonne expérience utilisateur.
En effet, la vitesse d’affichage des pixels à l’écran n’offrira qu’une satisfaction limitée sans une réactivité opérationnelle de l’interface. Car il n’est pas rare que l’utilisateur veuille interagir avec la page sans attendre qu’elle ait fini de se charger.
Dans ce cas, une trop grande latence d’entrée due à la lenteur du fil d’exécution principal voit l’internaute dépourvu de retour de ses actions. Celui-ci est donc obligé de s’interrompre sans savoir quelle saisie sera ou non prise en compte lorsque le navigateur en aura terminé avec les gros fichiers qu’il peine à traiter.
Ainsi, la plupart du temps, ce cas de figure se produit entre le FCP et le TTI (time to interactive = calcul du temps séparant le début de chargement et le moment où la page sera entièrement réactive). En d’autres termes, le FID peut survenir quand le contenu est partiellement disponible, tandis que l’interactivité reste flottante.
Il est d’ailleurs concomitant au “temps de blocage total”, qui désigne la durée entre le moment où tout le contenu d’une page est visible et celui où l’interactivité de cette dernière est entièrement disponible.
Enfin, pour imager, visualisez le comptoir d’un pub, d’où vous pouvez consulter la carte et apercevoir les bières pression, liqueurs et digestifs.
Le FID désigne l’instant où vous pouvez vous adresser au serveur sans qu’il vous ignore, trop occupé qu’il est à préparer dix mojitos d’un coup…
La première entrée : un critère plus important qu’on l’imagine
Cette mesure-là pourrait sembler un peu anodine, voire pointilleuse. Toutefois, ce serait oublier que c’est dans cette fenêtre que les internautes rencontrent le plus de retard de réactivité.
Par conséquent, conformément à la méthode UX, c’est sur les points noirs remarquables et récurrents qu’on focalise l’attention des designers et des développeurs. À ce titre, on considère qu’un FID supérieur à 100 millisecondes est déjà problématique.
Bien entendu, pour les pages qui ne proposent guère d’autre action que le scroll ou le zoom, le test FID sera bien moins difficile à passer…
Types de première saisie pour le first input delay
En tant qu’indicateur de réactivité intervenant pendant le temps de chargement d’une page, le FID ne tient compte que d’actions relativement minimes.
Par ailleurs, le défilement et le zoom, qui sont plutôt de l’ordre de l’animation, ne sont pas calculés, contrairement aux clics ou tapotements sur les boutons, au glissement sur les menus ou à l’ouverture d’un lien.
Astuces techniques pour l’amélioration de votre score FID
À l’instar du LCP, les leviers pour minimiser le First Imput Delay se trouvent principalement du côté développeur. En effet, celui-ci pourra :
- alléger le thread principal ;
- optimiser le code tiers ;
- se servir d’un cache de navigateur ;
- minimiser le temps d’exécution du JavaScript ;
- limiter la taille des transferts et le nombre de requêtes possibles.
Encore un effort ! Il nous reste encore un troisième larron à vous présenter !
Qu’est-ce que le CLS, pour Cumulative Layout Shift ?
Nous en arrivons au CLS, ou Cumulative Layout Shift. Là encore, la traduction nous est d’un moindre secours : “déplacement cumulatif de la position (ou disposition)”. Reprenons l’image du comptoir. Vous interpellez un serveur, qui s’approche, fait mine de vous écouter, puis repart sans attendre la fin, tandis qu’un de ses collègues arrive pour prendre votre commande à sa place.
Imaginez à présent que ce ballet (sans grande gravité, certes) se déroule à chaque fois, si bien que vous n’osez plus vous adresser au premier serveur, bien qu’il semble vous interroger du regard… vous sentez venir la frustration ?
C’est exactement la même chose quand les éléments de votre écran se déplacent de manière inopinée alors qu’ils avaient l’air de s’être stabilisés.
C’est déjà perturbant pour lire, mais si vous aviez cliqué sur un bouton entre temps, il y a fort à parier que ce bref déplacement vous ait fait commettre une erreur.
La stabilité visuelle contre les variations abruptes
Toutes les variations des pages web dynamiques ne sont pas à mettre dans le même panier. À commencer par les changements que l’internaute initie lui-même. À condition toutefois que le retour du site soit clairement interprétable: “la page a-t-elle bougé toute seule ou bel et bien suite à l’action de mon (ma) doigt (souris) ?”.
Afin de désambiguïser certaines situations, des animations et des transitions, comme des indicateurs de chargement, aideront l’utilisateur à savoir s’il peut interagir ou s’il doit patienter. Nota bene : les problèmes de CLS sont particulièrement flagrants sur les interfaces responsives !
Évaluation des robots Google
L’algorithme de Google a donc été conçu pour mesurer le CLS, selon un indice compris entre 0 et 1. Vous, en tant qu’administrateur, vous aurez pour objectif de descendre au plus près de zéro. Quant à la barre à atteindre pour qu’un site soit au mieux de son référencement, elle se situe à seulement 0,1 !
Astuces techniques pour améliorer votre score CLS
Voici à présent les principes à respecter pour plaire aux robots Google et garder une belle position dans les SERP :
- attribuer à tous les médias une dimension déjà définie (pensez à la politique de fonctionnalité Unsized-media), afin que le navigateur n’ait pas à calculer ou modifier l’espace qu’ils prendront sur la page ;
- éviter l’insertion de contenu par-dessus un élément existant (sauf réponse à une action de l’utilisateur) ;
- parquer les publicités dans des espaces dédiés, afin qu’elles ne chamboulent pas l’affichage en arrivant sur leurs gros sabots ;
- choisir davantage des animations de transformation, et assurer une continuité par des transitions d’affichage.
Quelques outils pour mesurer personnellement vos Core Web Vitals
Pour vous épauler dans les quelques modifications que vous pourrez opérer d’ici mai 2021, voici quelques outils adaptés à la situation :
- Page Speed Insights, qui vous montre notamment comment votre page se comporte du point de vue d’un internaute qui utiliserait Chrome ;
- Chrome User Experience Report, qui recueille des données réelles afin d’être au clair sur les performances véritables (et non simulées) du site évalué ;
- Google Search Console ;
- Chrome DevTools, que vous n’utiliserez que pour le LCP et le CLS ;
- Lighthouse, un outil de mesure de laboratoire qui ne servira pas pour le FID ;
- WebPageTest ;
- Field tools ;
- Web-vitals JavaScript library ;
- Lab tools.
Ce qu’il faut retenir des Core Web Vitals pour le SEO
Vous l’aurez compris, tout le monde est concerné par ce genre d’actus Google. Seul un site débutant dont le contenu même est à créer ou à revoir ne les placera qu’en fin de sa to-do list.
Quant aux gros acteurs, ils peuvent saisir cette occasion pour opérer une refonte de leurs pages les plus importantes, que ce soit en termes de taille ou de notoriété.
Les administrateurs déjà sensibilisés à la méthode UX n’auront probablement que quelques ajustements à faire ; les autres pourront se familiariser avec le SXO. Ainsi, à la lecture de cet article, peut-être aurez-vous saisi non seulement l’enjeu des Core Web Vitals mais également l’esprit avec lequel vous pouvez améliorer une interface.
Il en va donc de votre initiative d’anticiper les besoins de vos utilisateurs : votre précision, votre sens du détail feront sans doute la différence.
Vos questions, nos réponses !
Pourquoi les Core Web Vitals sont-ils si importants ?
Ces détails, centrés autour du temps de chargement d’une page (vitesse, réactivité, stabilité), assurent une meilleure expérience utilisateur. Ils sont aussi essentiels que les boutons d’une chemise, lesquels doivent être bien cousus, aux bons endroits et faciles à enfiler. Sans quoi le reste du vêtement perdrait de sa valeur. En outre, performer aux tests LCP, FID et CLS augmentera votre SEO !
Qui doit optimiser ses Core Web Vitals ?
À peu près tous les sites internet qui veulent garder un bon positionnement dans les SERP. De plus, l’apparition des Core Web Vitals est une bonne occasion pour les sites web non débutants, qui embarquent beaucoup de contenu multimédia et de fonctionnalités diverses, de se mettre à jour sur tous les indicateurs qui concernent le temps de chargement de leurs pages les plus visitées.
Quand dois-je tester mon site internet ?
Dès maintenant, surtout si vous avez anticipé et mis en application les quelques principes que nous avons décrits plus haut. Sachez d’ailleurs que les robots Google mettront une trentaine de jours à évaluer vos Core Web Vitals. Ainsi, vous serez bien avisé(e) de réitérer le test au bout d’une période équivalente.
Comment avoir une écriture SEO friendly ?
Retrouvez tout ce qu’il y a à savoir pour créer du contenu SEO friendly dans notre article dedié à la question.
