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

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 classe­ment des pages depuis mai 2021. Les sig­naux sur desk­top sont util­isés depuis févri­er 2022. 

Le meilleur moyen pour con­naître les mesures de votre site est de se ren­dre 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 typolo­gies de prob­lèmes ain­si 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 mod­i­fi­ca­tions à 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ésor­mais quelles pages sont touchées pré­cisé­ment. Voici quelques infor­ma­tions com­plé­men­taires sur les Core Web Vitals ain­si que com­ment faire pass­er les tests à vos pages : 

• Quelques faits sur les Core Web Vitals
• Est-ce que les Core Web Vitals sont impor­tants en SEO ?
• Com­po­si­tion des Core Web Vitals
• Out­ils pour mesur­er les Core Web Vitals

Fait 1: Les mesures sont séparées entre ver­sion desk­top (ordi­na­teur) 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. Typ­ique­ment, je ne serais pas sur­pris que la taille de page soit ajoutée. Actuelle­ment, vous pou­vez réus­sir à 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 chang­er par la suite. 

Il y a plus de 200 fac­teurs de rank­ing, beau­coup d’ailleurs n’ont que peu d’importance. Pour ce qui est des Core Web Vitals, les représen­tants de Google dis­ent qu’ils ont une faible impor­tance, ou bien peu­vent servir d’aide à la déci­sion en cas d’égalité. Je ne m’attends pas à beau­coup de change­ments (voire aucun) dans l’amélioration du SEO d’un site en opti­misant les Core Web Vitals. Cela dit, ils restent un fac­teur, et ce tweet de John mon­tre com­ment cela peut marcher. 

https://twitter.com/JohnMu/status/1395798952570724352

Il y a eu beau­coup de fac­teurs de rank­ing qui pre­naient en con­sid­éra­tion la vitesse pen­dant de nom­breuses années. Je ne m’attendais donc pas à un gros impact vis­i­ble lorsque la mise à jour d’expérience de la page sur mobile a été déployée. Mal­heureuse­ment, il y a eu égale­ment plusieurs Google Core Updates pen­dant cette péri­ode, ce qui rend dif­fi­cile de réelle­ment mesur­er des impacts ou tir­er des con­clu­sions fiables. 

Cer­taines études mon­trent des cor­réla­tions pos­i­tives entre avoir un bon score en ter­mes de Core Web Vitals et de meilleurs résul­tats dans les SERP. Mais j’y porte un regard scep­tique. Ce serait comme dire que ce sont les sites qui se con­cen­trent sur le SEO qui ont ten­dance à mieux ranker. Si un site tra­vaille à amélior­er ses CWV, il a cer­taine­ment déjà fait beau­coup d’efforts sur d’autres points aus­si. Et beau­coup de gens ont tra­vail­lé à amélior­er ces mesures, comme vous pou­vez le voir de ce tableau issu de notre étude de cas.

Voyons main­tenant chaque Core Web Vital en détail. 

Voici les trois com­posants actuels des Core Web Vitals et ce qu’ils mesurent : 

• Largest Con­tent­ful Paint (LCP) – Charge­ment visuel 
• Cumu­la­tive Lay­out Shift (CLS) – Sta­bil­ité visuelle 
• First Input Delay (FID) – Interactivité 

Il faut savoir qu’il existe d’autres Web Vitals qui ser­vent de mesure prox­ies et des mesures sup­plé­men­taires qui ne sont pas util­isées dans les cal­culs. Les mesures de Web Vitals pour le charge­ment visuel com­pren­nent le Time to First Byte (TTFB) et First Con­tent­ful Paint (FCP). Le Total Block­ing Time (TBT) and Time to Inter­ac­tive (TTI) per­me­t­tent de mesur­er l’interactivité.

Largest Contentful Paint

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

Source: web.dev

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 : 

• Élé­ment <img>
• Élé­ment <image> dans un élé­ment <svg>
• Image dans un élé­ment <video>
• Image de fond chargée avec la fonc­tion url() 
• Blocs de texte 

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

Comment voir le LCP ?

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 : 

