Home Blogs Lighthouse 6,0 Score Audit : une liste de contrôle pour préparer votre site Web
Applications

Lighthouse 6,0 Score Audit : une liste de contrôle pour préparer votre site Web

About The Author

Outline

Google Lighthouse est devenu l’outil de facto permettant à de nombreux sites Web de mesurer leurs performances avec un seul score : le Lighthouse Performance Score. Une nouvelle version, Lighthouse 6,0, est désormais disponible sur npm dans Chrome Canary, PageSpeed Insights et GSC Console. À la mi-juillet, Lighthouse 6,0 sera entièrement déployé pour les utilisateurs de Chrome dans Chrome 84. Il est maintenant temps de vous assurer que votre site est prêt pour la nouvelle version avec un audit de score Lighthouse 6,0.

Lighthouse 6,0 est livré avec de nouvelles métriques dépréciées, ainsi qu’une nouvelle formule de pondération pour calculer les scores de performance. Cette nouvelle version, ainsi que l’annonce de l’ ajout de Core Web Metrics à l’algorithme de classement de Google dans la mise à jour de l’expérience de la page Google, sont des signes clairs que le géant de la recherche met l’accent sur la vitesse perçue – la vitesse à laquelle un utilisateur perçoit une page comme chargée. Plus les utilisateurs perçoivent rapidement votre site à charger, plus votre rang est élevé et plus vous recevrez de conversions.

Les six métriques Lighthouse que vous devez optimiser

Google se soucie de la façon dont les utilisateurs vivent le Web. Deux sites Web peuvent terminer le chargement en même temps, mais l’un peut sembler se charger plus rapidement, en fonction de la façon dont le contenu est affiché sur la page. Alors que les deux sites ont fini de se charger simultanément, Google privilégiera ce dernier, le site avec une performance perçue plus rapidement.

Les scores Lighthouse 6,0 sont basés sur une moyenne pondérée de six métriques de vitesse centrées sur l’utilisateur. First Contentful Paint (FCP), Speed Index (si) et LCP (Largest Contentful Paint) mesurent la vitesse de chargement perçue et détiennent un poids combiné de 55 % dans le score Lighthouse d’un site Web dans la version 6. Un autre 40% du score est basé sur des métriques mesurant la réactivité, un autre aspect impactant la perception de la vitesse par un utilisateur. Il s’agit notamment du temps total de blocage (pas à pas) et du temps de mise en œuvre interactive (TTI). Les derniers 5 % du score sont basés sur une mesure qui mesure la stabilité visuelle, appelée décalage de mise en page cumulatif (CLS).

First Meaningful Paint (FMP) et First CPU Idle (FCI) du score Lighthouse 5,7 ont été remplacés par de meilleures mesures pour mesurer la vitesse d’un point de vue centré sur l’utilisateur. Il s’agit de la plus grande peinture Contentful (LCP) et du temps total de blocage (TBT) dans Lighthouse 6,0.

Phare 5,7 Poids Phare 6,0 Poids
Première peinture complète (FCP) 20% Première peinture complète (FCP) 15%
Indice de vitesse (si) 27% Indice de vitesse (si) 15%
Première peinture significative (PMF) 7% Peinture la plus complète (LCP) 25%
Premier CPU inactif (FCI) 13% Temps total de blocage (pas à pas) 25%
Délai d'interactivité (TTI) 33% Délai d'interactivité (TTI) 15%
- - Décalage cumulé de la mise en page (CLS) 5%

Voici les mesures à six vitesses sur lesquelles vous devez vous concentrer lorsque vous auditez votre site Web en préparation pour Lighthouse 6,0. Les mesures sont présentées dans l’ordre dans lequel elles sont mesurées au fur et à mesure que la page se charge.

Une liste de contrôle simplifiée couvrant les vitesses que vous devriez viser à fournir et les techniques d’optimisation par métrique sont disponibles au bas de cet article.

Première peinture Contentful

FCP marque le premier point où un utilisateur peut voir n’importe quel contenu de page à l’écran. Ce contenu comprend du texte, des images, des graphiques ou des fichiers SVG. FCP avait un poids de 20% dans Lighthouse 5,7, mais seulement 15% de poids sur votre score Lighthouse 6,0.

