Core Web Vitals : la vitesse de chargement comme facteur SEO

Patrick Stox
Patrick Stox est conseiller produit, spécialiste SEO technique et ambassadeur à Ahrefs. Il co-organise divers évènements comme le Raleigh SEO Meetup, Raleigh SEO Conference, Beer & SEO Meetup et Findability Conference. Il est aussi modérateur sur /r/TechSEO.
    Les Core Web Vitals (Sig­naux Web Essen­tiels, même si peu de gens utilisent l’expression française) sont les indi­ca­teurs de vitesse qui entrent en compte dans les sig­naux d’Ex­péri­ence de Page de Google pour mesur­er l’expérience util­isa­teur. Ces notions mesurent le temps de charge­ment des visuels avec le Largest Con­tent­ful Paint (LCP), la sta­bil­ité visuelle avec le Cumu­la­tive Lay­out Shift (CLS) et l’interactivité avec le First Input Delay (FID).

    L’expérience de page et les indi­ca­teurs Core Web Vital entr­era offi­cielle­ment en compte dans le rank­ing en mai 2021

    Source: Google

    Le moyen le plus sim­ple de voir ces mesures pour votre site est le rap­port Sig­naux Web essen­tiels dans la Google Search Con­sole. Vous pour­rez rapi­de­ment y voir si vos pages sont dans la caté­gorie “URL lentes”, “URL à amélior­er” ou “URL rapide”.

    En explo­rant ce rap­port, vous pour­rez trou­ver des infor­ma­tions plus détail­lées sur les dif­férents prob­lèmes et une liste des pages affectées.

    Fait 1 : Les mesures sont divisées en desk­top et mobile, mais seuls les sig­naux mobiles seront util­isés pour le posi­tion­nement des pages. Google va pass­er en index­a­tion 100% mobile-first, cela fait donc sens d’utiliser les sig­naux de vitesse mobile puisque l’indexation va se baser sur ces ver­sions des pages.

    Fait 2 : Les don­nées provi­en­nent du Chrome User Expe­ri­ence Report (CrUX) qui enreg­istre les don­nées des util­isa­teurs de Chrome qui l’autorisent. Les seuils de note sont fixés sur 75% des util­isa­teurs. Donc si 70% des util­isa­teurs sont dans la caté­gorie “bonne” et que 5% dans la caté­gorie “à amélior­er”, la page sera jugée comme “à améliorer”.

    Fait 3 : Les mesures vont être pris­es pour chaque page, mais John Mueller déclare que s’il n’y a pas suff­isam­ment de don­nées, ce sont les mesures de cer­taines par­ties ou de tout le site qui pour­raient être utilisées.

    Fait 4 : Avec l’ajout de ces nou­velles mesures, l’AMP ne sera plus req­uise pour être dans les Top Sto­ries sur mobile. Comme les nou­velles sto­ries n’auront pas réelle­ment de don­nées sur la vitesse, il y a des chances que ce soient celles d’un groupe­ment de pages ou de tout le domaine qui soient pris­es en compte.

    Fait 5 : Les appli­ca­tions web monopages (Sin­gle Page Appli­ca­tions ou SPA) ne mesurent pas le FID et le LCP via les tran­si­tions de page. Nous en repar­lerons un peu plus bas.

    Fait 6 : Les mesures peu­vent chang­er au fil du temps, et les seuils de 75% aus­si. Google a déjà changé ses méth­odes pour mesur­er la vitesse d’une page dans leurs out­ils ain­si que les seuils pour lesquels une page est con­sid­érée comme rapi­de ou non. Il y a de grandes chances que cela change encore dans le futur. D’ailleurs, nous avons tra­vail­lé l’an dernier à amélior­er ces mesures pour notre site l’an dernier, mais nous avons déjà besoin de le refaire pour répon­dre aux mod­i­fi­ca­tions de Google.

    Pour remet­tre les choses à plat, sou­venez-vous qu’il existe plus de 200 fac­teurs de rank­ing. Il ne faut pas s’attendre à voir un bond dans son référence­ment en amélio­rant les Core Web Vitals. Per­son­ne ne sait réelle­ment à quel point cela va influ­encer les posi­tion­nements, mais il y a peu de chance que le sig­nal soit si fort que cela. Surtout si l’on con­sid­ère que beau­coup d’aspects de l’expérience util­isa­teur sont déjà util­isés par Google pour le ranking.

    Voyons cha­cun de ces Core Web Vitals en détail.

    Voici les trois com­posants actuels des Core Web Vitals:

    Largest Contentful Paint (LCP) — loading

    Le LCP est l’élément vis­i­ble le plus grand chargé sur l’écran (le viewport).

    L’élément le plus grand est générale­ment une image mise en avant pour le <h1> mais peut aus­si être l’un de ces éléments :

    • Élé­ment <img>
    • Élé­ment <image> dans un élé­ment <svg>
    • L’image dans un élé­ment <video>
    • L’image de fond charg­er avec la fonc­tion url()
    • Bloc 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 don­né dans la sec­tion Diag­nos­tic. Pour la page que nous testons ici, le LCP est l’image mise en avant de l’article.

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

    1. Per­for­mance > cochez “Screen­shots”
    2. Cliquez sur “start pro­fil­ing and reload page”
    3. Le LCP est sur la frise chronologique
    4. Cliquez sur le node, c’est l’élément pour le LCP

    Optimiser le LCP

    Notre élé­ment LCP sur cette page et beau­coup d’autres est l’image mise en avant. Pour amélior­er cela, nous pour­rions précharg­er l’image on la met­tre en inline pour la charg­er en même temps que le code HTML. Il faut sim­ple­ment que l’image charge plus vite qu’actuellement.

    Resources

    Cumulative Layout Shift (CLS) — Stabilité visuelle

    Le CLS mesure la manière dont les élé­ments d’une page vont bouger et la sta­bil­ité de la struc­ture. Cela prend en compte la taille de l’élément et com­ment il va bouger. L’un des prob­lèmes de cette mesure est qu’elle con­tin­ue à être cal­culée même après le charge­ment ini­tial. Google est en train de pren­dre en compte les retours sur cette don­née, nous ver­rons donc cer­taine­ment des change­ments à ce sujet dans le futur.

    Lorsque vous voulez cli­quer sur quelque chose, que la page bouge et que vous finis­sez par cli­quer sur un autre élé­ment, cela peut être très éner­vant. Ça m’ar­rive en per­ma­nence. Je clique sur quelque chose et, soudaine­ment, j’ouvre une pub voire je change de site. C’est quelque chose de très frus­trant en tant qu’utilisateur.

    Les prin­ci­paux prob­lèmes dans le CLS sont :

    • Les images sans dimension
    • Les pubs, les élé­ments embar­qués ou les iframes sans dimension
    • L’injection de con­tenu en JavaScript
    • Appli­quer des polices ou des styles tar­di­ve­ment dans le chargement

    Comment voir le CLS

    Dans Page­Speed Insights, dans Diag­nos­tics, vous trou­verez une liste des élé­ments qui bougent.

    En util­isant 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 sec

    Sur notre exem­ple : les polices changent de style entre 5.1 et 5.2 sec­on­des, ce qui fait bouger la struc­ture lorsque la police est appliquée.

    Vous pou­vez égale­ment essay­er  Lay­out Shift GIF Gen­er­a­tor.

    Smash­ing Mag­a­zine a aus­si util­isé une tech­nique intéres­sante : ils ont tout entouré d’un con­tour rouge de 3px et ont enreg­istré une vidéo de leur page en train de charg­er pour déter­min­er où il y a des change­ments de structure.

    Optimiser le CLS

    Pour notre page test, ce que nous pour­rions essay­er de faire est de précharg­er notre police ou l’abandonner com­plète­ment (peu de chance que nous choi­sis­sons cette option) ou encore utilis­er une police par défaut dans le charge­ment ini­tial et ne charg­er notre police que sur les charge­ments des pages suiv­antes. Cela peut pos­er des prob­lèmes de style, d’image de mar­que, de cohérence, etc. Nous allons devoir pren­dre une déci­sion pour le futur.

    Resources

    First Input Delay (FID) — interactivité

    Le FID est le temps qu’il va fal­loir à votre page pour répon­dre à une inter­ac­tion avec un util­isa­teur. Voyez ça comme son temps de réac­tion. Cela ne prend pas en compte le scroll ou le zoom.

    Exem­ples d’interactions :

    • Cli­quer sur un lien ou un bouton
    • Entr­er du texte dans un champ de formulaire
    • Sélec­tion­ner un menu déroulant
    • Cli­quer sur une case à cocher.

    Essay­er de cli­quer sur quelque chose sur une page et que ça n’ait pas d’effet peut être très frustrant.

    Tous les util­isa­teurs ne vont pas inter­a­gir avec une page, donc il n’y aura pas tou­jours une valeur de FID. C’est aus­si la rai­son pour laque­lle les out­ils de test ne pro­poseront pas cette mesure, car ils n’in­ter­agis­sent pas avec la page. Il faut se référ­er au TBT (Total Block­ing Time) à la place.

    Les causes du FID

    Il s’agit des élé­ments Javascript en com­péti­tion dans le thread prin­ci­pal. Il n’y a qu’un seul thread (ou tâche) prin­ci­pal et JavaScript essaye de faire pass­er des tâch­es dessus.

    Pen­dant qu’un thread est train de charg­er, une page ne peut pas répon­dre aux inputs d’un util­isa­teur. C’est à ce moment-là que l’on ressent du délai. Plus longue est la tâche, plus grand sera le délai. Les paus­es entre les tâch­es sont les seules oppor­tu­nités où une page va pou­voir pren­dre en compte la demande de l’utilisateur.

    Optimiser le FID

    Je n’ai repéré aucun prob­lème de FID sur notre site mais, en règle générale, il faut divis­er les tâch­es longues et retarder tout JavaScript non indis­pens­able pour plus tard.

    Resources

    La dif­férence entre les don­nées de “lab­o­ra­toire” et les don­nées réelles est que les don­nées réelles se fient aux véri­ta­bles util­isa­teurs, aux vitesses et sta­bil­ités de con­nex­ion, aux appareils util­isés, au cache, etc. Les don­nées de lab­o­ra­toire sont tou­jours testées dans les mêmes con­di­tions en espérant que les résul­tats soient cohérents et répétables.

    Don­nées réelles

    LCPFIDCLS
    Chrome User Expe­ri­ence Report
    Page­Speed Insights
    Google Search Con­sole (Core Web Vitals report)
    Web-vitals JavaScript library
    web.dev
    Web Vitals Extension

    Don­nées de laboratoire

    LCPFIDCLS
    Chrome Dev­Tools✘ (utilise TBT)
    Light­house✘ (utilise TBT)
    Web­PageTest✘ (utilise TBT)
    Page­Speed Insights✘ (utilise TBT)
    web.dev✘ (utilise TBT)

    J’aime beau­coup les résul­tats de GSC, car on peut voir les don­nées de plusieurs pages à la fois. Mais elles sont en décalage avec une moyenne de 28 jours, donc les change­ments peu­vent met­tre beau­coup de temps à être vis­i­bles dans le rap­port. Dans Chrome 88, Google ajoute directe­ment les Core Web Vitals dans le Dev­Tools.

    Vous pou­vez aus­si exam­in­er com­ment Light­house cal­cule les valeurs et suiv­re l’impact de vos changements.

    Conclusion

    Amélior­er les Core Web Vitals, c’est amélior­er l’expérience util­isa­teur, c’est donc quelque chose d’important. Il est trop tôt pour savoir quel impact cela va avoir sur le SEO, mais comme j’en par­le dans mon arti­cle sur la vitesse d’une page, cela va vous aider à enreg­istr­er plus de don­nées dans vos ana­lyt­ics ce qui va don­ner “l’impression” d’une amélioration.

    Rap­prochez-vous de vos développeurs : ce sont eux les experts sur ce sujet. La vitesse d’une page peut être un sujet extrême­ment com­plexe. Si vous êtes seul à vous charg­er d’un site, vous aurez peut-être besoin de vous appuy­er sur des plu­g­ins ou ser­vices tiers pour vous aider, comme WP Rock­et ou NitroPack.