Comment améliorer les Core Web Vitals

Les Core Web Vitals (CWV) sont un ensemble de métriques qui aident Google à évaluer les performances globales des pages web.

Ces trois métriques sont :

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Chacune des trois Core Web Vitals représente un aspect distinctif de l’expérience utilisateur.

Avec d’autres web vitals, LCP, FID et CLS font partie des signaux d’expérience de page de Google qui sont utilisés à des fins de classement.

Les CWV mesurent et évaluent trois aspects des pages web : le chargement, l’interactivité et la stabilité visuelle.

La première Core Web Vital est le LCP (Largest Contentful Paint). La métrique LCP est utilisée pour mesurer le temps qu’il faut à l’image ou au bloc de texte le plus grand dans une fenêtre d’affichage prédéfinie pour devenir visible à partir du moment où une page commence à se charger. Le benchmark actuel de Google pour Largest Contentful Paint est inférieur à 2,5 secondes.

La deuxième Core Web Vital de Google est le FID (ou First Input Delay). La métrique FID évalue la réactivité de la page et mesure le temps qu’il faut à une page pour réagir à l’entrée de l’utilisateur (clic, toucher ou pression de touche). Un bon First Input Delay est considéré comme inférieur à 100 millisecondes.

Enfin, la métrique CLS mesure la stabilité visuelle d’une page. Si les pages web ont des éléments instables pendant le chargement de la page, le score CLS sera médiocre. Un bon score Cumulative Layout Shift devrait être égal ou inférieur à 0,1.

Comment les Core Web Vitals corrélationnent avec les impressions et les clics organiques

Si vous lisez l’une des études de cas sur les Core Web Vitals, vous trouverez de nombreuses informations contradictoires sur la mesure dans laquelle un bon score CWV corrélationne avec les impressions et les clics organiques. J’ai délibérément inclus cette section au début de l’étude pour montrer comment l’optimisation des CWV a fonctionné pour nous et pourquoi nous en avons fait l’une de nos principales priorités pour l’année en cours.

Le rapport CWV dans Google Search Console a un plafond de 3 mois sur les données disponibles. Ainsi, pour suivre nos progrès plus facilement que les outils de Google, nous avons créé une intégration entre l’API de Google Search Console et PowerBI de Microsoft. De cette façon, nous avons pu combiner toutes les données dans un tableau de bord unique et collecter toutes les données historiques sans limites.

Point de départ

Tout le processus d’optimisation des CWV a commencé par la vérification de notre situation actuelle dans Google Search Console.

En plus de Search Console, vous pouvez utiliser PageSpeed Insights de Google pour vérifier les CWV sur votre site web. Cependant, il est important de comprendre la différence clé entre les deux et comment ils évaluent les CWV.

Search Console est basé sur les données de terrain, c’est-à-dire les données du rapport d’expérience utilisateur Chrome (CrUX), ce qui signifie que les scores CWV sont basés sur la façon dont les utilisateurs réels vivent l’expérience des pages. Ces données sont mises à jour tous les 28 jours, vous devez donc attendre tout ce temps avant de pouvoir voir les résultats des améliorations de performances.

PageSpeed Insights détermine les scores sur la base de données de laboratoire, une simulation de ce que Google considère comme un utilisateur web moyen. Vous pouvez vérifier n’importe quelle page à tout moment.

Donc, PageSpeed Insights est utile lorsque vous souhaitez obtenir une estimation rapide de ce qui se passe avec les CWV sur une page donnée.

Comment nous avons amélioré les métriques des Core Web Vitals

Lorsque nous avons découvert pour la première fois les trois Core Web Vitals, leur optimisation nous a semblé une tâche triviale. Nous consultions le rapport Lighthouse, PageSpeed Insights et Search Console et suivions les recommandations qui nous étaient données. Qu’est-ce qui aurait pu mal tourner ?

Quelques semaines plus tard seulement, nous nous sommes rendu compte qu’il pouvait y avoir des centaines de problèmes menant à des scores CWV médiocres. Ainsi, pour partager notre expérience et vous faire gagner beaucoup de temps, j’ai fait de mon mieux pour rassembler tout ce qui a été fait dans un format facilement compréhensible.

Préparation de serveurs et de CDN géospécifiques