Dans la bande de film ci-dessus, le FCP pour le chargement de la première page est mesuré à 0,6 secondes. C’est lorsque le contenu apparaît pour la première fois sur la page d’accueil de TheTieBar.com, mais vous remarquerez que ce n’est pas lorsque tout le contenu est visible. C’est une distinction importante entre la première et la plus grande peinture contentful. Le LCP est mesuré à 0,9 secondes lorsque le contenu au-dessus du pli est affiché.

Au fur et à mesure que vous passez par votre audit de score Lighthouse 6,0, assurez-vous que vos pages ont une moyenne de FCP de 2 secondes ou moins, car il s’agit du seuil de la métrique pour le 75e percentile et est considéré comme rapide par Google. Les PCF entre 2 et 4 secondes sont considérées comme des vitesses modérées, et les PCF dépassant 4 secondes tombent en dessous du 50e percentile et sont classées comme lentes.

Si vous trouvez que le chargement des FCP est trop lent, cela peut être dû à un ou plusieurs des facteurs suivants :

  1. Trop de ressources de blocage du rendu
  2. Fichiers CSS volumineux
  3. Manque de connexions sécurisées aux sources tierces
  4. Temps de réponse du serveur longs
  5. Redirections de plusieurs pages
  6. Ressources statiques non mises en cache
  7. Taille DOM excessive

Pour optimiser votre FCP, tenez compte des points suivants :

  1. Mettre en ligne les ressources critiques, différer les ressources non critiques et supprimer tout ce qui n’est pas utilisé pour réduire l’impact des URL bloquant le rendu.
  2. Supprimez tous les caractères inutiles du CSS pour réduire la taille des fichiers.
  3. Utilisez la préconnexion pour établir des connexions précoces avec des origines tierces importantes.
  4. Réduisez les temps de réponse du serveur en optimisant la logique applicative du serveur ou en mettant à niveau le matériel de votre serveur pour avoir plus de mémoire.
  5. Évitez plus qu’une redirection de 1 pages.
  6. Utilisez la mise en cache HTTP pour mettre en cache les ressources statiques.
  7. Avoir moins de 1 500 nœuds au total, une profondeur de moins de 32 nœuds et un nœud parent avec moins de 60 nœuds enfants pour réduire la taille du DOM.

Indice de vitesse

Si mesure la progression visuelle d’un chargement de page et calcule un score global pour la rapidité avec laquelle le contenu est peint. Dans Lighthouse 5,7, si avait un poids de 27 % sur le score de performance d’un site Web. Dans Lighthouse 6,0, cette valeur est semi-diminuée, influençant 15 % du score de performance d’une page. Google considère toujours cela comme une mesure perceptive clé, car une page avec un affichage d’image lent peut être perçue comme bouchée.

Lighthouse mesure si en capturant une bande de film d’une page lorsqu’elle se charge dans le navigateur et en analysant la progression visuelle image par image. Le temps moyen auquel les parties visibles de la page sont affichées détermine le si. Cette mesure varie en fonction de la taille de l’écran de l’appareil.

Au fur et à mesure de votre audit de score Lighthouse 6,0, visez le SIS en 4.3s ou moins. Cette vitesse se classe dans le 75e percentile et est considérée comme rapide par Google. Les pages dont le SIS est compris entre 4,3 et 5,8 secondes sont modérées, et les SIS plus lents que 5,8 secondes tombent en dessous du 50e percentile et sont considérés comme lents.

Les périodes si plus lentes ont tendance à provenir des facteurs suivants :

  1. Les temps de chargement sur le fil principal dépassent 4 secondes
  2. Le temps d’exécution JavaScript dépasse 3,5 secondes
  3. Les fichiers de police volumineux provoquent un flash de texte invisible (foi).

Pour réduire les temps si, tenez compte des points suivants :

  1. Implémentez le fractionnement de code, supprimez le code inutilisé et compressez le code pour réduire la charge sur le thread principal et le temps d’exécution JavaScript.
  2. Assurez-vous que le texte reste visible pendant le chargement de Webfont afin d’éviter foi.

