Core Web Vitals : Les performances de chargement vont-elles détrôner le contenu roi ?

Les éléments de performances pris en compte

LCP, FIP, CLS, ces éléments ne vous disent peut-être rien et pourtant ils sont les ‘nouvelles’ métriques à prendre en compte pour comprendre, mesurer et améliorer l’expérience utilisateur de votre site WEB en analysant la vitesse de performances de ces métriques.

Auparavant, nous utilisions des métriques comme le « DOMContentLoaded » qui consistait à mesurer en combien de temps la page HTML a été complètement chargée et analysée (sans le css, les images, etc.) et « Load » qui mesurait le temps nécessaire pour que l’entièreté de la page se charge (html, css, images, js). La principale problématique de ces métriques est qu’elles correspondent au chargement réel de la page et non au chargement ressenti par l’utilisateur.

Avec cette mise à jour, l’objectif est de transformer la manière dont sont interprétées et testées les temps de chargement : aujourd’hui, nous utilisons des outils de tests dits de « laboratoire », comme Lighthouse. Ces outils nous permettent d’auditer une page, ou un ensemble de pages via un test périodique, manuel et avec des conditions uniques. La problématique ? Il est très probable de passer à côté de problématiques majeures du fait de ces conditions particulières : en effet, un site peut tout à fait être performant pour un utilisateur avec un réseau de qualité et un appareil puissant, et inversement pour un autre utilisateur.

Il serait incohérent de tester l’efficacité d’un vaccin en analysant uniquement son efficacité sur une unique personne de 19 ans et de vérifier de manière périodique si celui-ci est tombé malade ou non, n’est-ce pas ?

Avec les Signaux Web Vitaux, et les nouveaux outils mis en place par Google, l’idée est de permettre une analyse en temps réel de ces signaux. Ainsi chaque visiteur du site va communiquer ses données de performances au fur et à mesure de sa navigation. C’est pour cela qu’on parle de données « terrain ». Elles vont permettre de raccourcir le temps de réaction des développeurs, d’alerter les équipes qui dégradent ou impactent les performances du site, mais aussi et surtout de résoudre les problèmes de performances à des niveaux macro et micro.

Les Core Web Vitals sont donc des métriques centrées sur l’utilisateur, qui n’ont pas d’influence les unes sur les autres, et directement mesurées sur l’appareil de l’utilisateur. Nous avons :

– Le « Largest Contentful Paint » – c’est-à-dire le temps de rendu du plus grand élément de contenu visible (image ou bloc texte).

– Le « First Input Delay » – Que l’on peut traduire par le temps nécessaire afin de pouvoir réaliser la première interaction avec le site.

– Le « Cumulative Layout Shift » – Qui correspond à la stabilité graphique de la page lors de son chargement.

Les clés du Largest Contentful Paint

Comme précisé précédemment, la métrique « Largest Contentful Paint » correspond à une mesure du temps entre le moment où la page commence son chargement et le moment où la partie principale du contenu de la page est rendue à l’écran.

Comme précisé par W3CW3C signifie World Wide Web Consortium., le « Largest contentful Paint » considère comme un contenu les éléments suivants :

– Les éléments <img>

– Les éléments <image> à l’intérieur d’une balise <svg>

– Les éléments <video> (l’image de l’affiche est utilisée)

– Un élément avec une image de fond chargée via la fonction url()

– Un élément de bloc

L’élément sera considéré comme principal à partir du moment où celui-ci est le plus important et visible dans la fenêtre de l’utilisateur. Sans considération pour les marges, bordures ou remplissage appliqués par le code CSS.

Comment mesurer son Largest Contentful Paint

Il est possible de mesurer son LCP avec des outils de laboratoire, principalement utiles pour tester des pages en préproduction :

– Chrome DevTools

– Lighthouse

– WebPageTest

Malgré tout, il est conseillé, voire encouragé, d’utiliser des outils de « terrain » afin de mesurer correctement ce Signal Vital Web :

– Rapport d’expérience utilisateur Chrome

– PageSpeed Insights

– Google Search Console

– Web-vitals Bibliothèque JavaScript

Améliorer son Largest Contentful Paint

Le Largest Contentful Paint est principalement affecté par quatre facteurs :

– Un temps de réponse de serveur lent (un « time to first byte » élevé, c’est-à-dire supérieur à 200 ms peut-être un indicateur de problématique serveur). En outre, posséder un serveur mutualisé et non dédié favorise les risques de temps de réponse des serveurs élevés.