– Métriques concernées : TTFB, LCP –

Le temps de réponse du serveur est crucial et peut annuler tous les efforts d’optimisation des CWV s’il n’est pas traité en amont. L’une des métriques qui aident Google à évaluer le temps de réponse d’un serveur s’appelle Time to First Byte (TTFB) et, bien qu’il ne s’agisse pas d’une Core Web Vital, elle fait partie d’autres Web Vitals.

Le TTFB mesure le temps qui s’écoule entre le moment où un utilisateur arrive sur un site web et le moment où la première « bouchée » d’informations est chargée. Habituellement, le TTFB devrait être inférieur à 600 ms.

Un TTFB médiocre affecte négativement le LCP, il est donc crucial de le rendre aussi bas que possible. Dans la plupart des cas, le score TTFB peut être amélioré simplement en passant à un meilleur fournisseur d’hébergement. Cependant, ce n’était pas le cas de link-assistant.com.

Link-assistant.com a une audience mondiale et Google utilise les données de surveillance de l’utilisateur réel (RUM) pour déterminer si une page spécifique répond aux critères des Web Vitals. Cela signifie que si le TTFB est bon pour, par exemple, les États-Unis et mauvais pour l’Inde, ce dernier abaissera le score final du TTFB.

Avant que les CWV ne deviennent si importantes, nous n’avions qu’un seul emplacement de serveur, aux États-Unis. Évidemment, ce n’était pas suffisant pour un site web ayant une audience multinationale.

Cela nous a conduit à l’hypothèse que les volumes de trafic provenant d’Inde étaient trop élevés pour un seul serveur. Donc très probablement le serveur était surchargé, ce qui entraînait un très mauvais TTFB pour tous les emplacements autres que l’Inde. Nous avons donc ajouté deux nouveaux serveurs : un à Osaka et un autre à Singapour.

Comme les serveurs supplémentaires n’ont été ajoutés qu’il y a environ une semaine, nous devrons attendre que les résultats finaux se manifestent. Cependant, l’amélioration est déjà visible pour la plupart des emplacements.

Le même problème avec le TTFB a été observé dans les Amériques. Non seulement les scores TTFB ne se sont pas améliorés pour les emplacements aux États-Unis, mais il y avait également des temps de réponse de serveur énormément élevés pour les utilisateurs au Brésil et au Chili.

Ici, nous avons tiré quelques conclusions. Premièrement, notre trafic organique dans les Amériques est aussi important qu’en Inde, donc deux serveurs ne sont probablement pas en mesure de gérer le flux sans compromettre le TTFB.

Deuxièmement, l’un de nos serveurs était sur Wowrack. Notre équipe de développement a découvert que ce serveur était gravement surchargé, avait des spécifications techniques plutôt datées et se trouvait dans la zone tristement célèbre de l’« Internet plus ancien » sur la côte ouest des États-Unis, ce qui a entraîné des retards de connexion significatifs entre les utilisateurs et le serveur lui-même.

Comme solution finale, nous avons récemment configuré un serveur AWS supplémentaire, donc nous avons maintenant trois serveurs aux États-Unis. Les résultats des améliorations que nous avons apportées ne sont pas encore significatifs, mais nous les surveillerons de près et mettrons à jour cette étude par la suite.

Dans l’ensemble, l’optimisation du TTFB pour link-assistant.com nous a permis d’améliorer significativement cette métrique, ce qui a à son tour entraîné une amélioration également du LCP. Un résultat gagnant pour nous.

De plus, lorsque nous étions certains que le TTFB était suffisamment bon, nous nous sommes assurés que tous nos actifs statiques (images, CSS, Javascript) étaient chargés à partir de CDN plutôt que de nos serveurs. Bien qu’indirectement, avoir tous les actifs statiques sur des CDN contribue à améliorer les scores TTFB, car les serveurs ne sont pas surchargés de requêtes supplémentaires pour charger des images, du CSS ou du JS.

Note

Acquérir des serveurs supplémentaires est une solution coûteuse, qui n’est pas obligatoire à 100 % des cas. Si votre site web dessert une audience locale, vous pouvez tranquillement utiliser un seul serveur près de votre public cible. Si des problèmes avec le TTFB surviennent, essayez des solutions moins radicales, comme changer de fournisseur d’hébergement. Si les problèmes persistent, consultez cet article de Google.

