Que sont les Core Web Vitals et comment les améliorer ?

Les Core Web Vitals (CWV) sont des mesures de vitesse qui font par­tie des sig­naux de Page Expe­ri­ence de Google pour mesur­er l’expérience util­isa­teur. Ces chiffres mesurent le charge­ment visuel avec le Largest Con­tent­ful Paint (LCP), la sta­bil­ité visuelle avec Cumu­la­tive Lay­out Shift (CLS) et l’in­ter­ac­tiv­ité avec le First Input Delay (FID).

L’ex­péri­ence de page sur mobile et les Core Web Vitals qui vont avec ont été offi­cielle­ment util­isées pour le classement des pages depuis mai 2021. Les sig­naux sur desk­top sont util­isés depuis févri­er 2022.

Le meilleur moyen pour connaître les mesures de votre site est de se rendre sur le rap­port Core Web Vitals de la Google Search Con­sole. Avec ce rap­port, vous allez rapi­de­ment voir si vos pages sont classées dans “mau­vaise URL”, “URL a besoin d’amélioration” ou “bonne URL”.

Les seuils pour chaque caté­gorie sont les suivants :

Ain­si, voici à quoi ressem­ble le rapport :

Si vous cliquez sur l’un de ces rap­ports, vous aurez plus de détails sur les typologies de prob­lèmes ainsi que le nom­bre d’URL impactées.

Cli­quer sur l’un de ces prob­lèmes va de nou­veau vous don­ner plus de détails sur des groupes de pages qui sont affec­tées. Ce regroupe­ment est logique, la plu­part des modifications à faire pour amélior­er les Core Web Vitals se font depuis un tem­plate de page spé­ci­fique qui va affecter plusieurs URL. Vous pou­vez faire le change­ment une seule fois dans le tem­plate et les cor­rec­tions vont se propager sur toutes les pages où le tem­plate s’applique.

Vous savez désormais quelles pages sont touchées précisément.

Voici quelques infor­ma­tions com­plé­men­taires sur les Core Web Vitals ainsi que com­ment faire pass­er les tests à vos pages :

Fait 1: Les mesures sont séparées entre ver­sion desk­top (ordinateur) et ver­sion mobile. Les sig­naux mobiles sont util­isés pour le rank­ing sur mobile et les sig­naux desk­top pour le rank­ing sur desktop.

Fait 2: Les don­nées vien­nent du Chrome User Expe­ri­ence Report (CrUX), qui enreg­istre des don­nées d’utilisateurs Chrome qui ont accep­té de les partager. Ces mesures sont pris­es à mesure du 75e per­centile d’utilisateur. Par con­séquent, si 70% des util­isa­teurs ont une expéri­ence de page “bonne”, et 5% sont dans la caté­gorie “besoin d’amélioration”, alors votre page sera indiquée dans “besoin d’amélioration”.

Fait 3: Les mesures sont pris­es pour chaque page. Mais s’il n’y a pas assez de don­nées, “les sig­naux des par­ties d’un site ou du site en général peu­vent être util­isés” déclare John Mueller, Web­mas­ter Trend Ana­lyste de Google. Dans notre étude de don­nées Core Web Vitals, nous avons analysé plus de 42 mil­lions de pages et avons décou­vert que seules 11.4% d’entre elles avaient des mesures associées.

Fait 4: Avec l’ajout de ces nou­velles mesures, Accel­er­at­ed Mobile Pages (AMP) n’est plus un préreq­uis pour être dans les Tops Sto­ries sur mobile. Comme ces news sto­ries n’auront pas réelle­ment de don­nées sur les mesures de vitesse, il est pos­si­ble que ce soient les mesures d’une plus grande caté­gorie de page, voire du domaine en entier, qui soient utilisées.

Fait 5: Sin­gle Page Appli­ca­tion ne peut pas cal­culer deux mesures, FID et LCP, via les tran­si­tions de pages. Il y a quelques propo­si­tions de change­ment, dont App His­to­ry API et poten­tielle­ment un change­ment de mesure de l’interactivité qui pour­rait être appelé Respon­sive­ness pour le temps de réac­tion d’une page.