Peinture la plus complète

LCP est une nouvelle mesure ajoutée à Lighthouse 6,0 et reçoit 25 % de poids dans le score de performance d’un site. LCP remplace First Meaningful Paint (FMP) de Lighthouse 5,7. Bien que les deux métriques mesurent le temps d’affichage du plus grand élément de contenu, FMP est connu pour produire des résultats incohérents et ne peut être standardisé que dans certains navigateurs Web.

Le LCP mesure le moment où l’élément de contenu le plus grand est entièrement visible à l’écran. Les éléments de contenu mesurés comprennent les éléments de niveau bloc, les images (y compris les images dans les fichiers SVG) et les vidéos. Il s’agit d’une mesure extrêmement importante pour les sites Web de commerce électronique, car elle marque le moment où la plupart des utilisateurs perçoivent la page comme entièrement chargée et sont plus susceptibles de faire un achat.

Dans l’exemple ci-dessus, le LCP est de 0,9 secondes, lorsque l’image principale est entièrement peinte. Cette mesure capture un moment distinct où un utilisateur perçoit une page entièrement chargée, mais le contenu peut encore être chargé sous le pli.

Les sites Web les plus performants, comme ceux de Layer0 (maintenant Edgio), délivrent des LCP en moins de 1 seconde. Les LCP jusqu’à 2,5 secondes sont considérés comme rapides et se classent dans le 75e percentile pour cette mesure. Les LCP entre 2,5 secondes et 4 secondes sont considérés comme modérés, nécessitant une amélioration, et les LCP dépassant 4 secondes tombent en dessous du 50e percentile et sont considérés comme lents par Google.

Les LCP lents proviennent généralement d’un ou de plusieurs des éléments suivants :

  1. Temps de réponse du serveur lents
  2. JavaScript et CSS bloquant le rendu
  3. Temps de chargement des ressources longs
  4. Problèmes de rendu côté client

Si vous trouvez des LCP plus lents que les LCP souhaités lors de votre audit de score Lighthouse 6,0, tenez compte des points suivants :

  1. Optimisez les temps de réponse des serveurs en acheminant le trafic vers le CDN le plus proche disponible, en mettant en cache les ressources, en servant les pages HTML en premier et en établissant des connexions tierces en amont.
  2. Réduisez les CSS en supprimant les CSS inutiles, différez les CSS non critiques et les CSS critiques en ligne. Réduisez le temps de blocage JavaScript en compressant les fichiers JavaScript.
  3. Pour réduire les temps de chargement des ressources, optimisez et compressez les fichiers image et texte, et préchargez les ressources importantes.
  4. Optimisez le rendu côté client en utilisant le rendu côté serveur et le pré-rendu.

    Horaire 1-on-1 Demo Planifiez une conversation consultative maintenant pour apprendre comment Layer0 (maintenant Edgio) peut vous aider à atteindre des chargements de pages inférieurs à la seconde. Cliquez ici !

Temps total de blocage

Le TBT remplace le FCI de Lighthouse 5,7, qui détenait auparavant 13 % du poids. Dans Lighthouse 6,0, le Service pas à pas mesure la réactivité des pages et représente 25 % d’un score de performance. Le Service pas à pas mesure la gravité du caractère non interactif d’une page avant qu’elle ne devienne interactive de manière fiable.

Vous connaissez ces exemples douloureux : vous attendez qu’une page se charge, et enfin, elle semble prête. Vous appuyez sur le produit que vous voulez voir, mais rien ne se passe. Appuyez-vous à nouveau ? Cette période d’attente est connue pour causer littéralement du stress chez les consommateurs. Essentiellement, le TBT est la durée pendant laquelle un consommateur ressent ce stress dû à la non-interactivité d’une page.

Source : web.dev

Cette métrique est mesurée en calculant la somme totale du temps « bloqué » (tâches qui prennent plus de 50 ms) entre le premier élément de contenu affiché (FCP) et le moment où un utilisateur peut interagir pleinement avec la page (TTI). Par exemple, dans l’image ci-dessus, cinq tâches ont lieu dans le thread principal, mais seulement trois d’entre elles dépassent 50 ms. La première par 200 ms, la seconde par 40 ms et la troisième par 105 ms. Le TBT est de (200+40+105) 345 ms.

