qwanturank

La dernière phase du déploiement ayant lieu en août 2021, la mise à jour Core Web Vitals est déjà là. Cela signifie que nous pouvons maintenant passer des évaluations préliminaires et identifier certains modèles communs. Notre vaste étude Core Web Vitals couvre les domaines suivants  :

  • En prenant des données historiques, nous avons examiné dans quelle mesure les sites Web mobiles et de bureau étaient prêts à être mis à jour et quelles métriques Core Web Vitals (la plus grande peinture de contenu, le temps de blocage total* et le décalage de mise en page cumulatif) obtenaient les meilleures valeurs
  • Nous avons également réussi à mettre en évidence les facteurs les plus cruciaux qui affectent les performances des pages en ce qui concerne les trois métriques
  • À l’aide des informations de notre outil d’audit de site, nous avons examiné les valeurs moyennes de LCP, TBT et CLS et identifié les problèmes les plus fréquents pour chaque métrique
  • Armé de ces informations, vous pouvez être mieux équipé pour optimiser vos pages pour une conformité CWV maximale et ainsi garantir une convivialité ultime et des classements plus élevés. Métrique Input Delay (FID), car cette dernière implique d’avoir accès aux données d’utilisateurs réels. Google lui-même a déclaré que ces deux mesures sont corrélées et peuvent toutes deux être utilisées pour évaluer les problèmes d’interactivité.

    Méthodologie de l’étude

    Notre étude est séparée en quelques parties :

  • L’évaluation des changements pour la conformité CWV avant et après la mise à jour.
  • Un regard sur les facteurs qui influencent si un site dépasse les seuils pour chaque métrique
  • Un audit CWV complet des sites Web analysés pour explorer les problèmes les plus et les moins fréquents pour chaque métrique
  • La première partie de l’étude est basée sur l’analyse de 1,7 million d’URL de bureau et 324 000 d’URL mobiles. Nous avons empilé les valeurs de pré-mise à jour de juin 2021 pour les métriques LCP, TBT et CLS par rapport aux statistiques de septembre 2021, lorsque la mise à jour était terminée. Pour faire la comparaison, nous avons vérifié combien de pages se trouvaient dans les trois plages de catégories  :  » médiocre « ,  » à améliorer  » – pour chaque métrique avant et après la mise à jour. Bon Besoin d’amélioration Mauvais LCP ≤ 2,5 s ≤ 4 s > 4 s TBT < 300ms ≥ 300ms ≤ 600ms > 600ms  CLS ≤ 0,1 ≤ 0,25 > 0,25 Nous mentionnons également les scores  » Tout TBT  » et  » Tout CLS « . Celles-ci reflètent simplement les métriques moyennes pour toutes les URL sans tenir compte de leurs performances TBT ou CLS. Pour identifier les facteurs qui affectent chaque métrique et pour voir quelles erreurs surviennent plus souvent que d’autres, nous avons pris l’audit de septembre 2021 de Site Audit de 4 millions d’URL de bureau et 1,7 million d’URL mobiles. Dans l’ensemble, l’outil a passé ces pages à travers 23 contrôles différents spécifiques au CWV.** ce qui nous a permis de révéler les audits les plus difficiles et les plus faciles à réussir. L’ensemble de l’étude est basé sur des données de laboratoire. ** Remarque  : vous pouvez trouver un liste de toutes les vérifications, leurs définitions et une ventilation complète de l’audit sur ordinateur portable à la toute fin de l’article. Core Web Vitals Can Be Easywith Semrush Site Audit

    Résultats de l’étude Core Web Vitals pour les appareils mobiles et les ordinateurs de bureau

    Combien d’URL ont augmenté leurs scores LCP, TBT et CLS

    Les graphiques ci-dessous montrent combien de pages (mobiles et ordinateurs) ont réellement dépassé les bons seuils pour les trois métriques CWV (combinées et individuelles) en juin 2021 par rapport à septembre 2021. Avant la mise à jour, seules 34,5 % des pages d’ordinateurs pouvaient répondre aux exigences requises. seuils pour les trois métriques. Après la mise à jour, le nombre d’URL de bureau qui viennent avec tous les  » bons  » scores pour LCP, TBT et CLS a augmenté de 7 points de pourcentage. Les URL mobiles montrent une image plus sombre, avec moins de 4 % des pages mobiles passant le  » bon  » seuils pour les trois métriques. En juin 2021, ce nombre était presque trois fois plus élevé, ce qui impliquait que les pages mobiles étaient moins prêtes à être mises à jour que leurs homologues de bureau.

    Évaluation des changements positifs pour les mesures CWV avant et après la mise à jour

    Les métriques CWV ont cependant plus de couches qu’un simple  » bon  » score. Les LCP, TBT et CLS peuvent être classés en trois catégories  :  » Bon « ,  » À améliorer  » et  » Mauvais « . Pour analyser les changements post-mise à jour à un niveau plus granulaire, nous avons vérifié toutes les améliorations qui se sont produites dans les trois métriques, en explorant combien d’URL ont fait des gains, en déplaçant leurs scores LCP, TBT et CLS d’une catégorie à l’autre.Quand il s’agit à des changements positifs pour les scores avant et après la mise à jour, nous observons les tendances suivantes  : URL mobiles   TOTAL (tout décalage amélioré entre les seuils) À améliorer -> Bon médiocre -> Bon médiocre -> Pour améliorer la part d’URL qui se sont améliorées (tous les 3 métriques) 0,1 % 0,01 % 0,07 % 0,02 % Part des URL qui se sont améliorées (TBT uniquement) 14 % 5 % 3 % 6 % Part des URL qui se sont améliorées (CLS uniquement) 19 % 8 % 7 % 4 % Part des URL qui se sont améliorées ( LCP uniquement) 7 % 1 % 1 % 5 % de part d’URL qui se sont améliorées (au moins 1 métrique) 38 % 14 % 10 % 14 % URL de bureau   TOTAL (tout écart qui s’améliore entre les seuils) À améliorer → Bon Mauvais → Bon Mauvais → À améliorer la part d’URL qui se sont améliorées (les 3 métriques) 0,09 % 0,05 % 0 0,03 % 0,01 % de part d’URL améliorées (TBT uniquement) 7 % 4 % 1 % 1 % de part d’URL améliorées (CLS uniquement) 21 % 9 % 7 % 5 % de part d’URL améliorées (LCP uniquement) 14 % 9 % 2 % 4 % Part des URL qui se sont améliorées (au moins 1 métrique) 39 % 21 % 10 % 9 %

  • Nous avons constaté un très faible nombre de pages (jusqu’à 0,1 %) qui ont amélioré tous les scores à tous les niveaux. Cependant, un tiers de toutes les pages ont vu des améliorations de score pour au moins une métrique. Cela est vrai pour les URL mobiles et de bureau
  • Sur mobile, le changement de catégorie le plus populaire pour les trois métriques est passé de la plage  » médiocre  » à la plage  » à améliorer « . Les URL de bureau affichent des tendances plus positives, car la majorité des scores LCP, TBT et CLS des URL sont passés de la catégorie  » à améliorer  » à  » bonne « .
  • Sur mobile, le passage de  » mauvais  » à  » bon  » semble presque mission impossible, à une seule exception près. CLS semble avoir le seuil le plus facile pour passer directement de  » mauvais  » à  » bon « , et davantage de pages ont apporté des améliorations significatives à leurs scores CLS
  • Nous avons collecté nos informations après que Google a abaissé le seuil CLS, la facilité apparente est donc probablement liée à ce changement.

  • Les pages mobiles sont confrontées aux changements les moins positifs en ce qui concerne le LCP, tandis que pour les URL de bureau, TBT semble poser les plus grands défis, affichant la tendance de changement positif la plus faible (6,7%)
  • Facteurs ayant un impact sur les scores LCP, TBT et CLS

    En analysant plus en détail les éléments de chaque métrique, nous avons réussi à identifier les facteurs qui affectent ces scores. Quelles sont les causes des scores LCP médiocres ? Le LCP mesure le temps de chargement du plus grand élément de page (image ou bloc de texte) dans la fenêtre de l’utilisateur, tout ce qui s’étend au-delà de l’écran ne compte pas. Par conséquent, nous avons examiné lesquels des éléments suivants sont présents/absents dans les pages analysées  :

  • qwanturank les balises sont des images, des images d’affiches vidéo, des images d’arrière-plan, etc
  • / les balises impliquent n’importe quel élément (conteneur) sur la page 
  • la balise est un paragraphe (texte) 
  • la balise pointe généralement vers une sorte d’élément de texte ; et
  • /

    /

    Les balises sont utilisées pour indiquer divers en-têtes et sous-en-têtes de page

  • Notre analyse a montré que qwanturank et Les balises sont les éléments les plus courants qui provoquent la lenteur du LCP. Si nous examinons de plus près, cependant, nous verrons plus de différences entre les éléments de balise de bureau mobile qui affectent les scores LCP.

  • qwanturank et Les balises sont principalement un problème pour les URL mobiles qui se trouvent dans une plage LCP  » médiocre « . Les pages mobiles dont le LCP se situe dans la plage  » bon  » et  » à améliorer  » sont principalement affectées par et qwanturank Mots clés
  • H1 commence à être un problème sur mobile, probablement parce que les h1 sont l’un des éléments les plus importants de la fenêtre d’affichage lorsque nous traitons avec des écrans plus petits.
  • Cela signifie qu’il existe une différence entre ce qui est considéré comme le plus grand élément sur mobile et sur ordinateur de bureau. Vous pouvez utiliser l’outil d’audit de site pour découvrir quel élément de page spécifique est considéré comme le plus grand élément de contenu dans la fenêtre dans votre cas particulier. Scores TBTComme TBT mesure la rapidité avec laquelle les utilisateurs peuvent commencer à interagir avec les éléments de la page, nous avons dû examiner les tâches longues. Les tâches longues faisant partie d’un code JavaScript qui fige l’interface utilisateur, pour obtenir un  » bon  » score TBT, vous devez maintenir votre TBT global inférieur à 300 ms. Bien que vous puissiez avoir autant de tâches longues que vous le souhaitez (tant qu’elles ne dépassent pas le seuil de 300 ms), il est toujours intéressant de voir que les pages mobiles et de bureau qui ont un  » bon  » score TBT viennent avec le nombre le plus bas. de tâches longues  : en moyenne, une page de bureau avec un score TBT  » mauvais  » comporte 6 fois plus de tâches longues que celles qui se situent dans la plage  » bonne « . Sur mobile, cette différence est plus modeste – elle est triple. Ce qui affecte les scores CLS La métrique CLS qui mesure la stabilité visuelle de la page dépend fortement des changements de mise en page qui apparaissent chaque fois qu’il y a un changement de position pour un élément visible d’un cadre rendu à l’autre.Comme avec TBT, les changements de mise en page concernent l’étendue plutôt que le nombre de ces changements. Et si nous n’avons pas vu de preuve directe de cela avec TBT, notre analyse CLS le rend évident  : nous ne voyons pas de grande différence dans le nombre de changements de mise en page entre les pages avec différents scores CLS, ce qui signifie que vous pouvez vous permettre d’avoir pas mal de quarts tant qu’ils atteignent les seuils.

    Les problèmes les plus courants de Web Vitals et comment les résoudre

    Bien que nous ayons identifié les principaux facteurs qui affectent les scores CWV des pages, cela ne signifie pas que ceux-ci peuvent être considérés comme les problèmes les plus urgents pour les propriétaires de sites. C’est là que le rapport Core Web Vitals de Site Audit entre en jeu et aide à identifier les vérifications les plus difficiles à passer. L’outil d’audit de site passe n’importe quelle page à travers 23 vérifications différentes où nous prenons la logique de Pagespeed Insights et considérons  :

  • Si la vérification dépasse la barre des 90, la page passe dans la zone verte, et nous considérons cet audit comme réussi ;
  • La marque 50-89 place la page dans la zone jaune ; et
  • Si la valeur est inférieure à 49, la page passe en zone rouge pour un contrôle donné
  • Les éléments essentiels du Web peuvent être faciles avec l’audit de site SemrushD’un point de vue d’ensemble, nous pouvons voir que les pages mobiles sont confrontées à un nombre beaucoup plus élevé de problèmes avec CWV. Les URL de bureau semblent faire un assez bon travail pour réussir les contrôles CWV, avec la majorité (68%) des contrôles dans la zone verte. Contrairement au bureau, où les pages ont passé la majorité des contrôles, sur mobile, seulement 34% des contrôles sont verts. Un inquiétant 65% de tous les audits sont jaunes ou rouges, ce qui signifie que les pages mobiles ne répondent pas aux exigences CWV pour ces contrôles. Examinons de manière plus nuancée tous les contrôles et voyons les trois premiers les plus faciles et les plus difficiles à passer. les pages mobiles et de bureau. Les sommets se ressemblent presque, qu’il s’agisse d’URL de bureau ou mobiles  :

  • Les éléments d’image qui n’ont pas de largeur et de hauteur explicites semblent être le plus gros problème pour les pages mobiles et de bureau.
  • Les modules en double dans les bundles JavaScript, les redirections de plusieurs pages et l’utilisation de formats vidéo pour un contenu animé efficace sont généralement transmis avec peu ou pas de problèmes
  • Pourtant, lorsqu’il s’agit d’éliminer les ressources bloquant le rendu, la différence est frappante  : sur le bureau, 76 % des pages réussissent ce contrôle, tandis que sur le mobile, seulement 57 % réussissent
  • L’audit de site ne détecte pas seulement les problèmes dans toutes les métriques, mais il les sépare également en problèmes liés aux LCP, CLS et TBT. Assurez-vous de passer en revue la répartition métrique par métrique des problèmes les plus courants pour vos pages particulières, car l’audit du site façonne réellement le problème d’une manière qui inclut la solution.

    Résumé

    Avec la mise à jour Core Web Vitals déjà disponible, vous n’avez pas d’autre choix que d’améliorer votre score pour les trois mesures (CLS, LCP et TBT) pour montrer à Google que vos pages offrent une convivialité ultime et méritent ces classements. Nous espérons que notre étude, qui a couvert beaucoup de terrain et a révélé des informations clés, fournit des conseils clairs pour soutenir davantage vos efforts d’optimisation. Bien que nous vous suggérions de jeter un autre regard sur toutes les découvertes, il y a quelques choses que vous devriez retenir de cette étude :

  • Le Web n’est pas encore entièrement prêt pour le CWV.
  • Seuls un tiers des URL de bureau et 3 % des URL mobiles dépassent les seuils pour les trois métriques CWV. Depuis la mise à jour, nous n’avons constaté des améliorations générales que pour environ 1% des pages. Et seulement moins de 40 % ont obtenu de meilleurs scores pour au moins une métrique. Cela signifie qu’il y a de fortes chances que vous disposiez de beaucoup d’espace pour vous améliorer et, si vous faites correctement et tôt, vos efforts d’optimisation de page peuvent donner à vos pages un avantage concurrentiel.

  • Portez une attention particulière à vos pages mobiles.
  • La majorité des contrôles pour les ordinateurs de bureau sont verts (aka réussis), tandis que pour les mobiles, nous voyons principalement des jaunes et des rouges. Cela signifie qu’il est plus facile de réussir les audits sur ordinateur de bureau que sur mobile, les pages mobiles étant en moyenne confrontées à plus de problèmes que les ordinateurs de bureau. Cela est probablement dû aux seuils mobiles et au fait que les données de laboratoire sont simulées sur un appareil 3G.

  • Travaillez sur vos scores LCP (pour mobile) et TBT (pour ordinateur).
  • Avec CLS comme métrique la moins  » problématique « , vous devez travailler sur l’amélioration de vos scores LCP et TBT  :

  • Les améliorations CLS sont plus susceptibles de vous faire passer rapidement de la plage de scores  » mauvais  » à  » bonne « 
  • Donnez un audit à votre qwanturank. , et

    balises pour vous assurer qu’elles ne diminuent pas votre score LCP. Utilisez l’outil d’audit de site pour identifier les éléments de page qui causent la lenteur

  • Gardez votre temps de blocage total à 300 ms pour assurer un  » bon  » score TBT. Encore une fois, l’outil d’audit de site vous aidera à identifier les tâches longues qui entravent le plus votre score TBT global
  • Faites attention à l’étendue de vos changements de mise en page et débarrassez-vous de ceux qui occupent trop d’espace de seuil CLS. L’audit du site reflète la contribution CLS de chaque changement de mise en page le plus important
  • Méfiez-vous des images non dimensionnées et des autres problèmes CWV courants.
  • Revoyez les audits les plus difficiles à réussir. La majorité des problèmes, à la fois pour les URL mobiles et de bureau, se produisent avec des images non dimensionnées. Comme il s’agit d’un contrôle lié au CLS qui a une solution assez rapide, vous pouvez l’utiliser comme une victoire rapide pour améliorer votre score CLS.

  • Gardez des attentes raisonnables.
  • Pour les ordinateurs de bureau, le changement le plus courant consiste à passer de la gamme  » à améliorer  » à une  » bonne « . Mais la majorité des URL mobiles passent de la catégorie  » pauvres  » à  » à améliorer « , à la seule exception étant CLS. Ne vous attendez donc pas à passer rapidement de tous les scores  » mauvais  » à tous les  » bons  » pour chaque métrique CWV, et faites attention à tout changement dans les seuils.

    Bonus  : une liste complète des problèmes CWV les plus courants pour les URL mobiles et de bureau

    Si vous êtes curieux d’explorer la liste complète de toutes les vérifications d’audit de site et de voir les scores moyens des pages de bureau mobile, survolez le tableau ci-dessous et obtenez une image complète.

    Notes d’audit moyennes

    Audit Score moyen (ordinateur de bureau) Score moyen (mobile) Supprimer les modules en double dans les bundles JavaScript 100 % 100 % Éviter les redirections de pages multiples 100 % 100 % Utiliser les formats vidéo pour le contenu animé 100 % 99 % Réduire CSS 100 % 98 % Éviter de servir du JavaScript hérité à navigateurs modernes 99 % 97 % Réduction de l’impact du code tiers 99 % 72 % Réduction du temps d’exécution de JavaScript 99 % 88 % Minimisation de JavaScript 99 % 96 % Minimisation du travail du thread principal 99 % 74 % Préconnexion aux origines requises 94 % 86 % Activation du texte compression 93 % 88 % Supprimer les CSS inutilisés 92 % 72 % Éviter les charges utiles réseau énormes 92 % 92 % Éviter une taille de DOM excessive 91 % 91 % Supprimer le JavaScript inutilisé 85 % 55 % Réduire les temps de réponse du serveur (TTFB) 82 % 82 % Éliminer le rendu blocage des ressources 76 % 57 % S’assurer que le texte reste visible pendant le chargement de la police Web 33 % 36 % Les éléments de l’image n’ont pas de largeur et de hauteur explicites 24 % 29 % Pour vous Pour plus de commodité, nous ajoutons les notes de Google sur chaque contrôle d’audit  :

  • Réduisez le temps d’exécution de JavaScript  : lorsque votre JavaScript prend beaucoup de temps à s’exécuter, il ralentit les performances de votre page de plusieurs manières, telles que le coût du réseau, le coût d’analyse et de compilation, le coût d’exécution ou le coût de la mémoire 
  • Évitez une taille DOM excessive  : une grande arborescence DOM peut ralentir les performances de votre page de plusieurs manières, telles que l’efficacité du réseau et les performances de charge, les performances d’exécution et les performances de mémoire 
  • Supprimez les modules en double dans les bundles JavaScript : les bundles JavaScript sur la majorité des pages Web sont généralement créés en important du code à partir de bibliothèques, dépendances et packages populaires. Cela peut souvent faire en sorte que votre page hérite de modules en double à partir de plusieurs sources 
  • : les grands GIF sont inefficaces pour diffuser du contenu animé, il est donc préférable d’utiliser des formats vidéo
  • Assurez-vous que le texte reste visible pendant le chargement des polices Web  : les polices sont souvent des fichiers volumineux qui prennent un certain temps à charger. Certains navigateurs masquent le texte jusqu’au chargement de la police, provoquant un flash de texte invisible
  • Éviter de fournir du code JavaScript hérité aux navigateurs modernes  : évitez de fournir du code JavaScript hérité (c’est-à-dire la norme ES5) aux navigateurs modernes afin d’empêcher le téléchargement de fichiers JavaScript inutilement volumineux par les utilisateurs 
  • Minimiser le travail du thread principal  : le processus de rendu du navigateur est ce qui transforme votre code en une page Web avec laquelle vos utilisateurs peuvent interagir. Par défaut, le thread principal du processus de rendu gère généralement la plupart du code  : il analyse le HTML et construit le DOM, analyse le CSS et applique les styles spécifiés, et analyse, évalue et exécute le JavaScript 
  • Évitez les redirections de plusieurs pages  : les redirections ralentissent la vitesse de chargement de votre page 
  • Éliminez les ressources bloquant le rendu  : la section Opportunités de votre rapport Lighthouse répertorie toutes les URL bloquant la première peinture de votre page. L’objectif est de réduire l’impact de ces URL bloquant le rendu en insérant les ressources critiques, en différant les ressources non critiques et en supprimant tout ce qui n’est pas utilisé 
  • Réduisez les temps de réponse du serveur : la section Opportunités de votre rapport Lighthouse indique le temps jusqu’au premier octet, le temps qu’il faut au navigateur d’un utilisateur pour recevoir le premier octet du contenu de la page
  • Ressources tierces à chargement paresseux avec façades  : les ressources tierces sont souvent utilisées pour afficher des publicités ou des vidéos et s’intégrer aux médias sociaux. L’approche par défaut consiste à charger des ressources tierces dès le chargement de la page, mais cela peut ralentir inutilement le chargement de la page. Si le contenu tiers n’est pas critique, ce coût de performance peut être réduit en le chargeant paresseux 
  • Réduisez l’impact du code tiers  : pour ajouter un réseau publicitaire, un bouton de réseau social, un test A/B ou un service d’analyse à votre page, vous devez généralement ajouter un script tiers à votre code HTML. Ces scripts tiers peuvent affecter considérablement les performances de chargement de votre page 
  • Évitez les charges utiles réseau énormes  : les charges utiles réseau volumineuses sont fortement corrélées avec des temps de chargement longs. Ils coûtent également de l’argent aux utilisateurs ; par exemple, les utilisateurs peuvent avoir à payer pour plus de données cellulaires. Ainsi, réduire la taille totale des requêtes réseau de votre page est bon pour l’expérience de vos utilisateurs sur votre site et leurs portefeuilles 
  • Minification CSS  : la section Opportunités de votre rapport Lighthouse répertorie tous les fichiers CSS non minifiés, ainsi que les économies potentielles en kibioctets (KiB) lorsque ces fichiers sont minifiés ;
  • Minifier JavaScript : la réduction des fichiers JavaScript peut réduire la taille de la charge utile et le temps d’analyse des scripts
  • Images non dimensionnées  : l’image a l’air bien, mais elle gaspille les données des utilisateurs et nuit aux performances de la page 
  • Supprimez les règles CSS inutilisées  : la section Opportunités de votre rapport Lighthouse répertorie toutes les feuilles de style avec des CSS inutilisés avec une économie potentielle de 2 Kio ou plus. Supprimez le CSS inutilisé pour réduire les octets inutiles consommés par l’activité du réseau 
  • Supprimer le JavaScript non utilisé  : le JavaScript non utilisé peut ralentir la vitesse de chargement de votre page 
  • la section Opportunités de votre rapport Lighthouse répertorie toutes les demandes clés qui ne donnent pas encore la priorité aux demandes de récupération avec
  • Activer la compression de texte  : les ressources basées sur du texte doivent être desservies avec une compression pour minimiser le nombre total d’octets du réseau
  • Core Web Vitals peut être facile avec l’audit de site Semrush

    Core Web Vitals Problèmes les plus courants et comment les surmonter

    S’abonner
    Notification pour
    guest
    0 Commentaires
    Commentaires en ligne
    Afficher tous les commentaires