• Per­for­mance > sélec­tion­nez “Screen­shots”
• Cliquez sur “Start pro­fil­ing and reload page” 
• LCP est sur le graphique temporel 
• Cliquez sur le node, c’est l’élément pour le LCP 

Optimiser le LCP

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. 

1. Plus petit = plus rapide

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. 

2. Plus près = plus rapide

L’information ne se trans­met 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. 

3. Si possible, utilisez le même serveur

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 pre­con­nect.

4. Mettez en cache ce que vous pouvez

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 : 

5. Priorisez les ressources

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. 

LES IMAGES PLUS TÔT

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">

LES IMAGES PLUS TARD

Vous devriez charg­er plus tar­di­ve­ment (lazy load) les images dont vos util­isa­teurs 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">

LE CSS PLUS TÔT

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. 

LE CSS PLUS TARD

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'">

FONTS (POLICES)

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. 

LE JAVASCRIPT PLUS TÔT

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. 

LE JAVASCRIPT PLUS TARD

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 : 

Normal: 

<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>

Divers

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.

Resources

• Opti­mize Largest Con­tent­ful Paint – web.dev
• Inves­ti­gat­ing Largest Con­tent­ful Paint – Paul Irish (video)
• How to Improve Page Speed From Start to Fin­ish – Ahrefs

Cumulative Layout Shift

Le CLS mesure la façon dont les élé­ments bougent et la sta­bil­ité de l’organisation de la page. Il va pren­dre en compte la taille du con­tenu et la dis­tance sur laque­lle il va bouger. Google a déjà mis à jour la manière dont le CLS est mesuré. Aupar­a­vant, il con­tin­u­ait sa mesure après le charge­ment ini­tial de la page. Doré­na­vant, il se restreint au 5 sec­on­des où il y a le plus de changement. 

Source: web.dev

Source: web.dev

Il peut être éner­vant de vouloir cli­quer sur quelque chose sur une page qui va subite­ment bouger et vous faire cli­quer sur quelque chose d’autre. ça m’arrive tout le temps. Je veux cli­quer sur quelque chose et, subite­ment, une pub se met à la place et je me retrou­ve sur un autre site. En tant qu’utilisateur, c’est frustrant. 

Par­mi les prin­ci­pales cause de CLS, on retrouve : 

• Les images sans dimensions 
• les pubs, embed et iframes sans dimensions 
• L’injection de con­tenu avec du JavaScript 
• L’application tar­dive de polices ou styles 

Comment voir le CLS

En sélec­tion­nant le CLS dans Page­Speed Insight, vous pou­vez voir tous les prob­lèmes. Celui auquel il faut porter une atten­tion par­ti­c­ulière est “Avoid large lay­out shifts.”

Nous util­isons Web­PageTest. Dans la vue Film­strip, Utilisez les options suivantes : 

• High­light Lay­out Shifts 
• Thumb­nail Size: Huge 
• Thumb­nail Inter­val: 0.1 secs 

Vous voyez com­ment nos polices changent de style entre 5.1 et 5.2 ? La maque­tte (lay­out) change lorsque notre police per­son­nal­isée est appliquée. 

Smash­ing Mag­a­zine utilise égale­ment une tech­nique intéres­sante où ils met­tent un cadre de 3px rouge autour de tous les élé­ments et enreg­istrent une vidéo du charge­ment de la page pour voir tous les change­ments en direct. 

Optimiser le CLS

Dans la plu­part des cas, vous allez devoir tra­vailler autour des images, des polices et pos­si­ble­ment du con­tenu injec­té pour opti­miser le CLS. Voyons chaque cas. 

Images

Pour les images, vous devez réserv­er l’espace pour qu’il n’y ait pas de change­ment brusque et que l’image se con­tente de rem­plir l’espace alloué. Cela peut vouloir dire définir la hau­teur et largeur des images à l’intérieur de la balise <img> comme ceci : 

<img

width="1000"

height="1000"

src="puppy-1000.jpg"

srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"

alt="Puppy with balloons" />

Et, réserv­er l’espace max­i­mal néces­saire pour du con­tenu dynamique comme des pubs. 