Une tâche prenant plus de 50 ms sera assez longue pour qu’un utilisateur remarque et perçoive la page comme lente, ou pire, inactive, et les amène à quitter. Pour éviter cela, visez à ce qu’un TBT inférieur à 300 ms soit considéré comme rapide. Les TBT entre 300 ms et 600 ms sont considérés comme des vitesses modérées et doivent être améliorés. Les TBT plus lents que 600 ms tombent en dessous du 50e percentile et sont considérés comme lents.

Les tâches longues sont généralement causées par un ou plusieurs des éléments suivants :

  1. Code tiers qui bloque le thread principal pendant 250 ms ou plus
  2. Le temps d’exécution de JavaScript prend plus de 3,5 secondes
  3. Le thread principal est occupé pendant plus de 4 secondes pendant le chargement
  4. Un volume élevé de requêtes réseau et des transferts de grande taille

Pour améliorer cette mesure, tenez compte des points suivants :

  1. Chargez efficacement JavaScript tiers à l’aide des attributs async ou defer sur les balises de script, établissez des connexions précoces vers des origines tierces importantes et utilisez le chargement différé.
  2. Pour accélérer l’exécution de JavaScript et réduire la charge sur le thread principal, implémentez la division de code, supprimez le code inutilisé et compressez le code.
  3. Optimisez CSS et JavaScript pour réduire le nombre de ressources et la taille des transferts.

Temps de l’interactivité

TTI est la troisième mesure reportée de Lighthouse 5,7, mais Google a réduit son poids de 33% à 15% dans Lighthouse 6,0. TTI est une mesure complémentaire à TBT, mesurant le temps nécessaire à une page pour devenir fiable ou entièrement interactive. Lighthouse considère qu’une page est interactive de manière fiable lorsque le premier élément de contenu est affiché, que ses scripts initiaux (le cas échéant) ont été chargés et qu’elle peut répondre à l’entrée de l’utilisateur dans un délai de 50 ms.

Pour un utilisateur, les TTI lents peuvent avoir l’impression qu’une page est inactive ou cassée. Bien qu’une page ait l’air interactive, ce n’est pas parce que le fil principal est bloqué (mesuré par TBT). Lorsque vous auditez votre site Web pour Lighthouse 6,0, visez les TTI en 5,2 secondes ou moins pour être considéré comme rapide. Les TTI compris entre 5,2 et 7,3 secondes sont considérés comme des vitesses modérées, et les TTI inférieurs à 7,3 secondes sont considérés comme lents et auront un impact sur la volonté des consommateurs de rester sur place.

Si votre audit de score Lighthouse 6,0 montre des vitesses TTI médiocres, cela peut être dû à un ou plusieurs des facteurs suivants :

  1. Grandes tailles de charge utile et temps d’analyse de script long
  2. Temps de chargement des ressources longs
  3. Le code tiers bloque le thread principal pendant 250 ms ou plus
  4. Chaînes de requêtes critiques
  5. Vitesse lente du thread principal et temps d’exécution JavaScript
  6. Nombre de ressources élevé ou grandes tailles de transfert

Réduire le temps TTI peut être fait en optimisant votre JavaScript. Cela comprend :

  1. Réduisez et compressez les fichiers JavaScript pour réduire la taille des données utiles et le temps d’analyse des scripts.
  2. Demandes de préchargement et/ou ajout de préconnexion pour des temps de chargement plus rapides.
  3. Chargez efficacement JavaScript tiers en utilisant les attributs async ou defer sur les balises de script et en utilisant le lazy-loading.
  4. Réduisez l’effet des chaînes de requêtes critiques sur les performances en réduisant le nombre de ressources critiques et en optimisant l’ordre dans lequel les ressources restantes sont chargées.
  5. Implémentez le fractionnement de code, supprimez le code inutilisé et compressez le code pour réduire la charge sur le thread principal et le temps d’exécution JavaScript.
  6. Optimisez CSS et JavaScript pour réduire le nombre de ressources et la taille des transferts.