Fait 6: Les mesures peu­vent chang­er au fil du temps, tout comme le seuil. Google a déjà fait évoluer ses cal­culs pour mesur­er la vitesse dans ses out­ils au fil des années, ain­si que le seuil de ce qui était con­sid­éré comme étant rapi­de ou non.

Les Core Web Vitals ont déjà changé, et il y a déjà d’autres change­ments pro­posés pour le futur. Typiquement, je ne serais pas sur­pris que la taille de page soit ajoutée. Actuellement, vous pou­vez réussir à obtenir de bons scores dans les mesures actuelles en réglant les pri­or­ités de cer­tains élé­ments, même avec une très grande page. Je pense que cela devrait changer par la suite.

Parmi les facteurs de Google pour se positionner, beaucoup n’ont pas beaucoup d’importance. Pour ce qui est des Core Web Vitals, les représentants de Google disent qu’ils ont une faible importance, ou bien peuvent servir d’aide à la décision en cas d’égalité.

Gary Illyes, de l’équipe Google Search, l’a résumé lors de Pubcon en septembre 2023 :

Je ne m’attends pas à beaucoup de changements (voire aucun) dans l’amélioration du SEO d’un site en optimisant les Core Web Vitals. Cela dit, ils restent un facteur, et ce tweet de John Mueller montre comment cela peut fonctionner comme signal de départage.

Il y a eu beaucoup de facteurs de ranking qui prenaient en considération la vitesse pendant de nombreuses années. Je ne m’attendais donc pas à un gros impact visible lorsque la mise à jour d’expérience de la page sur mobile a été déployée. Malheureusement, il y a eu également plusieurs Google Core Updates pendant cette période, ce qui rend difficile de réellement mesurer des impacts ou tirer des conclusions fiables.

Certaines études montrent des corrélations positives entre avoir un bon score en termes de Core Web Vitals et de meilleurs résultats dans les SERP. Mais j’y porte un regard sceptique. Ce serait comme dire que ce sont les sites qui se concentrent sur le SEO qui ont tendance à mieux ranker. Si un site travaille à améliorer ses CWV, il a certainement déjà fait beaucoup d’efforts sur d’autres points aussi.

Ce que vous devez retenir : les CWV ne vont probablement pas transformer votre SEO du jour au lendemain. En revanche, ils ont un impact direct sur l’expérience utilisateur; et donc sur vos taux de conversion et de rétention. Si votre site est déjà bien optimisé sur tous les autres points, améliorer vos CWV peut faire la différence face à des concurrents aux scores similaires.

La différence entre les deux est simple : les données de terrain (field data) viennent de vrais utilisateurs qui visitent votre site, via le Chrome User Experience Report (CrUX). C’est ce que Google utilise pour le classement. Les données de laboratoire (lab data) sont produites dans un environnement simulé et contrôlé — c’est ce que vous voyez dans Lighthouse, PageSpeed Insights ou Chrome DevTools. Elles ne reflètent pas votre classement, mais elles sont reproductibles et utiles pour tester vos corrections.

Les deux peuvent afficher des scores très différents pour une même page, et c’est normal. Un vrai utilisateur arrive souvent avec du cache, sur un réseau variable, depuis un appareil que vous n’avez pas simulé. Par ailleurs, l’INP ne peut pas être mesuré en lab : comme cette métrique dépend des vraies interactions, les outils de lab utilisent à la place le Total Blocking Time (TBT) comme indicateur proxy.

En pratique, servez-vous des données terrain pour savoir où vous en êtes aux yeux de Google, et des données de lab pour diagnostiquer et tester. Les deux sont complémentaires. Notez que les données CrUX ont un délai de 28 jours : après une optimisation, il faudra patienter avant de voir le résultat remonter dans Search Console.

Voici les trois composants actuels des Core Web Vitals et ce qu’ils mesurent :

