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

Le meilleur moyen de voir quelles sont les mesures de votre site est via le rap­port Core Web Vitals de la Google Search Con­sole. Avec ce rap­port, vous allez rapi­de­ment pou­voir 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 ces caté­gories de prob­lèmes et 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 change­ments à faire pour amélior­er les Core Web Vitals sont à faire sur 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 main­tenant quelles pages sont touchées, voici quelques infor­ma­tions com­plé­men­taires sur les Core Web Vitals et 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 et ver­sion mobile. Les sig­naux mobiles sont util­isés pour le rank­ing mobile et les sig­naux desk­top pour le rank­ing 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”, votre page sera classé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 cal­cule pas 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é 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 dans le futur. Je ne serais pas sur­pris que la taille de page soit ajoutée. Vous pou­vez par­venir à avoir 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.

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 VIrals, les représen­tants de Google dis­ent qu’ils ont une faible impor­tance, ou bien peu­vent servir à se décider en cas d’égalité. Je ne m’attends pas à beau­coup de change­ments (voire aucun) dans l’amélioration du rank­ing 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 de bon Core Web Vitals et un meilleur rank­ing. 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 :

1. Per­for­mance > sélec­tion­nez “Screen­shots”
2. Cliquez sur “Start pro­fil­ing and reload page”
3. LCP est sur le graphique temporel
4. 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 par­tie de code qui ne sont pas utilisés.

La manière dont 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 le prunier). 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 voy­age 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, il se passe un proces­sus qui 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-pre­fecth, 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.

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 voie en pre­mier, puis charg­er le reste.

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 vous n’avez pas besoin immé­di­ate­ment. 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 de con­cert 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 pencherai pour l’async. J’utiliserai, 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>

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 com­ment 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 cinq sec­on­des où il y a le plus de changement.

Source: web.dev

Il peut être exces­sive­ment é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 que vous ne vouliez pas. ç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 extrême­ment 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 src=“cat.jpg" width="640" height="360" alt=“cat with string" />

Pour les images respon­sives, vous devez utilis­er un src­set comme celui-ci :

<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, réservez 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 pen­dant 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 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 labo 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 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 de vitesse 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 plus intéress­er Google au fil du temps.

Conclusion

Je ne pense pas que les Core Web Vitals ont un grand impact en SEO et, à moins que le site soit très lent, ma pri­or­ité n’est pas d’optimiser pour elles. 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 : 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 sont 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.