Décalage de mise en page cumulé

CLS est la troisième nouvelle métrique introduite dans Lighthouse 6,0, et elle est la seule à ne pas remplacer une métrique de Lighthouse 5,7. CLS représente les derniers 5 % de votre score Lighthouse 6,0 et mesure la stabilité visuelle.

Cette mesure mesure la fréquence à laquelle les utilisateurs subissent des changements de mise en page inattendus. Vous avez déjà connu cela : vous êtes sur le point de toucher un produit, et bam, soudainement, vous touchez quelque chose d’autre sur la page parce que les éléments ont changé. Ces expériences peuvent être assez ennuyeuses et considérées comme janky pour un utilisateur.

CLS est mesuré par la somme totale de tous les scores de décalage de mise en page individuels pour chaque décalage de mise en page imprévu qui se produit pendant toute la durée de vie de la page. Un bon CLS est inférieur à 0,1 et se classe dans le 75e percentile pour la performance. Un CLS entre 0,1 et 0,25 est considéré comme modéré, et toute mesure supérieure à 0,25 tombe en dessous du 50e percentile et est considéré comme lent par Google.

Si vous trouvez un CLS médiocre lors de votre audit de score Lighthouse 6,0, cela est probablement dû à l’une des causes suivantes :

  1. Une image ou une vidéo qui se redimensionne elle-même
  2. Police qui se charge tardivement et qui s’affiche plus ou moins grande que prévu

Pour améliorer cette mesure, tenez compte des points suivants :

  1. Incluez des dimensions exactes sur vos images et éléments vidéo
  2. Évitez les publicités popup ou les bannières
  3. Évitez que la police ne provoque le fout/fout

Les scores Lighthouse vous montrent ce que Google pense de votre site

Le score de performance Lighthouse d’une page indique comment Google perçoit la page en termes de vitesse. Chaque métrique de Lighthouse 6,0 reflète la meilleure tentative de Google de mesurer la façon dont les utilisateurs perçoivent la vitesse. Si un score tombe en dessous des normes, il sera perçu comme lent, non seulement par les utilisateurs, mais aussi par le géant de la recherche lui-même, ce qui aura un impact négatif sur les revenus et le référencement.

Google classe les sites plus rapidement et plus haut sur la page de résultats du moteur de recherche. Au-delà du SEO, il a été constaté que la vitesse du site a un impact significatif sur les conversions et les revenus. Amazon, par exemple, a constaté qu’un décalage de 1 secondes dans le chargement de la page pourrait coûter à l’entreprise une perte de 1,6 milliard de dollars par an.

Résultat

Cette dernière version de Lighthouse démontre l’accent mis par le géant de la recherche sur les métriques de vitesse perceptuelles. Les métriques de notation dans Lighthouse 6,0 tentent de mesurer la rapidité avec laquelle les visiteurs perçoivent votre page comme étant entièrement chargée (même si elle exécute toujours des processus en arrière-plan).

Trois mesures, First Contentful Paint, Speed Index et Largest Contentful Paint, mesurent la vitesse de chargement perçue et représentent 55 % de votre score de performance. Visez des FCP de 2 secondes, des LCP de 2,5 et des SIS de 4,3 secondes ou moins.

Un autre 40 % d’un score de performance est basé sur des métriques perceptuelles mesurant la réactivité d’une page. Il s’agit notamment du temps total de blocage et du temps de mise en œuvre interactive. Un audit de score Lighthouse 6,0 rapide montrera un TBT en moins de 300 ms et un TTI en moins de 5,2 secondes, ou un utilisateur percevra votre site comme janky.

Enfin, personne n’aime que du texte ou des images sautent et sortent de l’écran. Le décalage cumulatif de la mise en page est la sixième mesure à prendre en compte dans votre audit Lighthouse 6,0. Visez des mesures CLS inférieures à 0,1, et vous recevrez les 5% du poids qu’il détient dans votre score de performance.

Pour recevoir une liste de contrôle simple couvrant les vitesses que vous devriez viser dans votre audit Lighthouse 6,0 Score, ainsi que les techniques d’optimisation par mesure, veuillez remplir le formulaire ci-dessous.