Il faut savoir qu’il existe d’autres Web Vitals qui servent de mesures proxy et des mesures supplémentaires qui ne sont pas utilisées dans les calculs de ranking. On va en parler dans la section Web Vitals secondaires.

Le LCP est l’élément vis­i­ble le plus grand qui soit chargé dans le viewport.

L’élément le plus grand est générale­ment l’image mise en avant ou peut-être la balise h1, mais cela peut être également :

les <svg> et <video> pour­raient être ajoutés dans le futur.

Dans Page­Speed Insights l’élément LCP sera spé­ci­fié dans la sec­tion “Diag­nos­tic”. Remar­quez égale­ment qu’il y a un onglet pour sélec­tion­ner LCP pour ne voir que les élé­ments qui le concernent.

Dans Chrome Dev­Tools, suiv­ez ces étapes :

Comme nous avons pu le voir sur Page­Speed Insights, il y a beau­coup de prob­lèmes qui doivent être cor­rigés, ce qui fait du LCP la mesure la plus dif­fi­cile à amélior­er. Dans notre étude, j’ai remar­qué que la plu­part des sites n’ont pas beau­coup amélioré le LCP au fil du temps.

Voici quelques élé­ments à garder en tête sur les dif­férentes manières d’améliorer le LCP.

Je vous liste les 5 étapes pour améliorer le LCP ici et après, je les développe un par un :

On entre dans le détail de chaque étape maintenant :

Si vous ne pou­vez vous débar­rass­er de n’importe quel fichi­er ou réduire sa taille, votre page va charg­er plus vite. Vous pou­vez vouloir sup­primer tout fichi­er ou morceau de code qui ne sont pas utilisés.

La manière dont vous allez vous y pren­dre va beau­coup dépen­dre de com­ment votre site est fait, mais on par­le du proces­sus comme du a href=“https://webpack.js.org/guides/tree-shaking/”>tree shak­ing (sec­ouer l’arbre). C’est générale­ment géré de manière automa­tique dans beau­coup de sys­tèmes, mais pour cer­tains, cela va deman­der des efforts.

Il y a égale­ment la com­pres­sion, qui va réduire la taille des fichiers. Qua­si­ment tous les types de fichiers util­isés pour con­stru­ire votre site peu­vent être com­pressés, comme le CSS, le JavaScript, les Images et le HTML.

L’information ne se transmet pas instan­ta­né­ment, il lui faut du temps. Plus vous êtes loin du serveur, plus il fau­dra de temps pour trans­met­tre les don­nées. À moins que vous ne vous con­cen­triez exclu­sive­ment sur une petite zone géo­graphique, avoir un Con­tent Deliv­ery Net­work (CDN) est une bonne idée.

Les CDN sont un bon moyen de faire pass­er votre site par un serveur plus proche des util­isa­teurs. C’est un peu comme avoir des copies de votre serveur à dif­férents endroits du monde.

Lorsque vous vous con­nectez la pre­mière fois à un serveur, un proces­sus par­court le web pour établir une con­nex­ion sécurisée entre l’utilisateur et le serveur. Cela prend un peu de temps, et chaque nou­velle con­nex­ion néces­saire va ajouter du délai sup­plé­men­taire pour répéter le proces­sus. Si toutes vos ressources sont sur le même serveur, cela va vous per­me­t­tre d’éliminer ces délais supplémentaires.

Si vous ne pou­vez pas utilis­er le même serveur, vous pou­vez vous trou­ver vers le pre­con­nect ou le DNS-prefetch pour que les con­nex­ions se déclenchent plus tôt. Un nav­i­ga­teur va en général attein­dre la fin du télécharge­ment du HTML pour com­mencer les con­nex­ions. Mais avec du pre­con­nect et du DNS-prefetch, les con­nex­ions vont se déclencher plus tôt que la nor­male. Notez que le DNS-prefetch est mieux sup­porté que preconnect.