Reporter les JS de tiers

– Métriques concernées : LCP –

Les JS de tiers incluent tout, des boutons de partage Facebook aux traqueurs de Google Analytics présents sur une page. Ces éléments de page consomment toujours beaucoup de ressources de rendu. De plus, chaque fois qu’un navigateur détecte un tel morceau de JS, il interrompt le rendu de l’HTML jusqu’à ce qu’il ait fini de rendre le JS. Tout cela conduit inévitablement à un mauvais LCP.

Ce que nous avons fait, c’est d’abord analyser quels JS bloquant le rendu nous avions sur nos pages. D’après notre recherche, nous avons vu que les principaux bloqueurs étaient les boutons de partage sur les réseaux sociaux, les blocs de commentaires Facebook, les intégrations YouTube et Sleeknote, que nous utilisions pour les pop-ups.

Par exemple, les vidéos intégrées de YouTube à elles seules pouvaient contribuer jusqu’à 30 % de gain de temps pour le LCP :

Bien que ce ne fût pas obligatoire, nous nous sommes débarrassés de tous les scripts de tiers là où c’était possible pour obtenir de meilleurs scores LCP.

En même temps, il y avait des pages où nous voulions conserver les boutons de partage sur les réseaux sociaux, Sleeknote ou les traqueurs GA.

Pour conserver ces éléments de page sans compromettre le LCP, nous les avons déplacés hors du chemin de rendu critique. Cela a été fait en ajoutant l’un des attributs suivants à la balise <script> :

• Async. Cet attribut indique au navigateur d’exécuter le script de manière asynchrone sans interrompre l’analyse d’une page. Nous avons utilisé cet attribut pour les scripts qui étaient sensibles au chargement différé (Google Analytics) :

Juste pour être complet, voici une explication visuelle des attributs defer et async :

Il convient de noter qu’il faut éviter d’utiliser l’attribut defer et utiliser async pour divers scripts de suivi. Dans notre cas, il nous manquait près de 15 % des données d’objectifs dans Google Analytics après avoir déplacé le script de suivi à la fin du chemin de rendu.

Note

La même technique a été appliquée à notre JS personnalisé. Nous avons examiné tout le Javascript utilisé sur nos pages et analysé les parties qui étaient inutiles pour les éliminer et les parties qui devaient être conservées : dans la plupart des cas, nous les avons faites charger de manière asynchrone avec l’attribut async.

2. Optimisation de l’utilisation des polices

– Métriques concernées : LCP, CLS –

Les polices web sont essentielles pour un design attrayant, une meilleure lisibilité et l’identité de la marque, mais ce sont aussi des fichiers lourds qui peuvent prendre du temps à se charger et nuire à la fois au LCP et au CLS.

Si une police tierce est utilisée pour un bloc de texte qui représente l’élément LCP, le score LCP peut être affecté négativement car le navigateur mettra du temps à charger et à récupérer cette police.

En ce qui concerne le Cumulative Layout Shift, le principal problème des polices tierces est qu’avant le chargement d’une police spécifique, le navigateur affichera une police système. Une fois chargée, la police tierce peut occuper plus d’espace sur l’écran, affectant ainsi la stabilité visuelle d’une page, provoquant un décalage de la mise en page et entraînant un mauvais score CLS.

Voici à quoi ressemble le décalage de la mise en page :

Avant que les Core Web Vitals ne deviennent une chose, nous avions beaucoup de polices différentes sur une seule page.

Parfois, ces polices n’étaient même pas utilisées mais étaient quand même chargées. Comme vous pouvez le voir sur la capture d’écran ci-dessous.

La police Roboto était utilisée exclusivement dans l’infobulle contextuelle, qui n’était pas visible sur les appareils mobiles, mais en même temps, la police était toujours chargée.

Nous utilisions également de nombreuses polices externes, comme les Google Fonts, qui étaient stockées en dehors de notre serveur.

Donc, la première chose que nous avons faite a été d’éliminer toutes les polices externes et de passer aux polices système (Arial, Helvetica, Verdana, Tahoma, etc.). Cette solution simple a superbement fonctionné pour nous et nous avons constaté une grande amélioration des scores LCP et CLS.