– Le JavaScript et CSS bloquant le rendu, il est courant que des ressources JS ou CSS soit bloqué, cela peut être aussi dû à de mauvaises règles dans le fichier robots.txtLe fichier Robots.txt est placé à la racine d’un site web. ou dans le fichier racine HTACCESS.

– Le temps de chargement des ressources. Généralement, c’est une des variables les plus simples à optimiser puisque beaucoup de sites chargent des éléments inutiles au bon fonctionnement d’une page.

– Le rendu côté client.

Les solutions les plus simples et faciles à mettre en place sont généralement l’optimisation du CSS et JavaScript en éliminant les ressources inutiles, puis l’optimisation des images qui est une problématique récurrente en SEO. Par la suite, l’optimisation des polices Web et pour finir le « critical rendering path » qui consiste à prioriser les éléments que vous allez afficher à l’utilisateur de manière à ce que ceux de la partie visible de la page se charge en premier lieu et soit interactive avant la fin complète du chargement.

Cumulative Layout Shift ou la Stabilité Graphique

Le « Cumulative Layout Shift », soit le « décalage cumulatif de la mise en page » mesure le score cumulé de tous les décalages de mise en page. Son score doit être inférieur à 0,1 et le plus proche possible de 0.

Pour toutes les Core Web Vitals, la mesure à interpréter en utilisant les 75^e centiles de toutes les pages vues de cette page ou du site.

C’est-à-dire que si au moins 75 % des pages sont inférieurs à la notation 0,1, on peut considérer le seuil de « bon » d’atteint. Globalement, il prendra en compte la stabilité graphique de vos pages, attention au JavaScript !

First Input Delay (FID), la métrique de la frustration

Cette métrique consiste à mesurer le temps écoulé entre le moment où un utilisateur interagit pour la première fois avec votre site (par exemple, qu’il clique sur un lien ou un bouton) et le moment où le navigateur est réellement capable de répondre à l’interaction.

On la considère généralement comme la métrique de la frustration :

Quoi de plus terrible que de voir une page correctement affichée sur votre écran, qui semble charger et pourtant ne pouvoir interagir avec aucun élément ? À ce moment, vous cliquerez de manière effrénée sur l’ensemble des éléments affichés sur votre écran par impatience, puis c’est généralement à ce moment que le navigateur répondra, et que vous cliquerez involontairement sur le mauvais lien, dédoublement de votre frustration assurée !

Donc si vous essayez d’avoir une interaction avec la page (clic, bouton) et que celle-ci met moins de 100 ms à répondre, le FID est considéré comme BON.

Plus le temps de réaction est faible, plus la frustration le sera aussi.

Nous connaissons maintenant les métriques, leurs définitions, la manière de les mesurer, mais beaucoup de questions perdurent :

Core Web Vitals et Scripts tiers ?

Si les Core Web Vitals des sites sont définissables, observables et modifiables pour les scripts internes au site, qu’en est-il des applications et outils tiers qui foisonnent dans l’environnement technique des sites aujourd’hui ? On peut citer, dans les plus communs : Google Analytics, Avis vérifiés, etc. Les robots de Google prendront-ils en compte le poids supplémentaire de ces éléments ? Il est très probable que oui, ce qui à terme, impliquera de vrais choix technologiques pour l’ensemble des entreprises, au-delà des développeurs et des référenceurs.

Les performances, un futur critère premium ?

À quoi s’attendre ? Une réelle transformation de la SERP dès mai où un épouvantail du même type que « Mobilegeddon« , une mise à jour Google de 2015 priorisant les sites optimisés pour les mobiles dans la SERP et qui se révéla bien moins dévastateur qu’envisagé. En réalité, il est fort probable que le contenu reste l’élément roi pour le référencement de vos pages. Et que dans les faits, les Core Web Vitals ne représentent que les balbutiements de l’inscription de Google dans une optique de référencement orienté expérience utilisateur. En revanche, c’est une réelle démonstration de l’orientation future que les ingénieurs de Google souhaitent prendre.

En outre, les Core Web Vitals ont un réel impact dans tous les éléments joints au SEO : l’utilité d’accroître son positionnement et donc son trafic n’obtient sa finalité que dans la croissance du chiffre d’affaires ou de la prise de contact, et par essence, du taux de conversion des pages. Et l’on connait depuis longtemps l’impact des temps de chargement et de l’expérience utilisateur sur ces métriques.

En conclusion, beaucoup d’interrogations demeurent et il est difficile de ne pas tomber dans la prospective avec Google. Dans les faits, les référenceurs et développeurs devraient surveiller les Core Web Vitals depuis hier, les optimiser aujourd’hui, et ce dans l’optique de prévenir demain.