Lorsque vous met­tez des ressources en cache, elles sont téléchargées lors de la pre­mière vue de la page, mais n’auront pas besoin d’être à nou­veau téléchargées avec les nou­velles vues. Avec des ressources directe­ment acces­si­bles, les futurs charge­ments de page seront plus rapi­des. Voyez dans le tableau en cas­cade ci-dessous, la dif­férence entre le pre­mier et le sec­ond charge­ment de page.

Pre­mier charge­ment de la page :

Sec­ond charge­ment de la page :

Pour réus­sir la véri­fi­ca­tion LCP, vous devez don­ner des ordres de pri­or­ité sur com­ment les ressources sont chargées dans le crit­i­cal ren­der­ing path. Vous devez réor­gan­is­er l’ordre dans lequel les ressources sont téléchargées et traitées. Il faut com­mencer par celles que vous voulez que votre util­isa­teur voit en pre­mier, puis charg­er le reste ensuite.

Beau­coup de sites peu­vent pass­er le LCP en ajoutant sim­ple­ment des règles de pre­load pour cer­taines choses comme l’image prin­ci­pale ou les feuilles de styles et polices néces­saires. Voyons com­ment opti­miser ces dif­férents types de ressources.

Si vous n’avez pas besoin de l’image, la meilleure solu­tion est tout sim­ple­ment de s’en débar­rass­er. Si vous avez besoin de l’image, il faut en opti­miser la taille et la qual­ité pour la ren­dre la plus légère possible.

Vous pou­vez en plus précharg­er l’image (pre­load). Cela va lancer le télécharge­ment de l’image un peu plus tôt. Elle appa­raî­tra donc plus vite. Une déc­la­ra­tion de pre­load pour une image ressem­ble à ça :

<link rel="preload" as="image" href=“cat.jpg"
imagesrcset=“cat_400px.jpg 400w,
cat_800px.jpg 800w, cat_1600px.jpg 1600w"
imagesizes="50vw">

On appelle cette étape le lazy loading des images non critiques.

Vous devriez charg­er plus tar­di­ve­ment (lazy load) les images dont vos utilisateurs n’ont pas besoin dans l’immédiat.. Cela déclenche le charge­ment de l’image plus tard dans le proces­sus ou lorsque l’u­til­isa­teur scrolle jusqu’à elle. Vous pou­vez utilis­er le loading=”lazy” comme ceci :

<img src=“cat.jpg" alt=“cat" loading="lazy">

Nous avons déjà par­lé du fait de retir­er le CSS inutil­isé et de mini­fi­er celui qui reste. L’autre chose à faire est de charg­er le CSS cri­tique inline. Cela prend les par­ties du CSS néces­saires pour charg­er les élé­ments que l’utilisateur doit voir immé­di­ate­ment pour l’appliquer directe­ment dans le HTML. Lorsqu’il est téléchargé, tout le CSS néces­saire pour charg­er ce que voit l’utilisateur est déjà disponible.

Pour tout le CSS sup­plé­men­taire qui n’est pas cri­tique (néces­saire à l’affichage immé­di­at), il devrait être chargé plus tard dans le proces­sus. Vous pou­vez com­mencer le télécharge­ment du CSS avec une déc­la­ra­tion de pre­load mais ne l’appliquer que plus tard avec un event onload, ça ressem­ble à ça :

<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">

Voici plusieurs options pos­si­bles selon mon avis :

Bien : Préchargez vos polices. C’est encore mieux si vous utilisez le même serveur pour éviter toute connexion.

Mieux : Font-dis­play: option­al. Cela peut être fait avec une déc­la­ra­tion de pre­load. Cela va don­ner à votre police un court laps de temps pour charg­er. Si elle ne charge pas à temps, le charge­ment ini­tial de la page se fera avec une font par défaut. Votre police per­son­nal­isée sera mise en cache et appa­raî­tra lors des prochains charge­ments de page.

Par­fait : utilisez une police sys­tème. Il n’y a rien à charg­er, donc pas de délai.