Nous avons également compris qu’il pourrait y avoir des cas où nous aurions besoin d’utiliser des polices tierces. Pour de tels cas, nous rendons la police auto-hébergée sur nos serveurs et la préchargeons dans la section head de l’HTML d’une page. Pour finir, nous nous sommes également assurés de ne pas utiliser de polices d’icônes. Ce sont les polices utilisées pour remplacer les images schématiques, comme une loupe, utilisée pour les barres de recherche. Ces icônes ont été remplacées par des images SVG hébergées sur nos serveurs afin que le navigateur n’ait pas à les charger à partir de sources externes à chaque fois.

Note Importante

L’auto-hébergement des polices web pourrait ne pas aider à améliorer le LCP si votre site web n’utilise pas de CDN et HTTP/2. Essayez d’expérimenter avec des polices auto-hébergées et tierces pour voir quelle solution vous convient le mieux.

3. Extraire les CSS et JS critiques

– Métriques concernées : LCP –

Le CSS est une ressource qui bloque le rendu, ce qui signifie qu’une page ne peut pas être rendue tant que le navigateur n’a pas récupéré et analysé tous les fichiers CSS. Si le CSS est lourd, il faudra beaucoup de temps pour le charger, ce qui affecte directement le score LCP.

Dans notre cas, ce n’était pas seulement la taille du CSS que nous utilisions. Avant le début des travaux d’optimisation, nous avions une seule feuille de style CSS pour toutes les pages, avec plus de 70 000 lignes. Le même CSS lourd était chargé pour chaque page, même s’il n’était pas réellement utilisé là.

Pour résoudre ce problème, nous avons d’abord consulté le rapport de couverture dans les outils pour développeurs de Chrome. Nous avons ensuite examiné tout le contenu de ce fichier CSS et nous sommes débarrassés de toutes les lignes inutiles. Cela nous a permis de réduire considérablement sa taille effective et le pourcentage de bytes inutilisés.

Note

Pour réduire davantage la taille de nos fichiers CSS et nous assurer qu’ils n’affectent pas négativement le score LCP, nous les avons également soumis à un processus de minification du CSS.

Les feuilles de style CSS contiennent souvent des commentaires, des espaces et des retours à la ligne superflus, et s’en débarrasser peut souvent aider à réduire la taille finale du fichier jusqu’à 50 %. Nous avons utilisé CSS Minifier pour réduire la taille de notre CSS et JSCompress pour faire de même avec le Javascript qui bloque le rendu.

Finalement, notre équipe de développement a développé un outil dédié, qui gère désormais la minification de manière automatique.

De plus, tout comme pour le JS, il n’était pas nécessaire de charger le même énorme CSS pour chaque page à chaque fois. Nous avons donc extrait uniquement les styles nécessaires pour la zone au-dessus du pli d’une page spécifique et les avons ajoutés au fichier HTML de cette page.

4. Compression du contenu HTTP

– Métriques concernées : LCP –

La compression du contenu HTTP est une excellente pratique pour réduire la taille des fichiers transférés entre le serveur et le navigateur. Cela peut réduire significativement les temps de chargement des pages et améliorer le score LCP.

Pour compresser le contenu HTTP, nous avons configuré la compression gzip sur notre serveur. Cela a permis de réduire considérablement la taille des fichiers qui sont envoyés au navigateur, améliorant ainsi le LCP.

La compression gzip est une technique de compression de données qui réduit la taille des fichiers sans perte d’informations. Cela permet de transférer les fichiers plus rapidement et donc d’améliorer le temps de chargement des pages.

5. Optimisation des images

– Métriques concernées : LCP –

Les images non optimisées peuvent ralentir le chargement des pages et affecter négativement le score LCP. Par conséquent, nous avons accordé une attention particulière à l’optimisation des images pour améliorer les performances des Core Web Vitals.

Pour optimiser les images, nous avons suivi les étapes suivantes :