Fonts (polices)

Pour les polices, votre but est qu’elles appa­rais­sent dès que pos­si­ble et ne s’interchangent pas. Lorsqu’une police est chargée ou changée, vous allez avoir un change­ment vis­i­ble comme un Flash of Invis­i­ble Text (FOIT) ou Flash of Unstyled Text (FOUT).

Si vous pou­vez utilis­er une police sys­tème, faites-le. S’il n’y a rien à charg­er, il n’y aura ni délai ni change­ment qui pour­rait provo­quer un mouvement. 

Si vous utilisez une police per­son­nal­isée (cus­tom font) , la meilleure méth­ode est de com­bin­er <link rel=”preload”> (qui va essay­er de charg­er votre police dès que pos­si­ble et font-dis­­­play: option­nal (qui va don­ner à votre pos­si­ble un cours laps de temps pour charg­er). Si la police ne parvient pas à se charg­er à temps, la page ini­tiale va sim­ple­ment mon­tr­er la police par défaut. Votre police per­son­nal­isée va être mise en cache et sera mon­trée aux prochains charge­ments de page. 

Contenu injecté

Lorsque le con­tenu est inséré dynamique­ment par-dessus du con­tenu exis­tant, cela va causer un mou­ve­ment. Si vous devez le faire, pensez à réserv­er de l’espace à l’avance.

Resources

• What Forces Layout/Reflow – Paul Irish
• Opti­mize Cumu­la­tive Lay­out Shift – web.dev
• Debug­ging Lay­out Shifts – web.dev
• Under­stand­ing Cumu­la­tive Lay­out Shift – Annie Sul­li­van (video)
• How to Avoid Lay­out Shifts Caused by Web Fonts – Simon Hearne
• Evolv­ing Cumu­la­tive Lay­out Shift in Web Tooling

First Input Delay

Le FID est le temps entre le moment où un util­isa­teur inter­ag­it avec votre page et celui où la page répond. On peut voir cela comme le temps de réaction. 

Exem­ple d’interactions :

• Clic sur un lien ou un bouton 
• Entrée de texte dans un champ vide 
• Sélec­tion d’un menu déroulant 
• Clic sur une case à cocher 

Cer­tains évène­ments comme le scroll ou le zoom ne sont pas comptabilisés. 

Il peut être très frus­trant d’essayer de cli­quer sur quelque chose et que rien ne se passe sur la page. 

Source: web.dev

Tous les util­isa­teurs ne vont pas inter­a­gir avec une page, elle n’aura donc pas for­cé­ment de valeur FID. C’est pour cela que les out­ils de tests ne vont pas avoir de valeur à don­ner : ils n’in­ter­agis­sent pas avec la page. Ce qu’il faut regarder dans un test d’outil est le Total Block­ing Time (TBT). Sur Page­Speed Insights, vous pou­vez utilis­er le TBT pour voir les prob­lèmes éventuels. 

Qu’est-ce qui cause ce délai ?

C’est le Javascript qui entre en com­péti­tion pour être le thread prin­ci­pal. Il n’y a qu’un seul thread prin­ci­pal, et le Javascript essaye de trans­met­tre ses tâch­es dessus. Il faut voir ça comme les tâch­es JavaScript qui s’exécutent à tour de rôle. 

Source : web.dev

Pen­dant qu’une tâche est en cours, une page ne peut pas répon­dre aux inter­ac­tions d’un util­isa­teur. C’est le délai que l’on ressent. Plus longue est la tâche, plus l’utilisateur ressent du délai. Les paus­es entre les tâch­es sont les oppor­tu­nités de la page pour traiter les inputs util­isa­teurs et répon­dre à ce que veut l’utilisateur.

Optimiser le FID

La plu­part des pages passent le test FID. Mais si vous avez besoin de l’optimiser, il n’y a que quelques élé­ments sur lesquels tra­vailler. Si vous pou­vez réduire la dose de JavaScript, faites-le. 

Si vous êtes dans un frame­work JavaScript, alors évidem­ment il va en fal­loir beau­coup pour charg­er la page. Ce JavaScript peut pren­dre du temps à être traité par le nav­i­ga­teur, et donc provo­quer des délais. Si vous utilisez le pre­ren­der­ing (SSR), vous pou­vez pass­er ces charges du nav­i­ga­teur au serveur. 

Une autre option est de divis­er le Javascript pour qu’il tourne moins longtemps. Vous prenez les tâch­es longues qui blo­quent l’utilisateur et vous les séparez en plus petites tâch­es qui vont blo­quer moins longtemps. On peut y arriv­er avec du code split­ting qui va divis­er les tâch­es en plus petits blocs. 

Il existe égale­ment la pos­si­bil­ité de déplac­er un peu du JavaScript vers un ser­vice work­er. Comme je le dis­ais, le Javascript entre en com­péti­tion pour rem­porter le main thread, mais cela per­met d’une cer­taine manière de con­tourn­er le prob­lème en lui don­nant un autre endroit où s’exécuter.

Il y a des désa­van­tages à cette méth­ode surtout pour le caching. Et le ser­vice work­er ne peut pas accéder au DOM, il ne peut donc faire ni mise à jour ni change­ment. Si vous voulez déplac­er le JavaScript vers un ser­vice work­er, vous allez vrai­ment avoir besoin de faire appel à un développeur qui sait ce qu’il fait. 

Resources

• Opti­mize First Input Delay – web.dev
• How to Improve Page Speed From Start to Fin­ish – Ahrefs

Il existe beau­coup d’outils pour mesur­er et suiv­re ces don­nées. L’idéal est de voir les don­nées réelles du ter­rain, qui seront les véri­ta­bles bases de mesure de Google. Mais, des don­nées “de labo” seront plus utiles pour faire des tests. 

La dif­férence entre les don­nées de lab­o­ra­toires et de ter­rain est que celles de ter­rain s’intéressent aux véri­ta­bles util­isa­teurs et pren­nent donc en compte les con­di­tions de réseau, les devices, le cache nav­i­ga­teur, etc. Mais les don­nées de labo sont con­stantes et réal­isées dans les mêmes con­di­tions pour des résul­tats de test répétables. 

La plu­part des ces out­ils utilisent Light­house comme base pour les tests. La seule excep­tion est Web­PageTest, même si vous pou­vez aus­si y utilis­er des tests Light­house si vous le souhaitez. Les don­nées ter­rain vien­nent de CrUX. 

Don­nés terrains

Il existe quelques autres out­ils que vous pou­vez utilis­er pour récupér­er vos pro­pres don­nées comme le Real User Mon­i­tor­ing (RUM) qui vous don­nent un feed­back immé­di­at sur com­ment vos amélio­ra­tions sur la vitesse de charge­ment ont un impact sur de véri­ta­bles util­isa­teurs (plutôt que de se baser sur des tests de laboratoire). 

Don­nées de laboratoire

Page­Speed­In­sight est par­fait pour véri­fi­er une page après l’autre. Mais, si vous voulez avoir des don­nées lab­o­ra­toire ou ter­rain à grande échelle, il vaut mieux pass­er par l’API. Vous pou­vez facile­ment la con­necter avec Ahrefs Web­mas­ter Tools (gra­tu­it) ou l’Audit de Site Ahrefs pour avoir des rap­ports qui détail­lent toutes les performances. 

Notez bien que les don­nées CWV mon­trées là seront déter­minées par l’user-agent que vous aurez sélec­tion­né pour votre crawl pen­dant sa configuration. 

J’aime égale­ment le rap­port GSC, car vous pou­vez voir les don­nées ter­rain pour plusieurs pages à la fois. Mais les don­nées ont un délai moyen de 28 jours, donc tout change­ment met­tra du temps à remon­ter dans le rapport. 

Une autre chose qui peut être utile : vous pou­vez trou­ver le scor­ing weights de Light­house à tout moment dans le temps pour voir les change­ments his­toriques. Cela peut vous don­ner une meilleure idée de pourquoi vos scores ont changé et ce qui va davan­tage intéress­er Google au fil du temps. 

Conclusion

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 opti­miser. 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.