Nous avons déjà par­lé de sup­primer le Javascript non util­isé et mini­fi­er celui qui reste. Si vous utilisez un frame­work JavaScript, vous pou­vez soit pré-ren­dre la page ou la ren­dre serv­er-side (SSR).

Vos autres options sont de ren­dre le JavaScript néces­saire tôt dans le charge­ment inline. Cela fonc­tionne de la même manière que le CSS, où vous chargez des por­tions du code dans le HTML ou préchargez les fichiers JavaScript pour les avoir disponibles plus tôt. Cela ne doit être fait que pour des élé­ments néces­saires pour charg­er du con­tenu au-dessus du fold (c’est-à-dire la par­tie vis­i­ble avant d’avoir besoin de scroller) ou si cer­taines fonc­tion­nal­ités dépen­dent du JavaScript.

Tout Javascript dont vous n’avez pas besoin immé­di­ate­ment devrait être chargé plus tard. Il y a deux manières de faire cela : les attrib­uts defer et async. Ces attrib­uts peu­vent être ajoutés dans les balis­es de vos scripts.

Générale­ment, le télécharge­ment d’un script bloque le pars­er pen­dant le télécharge­ment et l’exécution. Async (asyn­chro­ni­sa­tion) va per­me­t­tre le pars­ing et le télécharge­ment de se pro­duire en même temps, mais blo­quera tout de même le pars­ing pen­dant l’exé­cu­tion. Le Defer (retarde­ment) ne blo­quera pas le pars­ing pen­dant le télécharge­ment et ne s’exécutera que lorsque le HTML aura fini son parsing.

Quelle méth­ode choisir ? Pour tout ce que vous voulez assez tôt ou qui est néces­saire à d’autres fonc­tions, je pencherais pour l’async. J’utiliserais, par exem­ple, l’async pour qu’une balise ana­lyt­ics enreg­istre plus d’utilisateurs. Il vaut mieux defer tout ce qui n’est pas immé­di­ate­ment néces­saire ou n’est pas néces­saire à autre chose. Ces attrib­uts sont assez sim­ples à ajouter, voici des exemples :

Nor­mal:

<script src="https://www.domain.com/file.js"></script>

Async:

<script src="https://www.domain.com/file.js" async></script>

Defer:

<script src="https://www.domain.com/file.js" defer></script>

Il existe encore d’autres tech­nolo­gies que vous pour­riez vouloir explor­er pour amélior­er les per­for­mances, par exem­ple : Spec­u­la­tive Pre­ren­der­ing, Ear­ly Hints, Signed Exchanges, and HTTP/3.

L’INP a officiellement remplacé le First Input Delay (FID) le 12 mars 2024. Ce changement n’est pas anodin : le FID ne mesurait que le délai avant la première interaction d’un utilisateur sur une page. C’était une fenêtre trop étroite, qui ne reflétait pas la réactivité réelle d’une page tout au long de la session.

L’INP mesure toutes les interactions (clics, tapotements, pressions de touches) et retient la pire au 75e percentile. Si un utilisateur clique dix fois sur votre page et que neuf interactions sont instantanées mais qu’une seule est lente, c’est cette lenteur que l’INP va capturer. C’est beaucoup plus exigeant, et beaucoup plus représentatif de ce que vit vraiment l’utilisateur.

Le CLS mesure la façon dont les éléments bougent et la stabilité de l’organisation de la page. Il va prendre en compte la taille du contenu et la distance sur laquelle il va bouger. Google a déjà mis à jour la manière dont le CLS est mesuré : auparavant, il continuait sa mesure après le chargement initial de la page. Dorénavant, il se restreint aux 5 secondes où il y a le plus de changement.

Il peut être agaçant de vouloir cliquer sur quelque chose sur une page qui va soudainement bouger et vous faire cliquer sur quelque chose d’autre. Je veux cliquer sur quelque chose et, subitement, une pub se met à la place et je me retrouve sur un autre site. En tant qu’utilisateur, c’est frustrant.

Parmi les principales causes de CLS, on retrouve :