• Nous avons redimensionné les images aux dimensions réelles où elles doivent être affichées sur la page. Réduire les dimensions physiques des images peut réduire significativement leur taille de fichier et accélérer le processus de chargement.
• Nous avons utilisé un format de compression adapté à chaque image. Par exemple, les images avec peu de détails et des couleurs plates ont été converties en formats comme PNG ou SVG, qui offrent une meilleure compression pour ce type d’images. Les images avec beaucoup de nuances ou de détails complexes ont été converties au format JPEG, qui est plus adapté aux images complexes.
• Nous avons utilisé des outils de compression d’images pour réduire davantage la taille des fichiers. Ces outils réduisent la taille des fichiers sans perte de qualité visuelle.
• Nous avons mis en œuvre la compression progressive des images pour améliorer l’expérience utilisateur pendant le chargement des pages. La compression progressive permet d’afficher un aperçu de l’image pendant son chargement, plutôt que d’attendre le chargement complet.

L’optimisation des images a eu un impact significatif sur le score LCP et sur le temps de chargement des pages en général. Nous avons constaté une amélioration notable des performances après avoir mis en œuvre ces optimisations.

6. Derniers ajustements

Après avoir accompli les étapes précédentes, nous avons effectué les derniers ajustements pour optimiser davantage les Core Web Vitals.

Nous avons effectué une analyse approfondie de nos pages pour identifier d’autres problèmes potentiels qui pourraient affecter le score des CWV. Par exemple, nous avons vérifié s’il y avait des scripts ou des ressources supplémentaires qui bloquaient le rendu ou causaient des retards dans l’interactivité.

Nous avons également vérifié l’utilisation des cookies sur notre site web et avons minimisé le nombre de cookies utilisés pour éviter des ralentissements de performance.

Enfin, nous avons effectué de nombreux tests et surveillé constamment les performances des Core Web Vitals en utilisant des outils tels que Google Search Console, PageSpeed Insights et Lighthouse.

Résultats des optimisations des Core Web Vitals

Après avoir effectué toutes les optimisations décrites ci-dessus, nous avons constaté une amélioration significative des scores des Core Web Vitals.

Le score LCP s’est considérablement amélioré, avec un temps de chargement inférieur à 2,5 secondes. Le score FID a diminué à moins de 100 millisecondes, rendant la page plus réactive à l’entrée de l’utilisateur. Le score CLS est resté inférieur à 0,1, assurant une plus grande stabilité visuelle.

Ces améliorations ont eu un impact direct sur les performances globales des pages. Nous avons observé une augmentation significative des clics organiques et des impressions, indiquant une meilleure expérience utilisateur et un meilleur positionnement dans le classement de Google.

L’optimisation des Core Web Vitals est un processus continu

Il est important de souligner que l’optimisation des Core Web Vitals est un processus continu. Les performances des pages peuvent se détériorer avec le temps en raison de nouvelles modifications ou mises à jour, il est donc fondamental de surveiller constamment les CWV et d’apporter les corrections ou améliorations nécessaires.

Nous continuerons à surveiller les Core Web Vitals de link-assistant.com et à mettre en œuvre d’autres optimisations si nécessaire. Maintenir une bonne expérience utilisateur et un classement élevé dans Google est essentiel pour le succès de notre site web.

Considérations Finales

Les Core Web Vitals sont devenues un facteur de classement essentiel pour Google. Optimiser les CWV peut avoir un impact significatif sur les performances des pages, l’expérience utilisateur et le positionnement dans le classement de Google.

Dans notre étude de cas sur les Core Web Vitals, nous avons démontré comment nous avons amélioré les CWV pour link-assistant.com et comment cela nous a aidés à nous remettre d’une baisse soudaine de position dans le classement.

Les optimisations que nous avons effectuées incluent la configuration de serveurs et de CDN géospécifiques, le report des JS tiers, l’optimisation de l’utilisation des polices, l’extraction de CSS et JS critiques, la compression du contenu HTTP, l’optimisation des images et les derniers ajustements.

Ces optimisations ont conduit à une amélioration significative des Core Web Vitals et ont eu un impact positif sur les performances des pages et les résultats organiques.

N’oubliez pas que l’optimisation des Core Web Vitals est un processus continu. Il est important de surveiller constamment les performances des pages, d’apporter des corrections ou des améliorations et de rester à jour sur les dernières directives et meilleures pratiques de Google pour garantir une expérience utilisateur optimale et un positionnement élevé.

Article tiré de Link-Assistant

Pubblicato in Marketing Digital, SEO