Google a pour mission d’améliorer les performances du Web avec les signaux web essentiels (Core Web Vitals). Pourquoi ? Parce que l’activité de Google est principalement basée sur le web – les sites et les applications web lents poussent les utilisateurs à se tourner vers les applications natives.
Votre position dans les résultats de recherche de Google est largement déterminé par les mots-clés du terme de recherche, l’utilisation de ces mots-clés dans votre page et la popularité de votre page en fonction du nombre (et de la qualité) des liens provenant d’ailleurs. À partir d’août 2021, Google s’efforce également d’évaluer les pages en fonction de leurs performances.
Cet article vous montrera comment optimiser votre site pour les mesures des signaux web essentiels de Google.
Pourquoi les Core Web Vitals ?
Le contenu reste crucial. Mais si vous comparez deux sites dont le texte et la popularité sont similaires, celui qui offre la meilleure expérience web aura une priorité plus élevée dans les résultats de recherche Google.
En plus d’un classement de page amélioré, les sites performants peuvent être inclus dans le carrousel de recherche mobile. Cela était auparavant réservé aux pages mobiles accélérées (AMP), qui nécessitaient de porter le contenu sur un site séparé hébergé par Google. AMP a suscité des critiques, notamment parce que les pages ne sont pas toujours plus rapides qu’un site WordPress ou statique bien optimisé. Cependant, ce n’est plus une obligation.
Peu importe votre choix, plus votre site est rapide et responsive, plus il a de chances d’être mieux classé dans les résultats de recherche de Google.
Quand vous savez que la page moyenne fait environ 2 Mo, qu’elle effectue plus de 60 requêtes HTTP et qu’il faut 16 secondes pour qu’elle soit entièrement rendue sur un appareil mobile, vous vous rendez compte qu’il y a de la marge pour améliorer votre site. Nous allons vous montrer les meilleures façons de réaliser ces améliorations.
Les principaux facteurs de classement de Google
Il y a quatre facteurs de classement clés à examiner avant de commencer à évaluer les performances :
- HTTPS : HTTPS est essentiel. Votre site établit-il une connexion sécurisée entre le navigateur de l’utilisateur et le serveur web ?
- Adaptabilité mobile : Votre site doit bien fonctionner sur un appareil mobile. Votre site est-il utilisable sur les appareils à petit écran ? Effectue-t-il un rendu sans débordement de contenu ? Le texte est-il suffisamment grand ? Les zones cliquables sont-elles suffisamment adaptées pour le contrôle tactile ?
- Pas d’interstitiels : Évitez les interstitiels intrusifs qui nécessitent une quantité déraisonnable d’espace d’écran. Votre contenu est-il toujours lisible ? Est-il partiellement obscurci par des interstitiels ou des bannières popups ? Votre publicité ou vos promotions marketing rendent-elles le site difficile à utiliser ?
- Navigation sûre : Votre site doit être exempt de logiciels malveillants, de virus, d’hameçonnage, de fraude et d’autres escroqueries.
Une fois que vous aurez satisfait à ces pré-requis, les performances de votre site seront évaluées.
Comment Google évalue-t-il les performances web ?
Faire en sorte que votre site se charge rapidement, s’affiche plus vite et soit responsive plus tôt est vital. Mais est-ce qu’il donne l’impression d’être rapide aux utilisateurs ?
Les applications de mesure des performances comme Browser DevTools rapportent des mesures techniques telles que :
- Temps de blocage : Le temps passé à attendre le début d’un téléchargement, généralement parce que d’autres ressources comme les feuilles de style et les scripts ont une priorité plus élevée.
- Résolution DNS : Le temps de résolution d’un nom d’hôte en une adresse IP pour récupérer une ressource.
- Temps de connexion : Le temps d’initialisation d’une connexion TCP.
- Temps jusqu’au premier octet (Time to Fist Byte ou TTFB) : Le temps total entre la requête et le premier octet de la réponse.
- Temps de réception : Le temps pour récupérer l’intégralité de la ressource.
- Temps de chargement DOM : Le temps de téléchargement et de rendu du Document Object Model HTML. C’est généralement le premier moment où les scripts qui analysent ou modifient le DOM peuvent s’exécuter de manière fiable.
- Temps de chargement de la page : Le temps de téléchargement de la page et de toutes les ressources telles que les images, les feuilles de style, les scripts, etc.
- Poids total de la page : La taille totale de toutes les ressources. Il est souvent indiqué à la fois une taille compressée (téléchargement) et une taille non compressée.
- Le nombre d’éléments DOM : Le nombre total d’éléments HTML sur la page. Plus il y a d’éléments, plus la page prend du temps à traiter.
- First Contentful Paint (FCP) : Le temps nécessaire avant que le navigateur ne rende le premier pixel de contenu.
- First Meaningful Paint (FMP) : Le temps avant que le contenu principal de la page ne devienne visible pour l’utilisateur.
- Temps d’interactivité (Time To Interactive ou TTI) : Le temps nécessaire avant qu’une page soit entièrement interactive et puisse répondre de manière fiable aux entrées de l’utilisateur.
- First Time CPU Idel : Le temps que met le CPU à rendre la page et à exécuter tous les scripts d’initialisation, en attendant d’autres entrées.
- Utilisation du CPU : L’activité de traitement nécessaire pendant le rendu de la page et la réponse aux entrées de l’utilisateur.
- Mises en page par seconde : La vitesse à laquelle le navigateur doit recalculer les styles et les mises en page.
Elles peuvent être utilisées pour déterminer des goulots d’étranglement spécifiques tels que la charge du serveur, la mise en cache du CMS, la mise en cache du navigateur, les vitesses de téléchargement et l’efficacité de JavaScript. Mais elles ne peuvent pas déterminer si une page offre une bonne ou une mauvaise expérience utilisateur. Par exemple :
- Une application pourrait se télécharger et apparaître rapidement mais devenir insensible après la première interaction car elle exécute une grande quantité de code JavaScript non optimisé.
- Une application de discussion en direct pourrait télécharger continuellement des données à mesure que les utilisateurs publient des messages. Un outil d’évaluation pourrait supposer qu’il n’a jamais terminé le chargement, même si la page semble réactive.
Les signaux essentiels du web sont la tentative de Google de résoudre ces dilemmes.
Que sont les Core Web Vitals ?
Les signaux essentiels du web (Core Web Vitals ou CWV) de Google sont trois mesures de performance qui évaluent l’expérience des utilisateurs dans le monde réel :
- Largest Contentful Paint (LCP) : Performances de chargement
- First Input Delay (FID) : Performances d’interactivité
- Cumulative Layout Shift (CLS) : Performances en matière de stabilité visuelle
Cette nouvelle mise à jour de l’algorithme de Google a commencé à être déployée dans le monde entier d’ici fin août 2021. Les mesure des signaux essentiels du web affectent principalement les résultats de recherche sur mobile, mais des équivalents pour ordinateur de bureau suivront si l’expérience est réussie.
Les scores LCP, FID et CLS d’une page sont basés sur les 28 derniers jours de mesures d’utilisateurs réels collectées anonymement via le navigateur Chrome. Ces mesures peuvent varier en fonction de l’appareil de l’utilisateur, de sa connexion et d’autres activités simultanées, c’est pourquoi le 75e percentile est calculé plutôt qu’une moyenne.
En d’autres termes, les mesures de tous les utilisateurs sont triées du meilleur au pire, et le chiffre situé aux trois quarts est retenu. Trois visiteurs du site sur quatre connaîtront donc ce niveau de performance ou mieux.
Toute page qui obtient un bon score (vert) pour les trois mesures des signaux essentiels du web sera mieux classée dans les résultats de recherche et sera incluse dans le carrousel « Top Stories » de l’application Google News.
Dans les sections suivantes, nous décrirons l’algorithme utilisé pour calculer une mesure, les outils que vous pouvez utiliser pour identifier le score d’une page, les causes typiques des mauvais scores et les mesures que vous pouvez prendre pour résoudre les problèmes de performance.
Largest Contentful Paint (LCP)
Largest Contentful Paint mesure les performances de chargement. En gros, à quelle vitesse le contenu utilisable est-il rendu sur la page ?
LCP analyse le temps qu’il faut à la plus grande image ou au plus grand bloc de texte pour devenir visible dans la fenêtre du navigateur (au-dessus du pli). Dans la plupart des cas, l’élément le plus visible sera une image Hero, une bannière, un titre ou un grand bloc de texte.
Tous les éléments suivants sont éligibles pour l’analyse du tableau le plus important du contenu :
- Images (élément
<img>) - Images à l’intérieur de graphiques vectoriels (une
<image>intégrée dans<svg>) - Miniatures vidéo (un attribut de poster défini sur une URL d’image dans
<video>) - Éléments avec images d’arrière-plan (généralement chargés avec la propriété CSS
background-image url()) - Éléments au niveau du bloc contenant du texte
Les pages où le tableau le plus volumineux est complété dans les 2,5 premières secondes du chargement de la page sont considérées comme bonnes (vertes). Les pages qui dépassent 4 secondes sont considérées comme mauvaises (rouge) :
Les plus grands outils d’analyse de Largest Contentful Paint
LCP est la mesure Core Web Vital la plus facile à comprendre, mais il n’est pas toujours évident de savoir quel élément sera choisi pour l’analyse.
Le panneau DevTools Lighthouse est fourni dans les navigateurs basés sur Chromium tels que Chrome, Edge, Brave, Opera et Vivaldi. Ouvrez DevTools à partir du menu du navigateur – généralement à l’aide de Plus d’outils > Outils développeur ou des raccourcis clavier Ctrl | Cmd + Shift + i ou F12 – puis accédez à l’onglet Lighthouse (les anciennes éditions peuvent le nommer Audit).
Générez un rapport de performance mobile, puis examinez la section Performance qui en résulte. LCP est affiché avec une section extensible, qui identifie l’élément choisi :
Vous pouvez générer des informations identiques dans les outils en ligne PageSpeed Insights et web.dev Measure si vous n’avez pas accès à un navigateur basé sur Chromium :
Le panneau Performance de DevTools affiche également un indicateur LCP. Pour commencer, cliquez sur l’icône circulaire Record, rechargez votre page, puis cliquez sur le bouton Stop pour afficher le rapport. Cliquez sur l’icône LCP dans la section Timings pour identifier l’élément et afficher un résumé des statistiques.
L’extension Web Vitals est disponible pour Google Chrome mais peut être installée sur la plupart des navigateurs basés sur Chromium. Elle calcule les mesures des signaux essentiels du web pour chaque site que vous visitez, et son icône devient verte, orange ou rouge en fonction du résultat. Vous pouvez également cliquer sur l’icône de l’extension pour afficher plus de détails sur LCP :
La Search Console de Google propose désormais une section Core Web Vitals si votre site est ajouté en tant que propriété. Le rapport illustre l’évolution des métriques CWV au fil du temps. Notez qu’il n’identifie pas les mesures LCP spécifiques, et que seuls les sites ayant un trafic raisonnablement élevé sont disponibles :
Le rapport sur l’expérience utilisateur de Chrome vous permet d’interroger les statistiques d’utilisation réelles, y compris le LCP à travers différents pays, connexions et appareils, pour une URL spécifique. Il s’agit d’un projet public sur Google BigQuery, vous devez donc vous inscrire à un compte Google Cloud Platform et fournir des détails de facturation. Encore une fois, le rapport ne sera utile que lorsqu’une URL a un niveau de trafic raisonnablement élevé.
Enfin, la bibliothèque JavaScript web-vitals est un petit script de 1 ko qui peut calculer LCP et d’autres mesures Core Web Vital pour des utilisateurs réels sur votre site en production. Comme il peut être téléchargé à partir d’un CDN, vous pouvez ajouter le script suivant à votre <head> HTML :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() est une fonction asynchrone à laquelle est transmise une fonction de rappel déclenchée lorsque la valeur LCP a été calculée (bien qu’elle puisse ne jamais se déclencher si la page se charge dans un onglet en arrière-plan). On passe à la fonction de rappel un objet contenant :
name: le nom de la mesure (« LCP » dans ce cas)value: la valeur calculéeid: un ID unique représentant cette mesure pour la page actuelledelta: le delta entre la valeur actuelle et la dernière valeur rapportéeentries: un tableau d’entrées utilisées dans le calcul de la valeur
Le script ci-dessus envoie l’objet à la console, bien qu’il soit plus pratique d’envoyer les données à un serveur ou à Google Analytics pour une analyse plus approfondie.
Causes communes des mauvais scores Largest Contentful Paint
Les mauvais scores LCP sont généralement dus à des pages à chargement lent qui empêchent le bloc le plus important d’apparaître rapidement :
- La réponse du serveur peut être lente parce qu’il est surchargé ou qu’il fait trop de travail pour rendre une page. Cela n’est pas forcément dû à votre site, mais à des contraintes de serveur si vous utilisez un service d’hébergement partagé.
- Les CSS et JavaScript qui bloquent le rendu peuvent retarder le chargement de la page s’ils sont référencés dans le HTML au-dessus du contenu principal.
- D’autres ressources, comme les images et les vidéos de grande taille, peuvent réduire la bande passante disponible et prendre plus de temps pour le rendu.
- Le contenu de la page généré sur le client plutôt que sur le serveur prend également plus de temps à s’afficher.
Comment améliorer les scores Largest Contentful Paint
Un audit approfondi peut identifier les problèmes de chargement, mais il s’agit généralement de réduire la quantité de données envoyées au navigateur. Les conseils suivants vous aideront à obtenir un meilleur score LCP :
- Mettez à niveau votre serveur et/ou votre service d’hébergement. Veillez à ce que les vitesses de téléchargement restent rapides, même en cas de forte utilisation.
- Activez la compression du serveur et HTTP/2+. Il n’y a aucune raison de ne pas le faire !
- Réduisez l’effort du serveur. Supprimez le code inutilisé et les extensions de CMS, puis activez une mise en cache efficace.
- Assurez-vous que le navigateur peut mettre les fichiers en cache de manière efficace. Définissez les hachages Expires, Last-Modified et/ou ETag appropriés dans l’en-tête HTTP, afin que les fichiers ne soient pas redemandés.
- Utilisez un réseau de diffusion de contenu (CDN) pour répartir la charge et héberger les ressources sur des serveurs géographiquement plus proches des utilisateurs.
- Améliorez votre optimisation globale en utilisant la fonction de minification du code intégrée au tableau de bord MyKinsta.
- Optimisez vos images. Réduisez-les à leurs plus petites dimensions et utilisez un format approprié pour minimiser la taille des fichiers. Veillez à ce que les images du bloc de contenu le plus important soient demandées le plus tôt possible ; un préchargement peut être utile.
- Chargez les images de manière différée en ajoutant un attribut
loading="lazy". Ajoutez des attributs de largeur et de hauteur pour vous assurer qu’un espace approprié est réservé sur la page avant que l’image ne termine son chargement. - Réduisez au minimum les requêtes tierces et envisagez de déplacer les ressources vers votre domaine principal pour éviter les consultations DNS superflues.
- Réduisez au minimum le nombre et la taille des fichiers demandés, surtout en haut de votre HTML.
- Veillez à ne charger que les polices web nécessaires. Passez à des polices web-safe afin d’obtenir des performances optimales.
- Supprimez les fichiers JavaScript et CSS inutilisés.
- Concaténez et minifiez vos fichiers JavaScript et CSS.
- Évitez les instructions CSS @import : elles bloquent le rendu et chargent les styles en série.
- Évitez le codage Base64 – il augmente la taille des fichiers et nécessite un traitement supplémentaire.
- Tenez compte des CSS critiques en ligne. Incorporez les feuilles de style CSS essentielles dans un bloc
<link>en haut de la page, puis chargez les autres feuilles de style de manière asynchrone. - Utilisez des modules JavaScript asynchrones, différés ou ES pour exécuter des scripts ultérieurement. Exécutez les processus JavaScript à long terme dans un worker de service.
First Input Delay (FID)
Fisrt Input Delay mesure la réactivité de votre page. En fait, à quelle vitesse réagit-elle aux actions de l’utilisateur telles que cliquer, saisir et faire défiler ?
La mesure FID est calculée comme le temps entre l’interaction de l’utilisateur et le traitement de sa requête par le navigateur. Elle ne mesure pas le temps d’exécution de la fonction de gestion, qui traite généralement l’entrée et met à jour le DOM.
Les pages dont le temps FID est inférieur ou égal à 100 millisecondes sont considérées comme bonnes (vertes). Les pages dépassant 300 millisecondes sont considérées comme mauvaises (rouge) :
First Input Delay.
Outils d’analyse First Input Delay
Le First Input Delay est impossible à simuler car il ne peut être mesuré que lorsque la page est servie à un utilisateur réel qui interagit avec la page. Le résultat dépend donc de la vitesse et des capacités du processeur de chaque appareil.
Le FID n’est pas calculé dans le panneau DevTools Lighthouse ou PageSpeed Insights. Cependant, ils peuvent déterminer le temps de blocage total (Total Blocking Time ou TBT). Il s’agit d’une approximation raisonnable du délai de première entrée. Il mesure la différence de temps entre :
- le First Contentful Paint (FCP), ou le moment où le contenu de la page commence à être rendu, et
- Le Time to Interactive (TTI), ou le moment où la page peut répondre aux entrées de l’utilisateur. Le TTI est présumé quand aucune tâche de longue durée n’est active et qu’il reste moins de trois requêtes HTTP à exécuter.
L’extension Web Vitals pour Google Chrome peut également afficher une mesure FID après avoir interagi avec la page en la faisant défiler ou en cliquant. Cliquez sur l’icône de l’extension pour obtenir plus d’informations :
À l’instar de LCP, le rapport sur l’expérience des utilisateurs de Chrome vous permet d’interroger les statistiques réelles du FID enregistrées dans différents pays, connexions et appareils pour une URL spécifique.
La bibliothèque JavaScript web-vitals peut également calculer les mesures FID pour des utilisateurs réels sur votre site en production. Vous pouvez ajouter le script suivant à votre HTML <head> pour transmettre les mesures FID à une fonction de rappel :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Causes courantes des mauvais résultats de First Input Delay
Les mauvais scores FID et TBT sont généralement causés par un code côté client qui accapare le processeur, comme par exemple :
- Des quantités importantes de CSS et de JavaScript bloquant le rendu, qui interrompent le chargement de la page pendant le téléchargement et l’analyse du code
- Des scripts volumineux et gourmands en ressources qui s’exécutent immédiatement au chargement de la page
- Des tâches JavaScript longues ou mal optimisées.
Par défaut, les navigateurs fonctionnent sur un seul thread, qui ne peut traiter qu’une seule tâche à la fois. Si l’exécution d’une fonction JavaScript prend une seconde, tous les autres processus de rendu sont bloqués pendant cette seconde. La page ne peut pas réagir aux entrées de l’utilisateur, mettre à jour le DOM, afficher des animations, etc. Même les animations GIF peuvent être bloquées dans les anciens navigateurs.
Comment améliorer les scores First Input Delay
Un audit JavaScript côté client peut identifier les problèmes, mais il s’agit généralement de supprimer le code redondant et de s’assurer que les tâches sont exécutées rapidement.
Les conseils suivants vous aideront à obtenir un meilleur score FID :
- Générez et mettez en cache autant de contenu HTML statique que possible sur le serveur. Essayez de ne pas compter sur les frameworks JavaScript côté client pour rendre le même HTML pour tout le monde.
- Assurez-vous que le navigateur peut mettre les fichiers en cache de manière efficace. Définissez les hachages Expires, Last-Modified et/ou ETag hashes dans l’en-tête HTTP, afin que les fichiers ne soient pas redemandés.
- Adoptez des techniques d’amélioration progressive, afin que l’interface soit utilisable en HTML et CSS avant l’exécution de JavaScript.
- Supprimez les fichiers JavaScript et CSS inutilisés.
- Concaténez et minifiez vos fichiers JavaScript et CSS.
- Évitez l’utilisation excessive de propriétés CSS gourmandes telles que box-shadow et filter.
- Utilisez le JavaScript asynchrone, différé ou le module ES pour exécuter les scripts ultérieurement.
- Réduisez au minimum les requêtes JavaScript de tiers pour les analyses, les widgets de réseaux sociaux, les forums de discussion, etc. Ces éléments peuvent rapidement atteindre plusieurs mégaoctets de JavaScript.
- Chargez de manière différée (Lazy Loading) les composants JavaScript à la demande, par exemple les widgets de discussion, les lecteurs vidéo, etc.
- Retardez le chargement des scripts moins critiques tels que les analyses, les publicités et les outils de réseaux sociaux.
- Divisez les tâches JavaScript à long terme en une série de tâches plus petites qui s’exécutent après un court délai requestIdleCallback, setTimeout ou requestAnimationFrame.
- Considérez l’exécution de processus JavaScript à long terme dans un worker web, qui utilise un thread d’arrière-plan.
Cumulative Layout Shift (CLS)
CLS mesure la stabilité visuelle de la page. En fait, le contenu de la page bouge-t-il ou saute-t-il inopinément, en particulier lors du chargement initial ?
CLS calcule un score lorsque des éléments se déplacent sans avertissement ni interaction de l’utilisateur. Vous avez probablement fait l’expérience de ce phénomène en lisant un article sur un appareil mobile : le texte saute soudainement hors de l’écran et vous perdez votre emplacement. Les pires exemples peuvent vous amener à cliquer sur un lien incorrect.
Les problèmes de CLS sont les plus flagrants lorsqu’une grande image ou une publicité se charge au-dessus de la position de défilement actuelle et qu’un espace à hauteur zéro s’agrandit instantanément de plusieurs centaines de pixels.
Les scores de Cumulative Layout Shift sont calculés en multipliant les mesures suivantes :
- La fraction d’impact : Il s’agit de la surface totale de tous les éléments instables dans le viewport, c’est-à-dire ceux qui vont « sauter ». Si des éléments couvrant 60 % de la fenêtre d’affichage sont déplacés pendant le chargement de la page, la fraction d’impact est de 0,6. Notez que les éléments à l’origine de ce déplacement, comme une image ou une publicité, sont considérés comme stables car ils ne se déplacent pas nécessairement après avoir été rendus.
- La fraction de distance : Il s’agit de la plus grande distance déplacée par un seul élément instable dans la fenêtre d’affichage. Si le plus grand déplacement se produit sur un élément qui passe de 0,100 à 0,800, il s’est déplacé de 700 pixels verticaux. Si la fenêtre du dispositif a une hauteur de 1 000 px, la fraction de distance est de 700 px / 1 000 px = 0,7. Le score cumulé de Cumulative Layout Shift calculé est donc de 0,6 x 0,7 = 0,42.
Google a apporté des modifications à la mesure CLS pour tenir compte des situations suivantes :
- Les changements de mise en page sont regroupés en « sessions » qui durent cinq secondes mais se terminent après une seconde si aucun autre changement de mise en page ne se produit. Si deux changements ou plus se produisent en une seconde, leurs scores sont additionnés.
- Les déplacements de mise en page ne sont pas enregistrés pendant 500 ms après l’interaction de l’utilisateur, comme un clic. Dans certains cas, cela déclenche des mises à jour du DOM (par exemple, l’ouverture d’un menu, l’affichage d’un message d’erreur, l’affichage d’une fenêtre modale, etc.)
- Les applications à page unique qui restent ouvertes pendant des périodes plus longues et qui effectuent de nombreuses mises à jour de DOM ne sont pas affectées.
Les pages dont le score CLS est inférieur ou égal à 0,1 sont considérées comme bonnes (vert). Les pages qui dépassent 0,25 sont considérées comme mauvaises (rouge) :
Outils d’analyse du Cumulative Layout Shift
Les mesures CLS sont calculées dans le panneau DevTools Lighthouse, PageSpeed Insights et les outils de mesure web.dev :
L’extension Web Vitals pour Google Chrome affiche également la mesure CLS :
À l’instar de LCP et FID, le rapport sur l’expérience utilisateur de Chrome vous permet d’interroger les statistiques réelles de CLS enregistrées dans différents pays, connexions et appareils pour une URL spécifique.
La bibliothèque JavaScript web-vitals peut également calculer les métriques CLS pour des utilisateurs réels sur votre site en production, tout comme elle le fait avec LCP et FID. Le script suivant pourrait être ajouté à votre HTML <head> pour sortir les mesures CLS vers une fonction de rappel :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Causes courantes des mauvais scores Cumulative Layout Shift
Les mauvais résultats de CLS sont généralement dus à des ressources de page à chargement lent et à des éléments DOM dynamiques ou non dimensionnés :
- L’espace de la page n’est pas réservé aux images, iframes, publicités, etc.
- Le contenu est injecté dynamiquement dans le DOM, généralement après une requête du réseau pour des publicités, des widgets de réseaux sociaux, etc.
- Le chargement des polices web provoque un Flash of Invisible Text (FOIT) ou un Flash of Unstyled Text (FOUT) perceptible.
Comment améliorer les scores Cumulative Layout Shift
Un audit côté client peut permettre d’identifier les problèmes, mais il s’agit généralement de s’assurer que l’espace est réservé au contenu avant son téléchargement. Les conseils d’optimisation du serveur suggérés pour Largest Contentful Paint auront un certain effet bénéfique, mais d’autres améliorations sont possibles :
- Ajoutez des attributs de largeur et de hauteur aux balises HTML
<img>et<iframe>ou utilisez la nouvelle propriété CSS aspect-ratio pour vous assurer qu’un espace approprié est réservé sur la page avant le téléchargement des ressources. - Définissez des dimensions appropriées pour les éléments conteneurs renfermant du contenu tiers à chargement lent, comme les publicités et les widgets.
- Veillez à ce que les images et autres éléments apparaissant en haut de la page soient demandés le plus tôt possible – un préchargement peut s’avérer utile.
- Réduisez au minimum l’utilisation des polices web et envisagez d’utiliser les polices courantes du système d’exploitation lorsque cela est possible.
- Chargez les polices web et définissez l’affichage des polices CSS comme facultatif ou permutable. Veillez à utiliser une police de secours de taille similaire pour minimiser le décalage de la mise en page.
- Évitez d’insérer des éléments vers le haut de la page, sauf s’ils répondent à une action de l’utilisateur, comme un clic.
- Assurez-vous que les interactions de l’utilisateur sont terminées dans les 500 millisecondes suivant le déclenchement de l’entrée.
- Utilisez la transformation et l’opacité CSS pour des animations plus efficaces qui n’entraînent pas de nouvelle mise en page.
- Tenez compte des CSS critiques en ligne. Incorporez les feuilles de style CSS essentielles dans un bloc
<link>en haut de la page, puis chargez les feuilles de style supplémentaires de manière asynchrone. - Si nécessaire, envisagez containment, une nouvelle fonctionnalité CSS qui vous permet d’identifier des sous-arbres isolés d’une page. Le navigateur peut optimiser le traitement en rendant – ou non – des blocs de contenu DOM spécifiques.
Résumé
Les développeurs n’ont pas toujours envie de danser au rythme de Google. L’entreprise dispose d’un pouvoir considérable, et des mises à jour mineures du moteur de recherche peuvent nuire à la productivité et à la rentabilité des organisations basées sur le web.
Cela dit, Core Web Vitals adopte une approche « carotte » plutôt que « bâton ». Les sites bien optimisés et utilisables, qui renoncent aux motifs sombres, ont de meilleures chances de succès que les sites gonflés, à forte intensité de popup, offrant une mauvaise interface utilisateur mobile.
Core Web Vitals fournit un moyen mesurable d’évaluer l’expérience utilisateur pour vous aider à vous concentrer sur les améliorations les plus importantes. Les changements apportés à vos signaux n’augmenteront peut-être pas vos revenus, mais vos utilisateurs seront plus heureux et plus fidèles.
Vous avez d’autres conseils pour améliorer Core Web Vitals ? Partagez-les dans la section des commentaires !
Laisser un commentaire