En sélectionnant le CLS dans PageSpeed Insights, vous pouvez voir tous les problèmes. Celui auquel il faut porter une attention particulière est “Avoid large layout shifts.”

Dans Chrome DevTools, l’onglet Performance met en évidence les layout shifts directement sur la timeline. Vous pouvez également utiliser l’extension Chrome Web Vitals pour voir le score CLS en temps réel pendant que vous naviguez sur votre site.

Ces métriques ne font pas partie des Core Web Vitals et ne sont pas utilisées directement dans le classement. Elles servent de métriques proxy : améliorer l’une d’elles a un impact direct sur vos scores LCP ou INP.

Le TTFB mesure le temps entre la requête du navigateur et la réception du premier octet de réponse du serveur. C’est la base de tout : un TTFB lent pénalise mécaniquement votre LCP, quelle que soit la qualité de vos autres optimisations.

Pour l’améliorer : hébergement performant, mise en cache serveur, CDN, et activation d’Early Hints.

Le FCP mesure le temps jusqu’à ce que le premier élément (texte, image, SVG) soit affiché à l’écran. Il précède toujours le LCP et sert d’indicateur intermédiaire : si votre FCP est lent, votre LCP le sera forcément aussi.

Un bon plugin de performance peut régler automatiquement une grande partie des problèmes LCP et CLS sans toucher au code : minification CSS/JS, lazy loading, cache navigateur et serveur, préchargement des ressources critiques.

Les options les plus efficaces :

Quel que soit le plugin choisi, travaillez avec votre développeur pour les réglages avancés — une mauvaise configuration peut aggraver les scores plutôt que les améliorer.

Je ne pense pas que les Core Web Vitals aient un grand impact en matière de SEO. À moins que le site soit très lent, ma pri­or­ité n’est pas de les optimiser. Si vous voulez faire un argu­men­taire pour opti­miser les CWS, ne vous servez pas du SEO comme argument.

Mais par con­tre, c’est à pren­dre en compte pour l’expérience util­isa­teur. Comme je l’ai dit dans mon arti­cle sur la vitesse de page, des amélio­ra­tions vont per­me­t­tre de faire ren­tr­er plus de don­nées dans Ana­lyt­ics, ce qui va “don­ner l’impression” d’une amélio­ra­tion. Vous pou­vez aus­si amélior­er les CWV pour avoir plus de con­ver­sions, beau­coup d’études ten­dent à le prou­ver (mais c’est peut-être encore là parce qu’il y a plus de don­nées enregistrées).

Un autre point impor­tant : en tant que SEO, tra­vaillez avec vos développeurs : ce sont eux les experts. L’optimisation de la vitesse peut être un sujet très com­plexe. Si vous êtes seul, vous allez peut-être avoir besoin d’un plu­g­in ou d’un ser­vice tiers (par exem­ple WP Rock­et ou Autop­ti­mize) pour gér­er cela.

Les choses seront de plus en plus sim­ples à mesure que de nou­velles tech­nolo­gies sor­tent et que des plate­formes comme votre CMS, votre CFN voire nos nav­i­ga­teurs gèrent une par­tie des tâch­es d’optimisation. Je pense que dans quelques années, la plu­part des sites n’auront pas à s’inquiéter de ces fac­teurs, car l’optimisation sera presque automatique.

Beau­coup de plate­formes ont déjà sor­ties des fonc­tion­nal­ités ou tra­vail­lent sur ce sujet.

D’ores et déjà, Word­Press précharge la pre­mière image et monte une équipe pour tra­vailler sur les Wore Web Vitals. Cloud­flare a déjà sor­ti beau­coup d’élé­ments pour ren­dre votre site plus rapi­de comme Ear­ly Hints, Signed Exchanges, et HTTP/3.. Je pense que cela va con­tin­uer jusqu’au point qu’un pro­prié­taire de site n’ait même plus à se pos­er de questions.

Comme tou­jours, écrivez-moi sur Twit­ter si vous avez des questions et sur Linkedin pour les francophones.