Accueil Tags Advanced

Tag: Advanced

Advanced Core Web Vitals : un guide technique de référencement

0

Les vrais humains veulent de bonnes expériences Web. À quoi cela ressemble-t-il en pratique ?

Eh bien, une étude récente citée par Google dans un article de blog sur Core Web Vitals a révélé que les utilisateurs Web mobiles ne gardaient leur attention sur l’écran que pendant 4 à 8 secondes à la fois.

Relisez cela.

Tu as moins de 8 secondes pour fournir un contenu interactif et amener un utilisateur à accomplir une tâche.

Entrez Core Web Vitals (CWV). Ces trois mesures sont conçues pour mesurer les performances du site en termes d’expérience humaine. Le projet open source Chromium a annoncé les métriques début mai 2020 et elles ont été rapidement adoptées dans tous les produits Google.

Comment qualifions-nous les performances dans les mesures centrées sur l’utilisateur ?

  1. Est-ce que ça charge ?
  2. Puis-je interagir ?
  3. Est-ce visuellement stable ?

Fondamentalement, Core Web Vitals mesure le temps nécessaire pour exécuter les fonctions de script nécessaires pour peindre le contenu au-dessus de la ligne de flottaison. L’arène de ces tâches herculéennes est une fenêtre d’affichage 360 ​​x 640. Il tient dans votre poche !

Ce tambour de guerre pour la dette technologique non adressée est une bénédiction pour de nombreux propriétaires de produits et professionnels du référencement technologique qui ont été retardés en faveur de nouvelles fonctionnalités et de babioles brillantes.

La mise à jour Page Experience sera-t-elle Mobileggedon 4.0 ?

Probablement pas.

Mais lorsque votre page passe les évaluations CWV, les utilisateurs sont 24 % moins susceptibles d’abandonner les chargements de page. Ces efforts profitent à toutes les sources et à tous les supports, et surtout aux vrais humains.

La mise à jour de l’expérience de la page

Pour tout le buzz, CWV sera des éléments d’un signal de classement. Devant être déployé progressivement de la mi-juin à août 2021, le classement de l’expérience de la page comprendra :

  1. Web Vitals de base.
    • La plus grande peinture de contenu.
    • Premier délai d’entrée.
    • Stabilité visuelle.
  2. Adapté aux mobiles.
  3. Navigation sûre.
  4. HTTPS.
  5. Pas d’interstitiels intrusifs.

La documentation mise à jour précise que le déploiement sera progressif et que « les sites ne doivent généralement pas s’attendre à des changements drastiques ».

Choses importantes à savoir sur la mise à jour :

  • L’expérience de la page est évaluée par URL.
  • L’expérience de la page est basée sur un navigateur mobile.
  • AMP n’est plus requis pour les carrousels Top Stories.
  • Passer CWV n’est pas obligatoire pour apparaître dans les carrousels Top Stories.

Un nouveau rapport d’expérience de page dans la console de recherche

La Search Console inclut désormais un rapport sur l’expérience de la page. La nouvelle ressource comprend des données antidatées pour les 90 derniers jours.

La Search Console inclut désormais un rapport sur l'expérience de la page.  La nouvelle ressource comprend des données antidatées pour les 90 derniers jours.

Pour qu’une URL soit « bonne », elle doit répondre aux critères suivants :

  • L’URL a un statut Bon dans le rapport Core Web Vitals.
  • L’URL ne présente aucun problème d’utilisabilité mobile selon le rapport d’utilisabilité mobile.
  • Le site n’a aucun problème de sécurité.
  • L’URL est diffusée via HTTPS.
  • Le site ne présente aucun problème d’expérience publicitaire, ou le site n’a pas été évalué pour l’expérience publicitaire.

Le nouveau rapport propose des widgets de haut niveau liés aux rapports pour chacun des cinq critères « Bon ».

Le nouveau rapport propose des widgets de haut niveau liés aux rapports pour chacun des 5

Flux de travail pour le diagnostic et l’action des améliorations CWV

Tout d’abord, une mise en garde importante concernant les données Field vs Lab.

Les données de terrain sont des données de performances collectées à partir de chargements de pages réels que vos utilisateurs rencontrent dans la nature. Vous pouvez également entendre les données de terrain appelées Real User Monitoring.

Les évaluations Core Web Vitals et le signal de classement de l’expérience de page utiliseront les données de terrain recueillies par le rapport d’expérience utilisateur Chrome (Crux).

Quels utilisateurs font partie du rapport sur l’expérience utilisateur de Chrome ?

Les données Crux sont des utilisateurs agrégés qui répondent à trois critères :

  1. L’utilisateur a choisi de synchroniser son historique de navigation.
  2. L’utilisateur n’a pas configuré de phrase secrète de synchronisation.
  3. L’utilisateur a activé les rapports de statistiques d’utilisation.

Crux est votre source de vérité pour l’évaluation Core Web Vitals.

Vous pouvez accéder aux données Crux à l’aide de Google Search Console, de PageSpeed ​​Insights (au niveau de la page), du projet Public Google BigQuery ou en tant que tableau de bord au niveau de l’origine dans Google Data Studio.

Pourquoi utiliseriez-vous autre chose ? Eh bien, CWV Field Data est un ensemble restreint de métriques avec des capacités de débogage limitées et des exigences de disponibilité des données.

Pourquoi ma page n’a-t-elle pas de données disponibles à partir de Crux ?

Pourquoi ma page n'a-t-elle pas de données disponibles à partir de Crux ?

Lors du test de votre page, vous pouvez voir « Le rapport d’expérience utilisateur Chrome ne contient pas suffisamment de données de vitesse réelle pour cette page ».

En effet, les données Crux sont anonymisées. Il doit y avoir suffisamment de pages chargées à signaler sans possibilité raisonnable que l’utilisateur individuel soit identifié.

Les Web Core Vitals sont mieux identifiés à l’aide de données de terrain, puis diagnostiqués/QAed à l’aide de données de laboratoire.

Lab Data vous permet de déboguer les performances avec une visibilité de bout en bout et approfondie sur l’UX. C’est ce qu’on appelle un « laboratoire » car ces données émulées sont collectées dans un environnement contrôlé avec des paramètres de périphérique et de réseau prédéfinis.

Vous pouvez obtenir des données de laboratoire à partir de PageSpeed ​​Insights, de web.dev/measure, du panneau Lighthouse de Chrome DevTool et de robots d’exploration basés sur Chromium comme un phare NodeJS local ou DeepCrawl.

Plongeons-nous dans un processus de workflow.

1. Identifiez les problèmes liés aux données Crux regroupées par modèles de comportement dans la Search Console.

Commencez par le rapport Core Web Vitals de la Search Console pour identifier les groupes de pages qui nécessitent votre attention. Cet ensemble de données utilise les données Crux et vous fait la gentillesse de regrouper des exemples d’URL en fonction de modèles de comportement.

Si vous résolvez le problème racine pour une page, vous le résoudrez probablement pour toutes les pages partageant ce problème CWV. Généralement, ces problèmes sont partagés par un modèle, une instance CMS ou un élément sur la page. GSC effectue le regroupement pour vous.

Concentrez-vous sur les données mobiles, car Google passe à un index Mobile-First et CWV est sur le point d’affecter les SERP mobiles. Priorisez vos efforts en fonction du nombre d’URL impactées.

Regroupements de problèmes de la console de recherche Google Core Web Vitals.

Cliquez sur un problème pour voir des exemples d’URL qui présentent les mêmes modèles de comportement.

Enregistrez ces exemples d’URL pour les tester tout au long du processus d’amélioration.

Regroupements de problèmes de la console de recherche Google Core Web Vitals avec des exemples de pages

2. Utilisez PageSpeed ​​Insights pour associer les données de terrain aux diagnostics de laboratoire.

Une fois que vous avez identifié les pages qui ont besoin de travail, utilisez PageSpeed ​​Insights (alimenté par Lighthouse et Chrome UX Report) pour diagnostiquer les problèmes de laboratoire et de terrain sur une page.

N’oubliez pas que les tests de laboratoire sont des tests émulés uniques. Un test n’est pas une source de vérité ou une réponse définitive. Testez plusieurs exemples d’URL.

PageSpeed ​​Insights ne peut être utilisé que pour tester des URL accessibles au public et indexables.

Si vous travaillez sur des pages sans index ou authentifiées, les données Crux sont disponibles via l’API ou BigQuery. Les tests en laboratoire doivent utiliser Lighthouse.

3. Créez un ticket. Faites le travail de développement.

Je vous encourage en tant que professionnels du référencement à faire partie des processus d’amélioration des tickets et d’assurance qualité.

Les équipes de développement travaillent généralement en sprints. Chaque sprint comprend des tickets fixes. Avoir des tickets bien rédigés permet à votre équipe de développement de mieux dimensionner l’effort et d’intégrer le ticket dans un sprint.

Dans vos billets, incluez :

Histoire de l’utilisateur

Suivez un format simple :

En tant que , je veux afin de .

Par exemple : en tant que site performant, je souhaite inclure du CSS en ligne pour le nœud X sur le modèle de page Y afin d’obtenir le plus grand contenu de peinture pour ce modèle de page en moins de 2,5 secondes.

Critères d’acceptation

Définir quand l’objectif a été atteint. Que signifie « fait » ? Par exemple.:

  • Inline tout CSS de chemin critique utilisé pour le contenu au-dessus de la ligne de flottaison en l’incluant directement dans .
  • Le CSS critique (lu comme : celui lié au nœud X) apparaît au-dessus des liens de ressources JS et CSS dans le .

Tester les URL/Stratégie

Incluez les exemples d’URL groupés que vous avez copiés depuis la Search Console. Fournissez un ensemble d’étapes à suivre pour les ingénieurs QA.
Réfléchissez à l’outil utilisé, à la métrique/au marqueur à rechercher et au comportement indiquant une réussite ou un échec.

Liens vers le document du développeur

Utilisez la documentation de première partie lorsqu’elle est disponible. S’il vous plaît pas de blogs pelucheux. S’il vous plaît? Par exemple.:

  • CSS critique en ligne, Web.dev
  • Extraire le CSS critique, Web.dev

4. Modifications de l’assurance qualité dans les environnements de mise en scène utilisant Lighthouse.

Avant que le code ne soit mis en production, il est souvent placé dans un environnement intermédiaire pour les tests. Utilisez Lighthouse (via Chrome DevTools ou une instance de nœud local) pour mesurer les Core Web Vitals.

Si vous débutez dans les tests avec Lighthouse, vous pouvez en savoir plus sur les méthodes de test et la méthodologie de test dans A Technical SEO Guide to Lighthouse Performance Metrics.

Gardez à l’esprit que les environnements inférieurs ont généralement moins de ressources et seront moins performants que la production.

Appuyez-vous sur les critères d’acceptation pour déterminer si les travaux de développement achevés ont répondu à la tâche confiée.

La plus grande peinture de contenu

Représente: Expérience de chargement perçue.

La mesure: le point dans la chronologie de chargement de la page où la plus grande image ou le plus grand bloc de texte de la page est visible dans la fenêtre d’affichage.

Comportements clés: les pages utilisant les mêmes modèles de page partagent généralement le même nœud LCP.

Objectif: 75 % des chargements de pages atteignent le LCP en moins de 2,5 secondes.

Disponible en: Données de laboratoire et de terrain.

Que peut être LCP ?

La métrique LCP mesure le moment où le plus grand élément de texte ou d’image dans la fenêtre d’affichage est visible.

Les éléments possibles qui peuvent être le nœud LCP d’une page incluent :

  1. <img> éléments.
  2. <image> éléments à l’intérieur d’un <svg> étiquette.
  3. images d’affiches de <video> éléments.
  4. images d’arrière-plan chargées via url() Fonction CSS.
  5. Nœuds de texte à l’intérieur des éléments de niveau bloc.

Attendez-vous à voir des éléments supplémentaires comme <svg> et <video> ajoutées dans les futures itérations.

Comment identifier LCP à l’aide de Chrome DevTools

  1. Ouvrez la page dans Chrome émulant un Moto 4G.
  2. Accédez au panneau Performances des outils de développement (Command + Option + I sur Mac ou Control + Shift + I sous Windows et Linux).
  3. Survolez le LCP marqueur dans la section Timings.
  4. Le ou les éléments correspondant à LCP sont détaillés dans le champ Nœud associé.

Comment identifier LCP à l'aide de Chrome DevTools

Qu’est-ce qui cause une mauvaise LCP ?

Il existe quatre problèmes courants à l’origine d’un LCP médiocre :

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

Les problèmes de source pour LCP sont au mieux peints à grands traits. Malheureusement, aucune des phrases ci-dessus ne suffira probablement à transmettre à votre équipe de développement avec des résultats significatifs.

Cependant, vous pouvez donner de l’élan au problème en vous concentrant sur laquelle des quatre origines est en jeu.

L’amélioration du LCP sera collaborative. Le réparer signifie s’asseoir sur les mises à jour des développeurs et suivre en tant que partie prenante.

Diagnostic d’un LCP médiocre en raison d’un temps de réponse lent du serveur

Où regarder: Tableau de bord Crux v2 – Délai avant le premier octet (TTFB) (page 6)

Diagnostic d'un LCP médiocre en raison d'un temps de réponse lent du serveur

SI vous voyez constamment un TTFB médiocre dans vos données de terrain, alors c’est le temps de réponse lent du serveur qui fait glisser LCP.

Comment réparer le temps de réponse lent du serveur

Le temps de réponse du serveur est composé de nombreux facteurs adaptés à la pile technologique du site. Il n’y a pas de solution miracle ici. Votre meilleur plan d’action est d’ouvrir un ticket avec votre équipe de développement.

Voici quelques façons possibles d’améliorer le TTFB :

  1. Optimisez le serveur.
  2. Acheminez les utilisateurs vers un CDN à proximité.
  3. Actifs du cache.
  4. Servez le cache des pages HTML en premier.
  5. Établissez rapidement des connexions avec des tiers.

Diagnostiquer un LCP médiocre en raison de JavaScript et CSS bloquant le rendu

Où regarder: Lighthouse (via web.dev/measure, Chrome DevTools, Pagespeed Insights ou instance nodeJS). Chacune des solutions ci-dessous inclut un indicateur d’audit pertinent.

Comment réparer le CSS bloquant le rendu

Le CSS est intrinsèquement bloquant le rendu et a un impact sur les performances critiques du chemin de rendu. Par défaut, CSS est traité comme une ressource bloquant le rendu.

Le navigateur télécharge toutes les ressources CSS, quel que soit le comportement bloquant ou non bloquant.

Minifier le CSS.

Si votre site utilise un module bundler ou un outil de build, trouvez le plugin qui minimisera systématiquement les scripts.

Différer les CSS non critiques.

Le rapport sur la couverture du code dans DevTools vous aidera à identifier les styles utilisés sur la page. S’il n’est utilisé sur aucune page, supprimez-le entièrement. (Pas de jugement, les fichiers CSS peuvent rapidement gonfler dans le proverbial tiroir à courrier indésirable.)
Si les styles sont utilisés sur une autre page, créez une feuille de style distincte pour les pages qui l’utilisent pour appeler.

CSS critique en ligne.

Inclure le chemin critique CSS utilisé pour le contenu au-dessus de la ligne de flottaison (tel qu’identifié par le rapport sur la couverture du code) directement dans <head>.

Utilisez les requêtes multimédia dynamiques.

Les requêtes multimédias sont de simples filtres qui, lorsqu’ils sont appliqués aux styles CSS, répartissent les styles en fonction des types d’appareils affichant le contenu.

L’utilisation de requêtes média dynamiques signifie qu’au lieu de calculer des styles pour tout viewports, vous appelez et calculez ces valeurs dans le viewport demandeur.

Comment réparer JavaScript bloquant le rendu

Minifiez et compressez les fichiers JavaScript.

Vous devrez travailler avec les développeurs pour réduire et compresser les charges utiles du réseau.

La minification consiste à supprimer les espaces et le code inutiles. Il est préférable de le faire systématiquement avec un outil de compression JavaScript.

La compression implique la modification algorithmique du format de données pour des interactions serveur et client performantes.

Différer le JavaScript inutilisé.
La division du code découpe de gros morceaux de JS pour fournir des packages plus petits. Vous pouvez ensuite charger ceux qui comptent pour le contenu au-dessus du pli en premier.

Minimisez les polyfills inutilisés.

Rappelez-vous comment Googlebot a été bloqué dans Chrome 44 pendant ce qui semblait être des siècles ? Un polyfills est un morceau de code utilisé pour fournir des fonctionnalités modernes sur les anciens navigateurs qui ne le prennent pas en charge de manière native.

Maintenant que Googlebot est à feuilles persistantes, il porte également le nom dette technologique.

Certains compilateurs ont des fonctionnalités intégrées pour supprimer les polyfills hérités.

Comment réparer les scripts tiers bloquant le rendu

Retardez-le.

Si le script ne contribue pas au contenu au-dessus du pli, utilisez async ou defer les attributs.

Retirez-le.

Si le script utilise un <iframe> dans la tête, retirez-le. Contactez le fournisseur pour une méthode d’implémentation mise à jour.

Consolidez-le.

Auditez l’utilisation de scripts tiers. Qui est en charge de l’outil ? Un outil tiers sans personne pour le gérer est également connu comme un passif.

Quelle valeur apporte-t-il ? Cette valeur est-elle supérieure à l’impact sur les performances ? Le résultat peut-il être atteint en consolidant les outils ?

Mettez-le à jour.

Une autre option peut être de contacter le fournisseur pour voir s’il dispose d’une version allégée ou asynchrone mise à jour. Parfois, ils le font et ne le disent pas aux gens qui ont leur ancienne implémentation.

Diagnostic d’un LCP médiocre en raison de la lenteur des temps de chargement des ressources

Où regarder: Lighthouse (via web.dev/measure, Chrome DevTools, Pagespeed Insights ou instance nodeJS). Chacune des solutions ci-dessous comprend un indicateur d’audit pertinent.

Les navigateurs récupèrent et exécutent les ressources au fur et à mesure qu’ils les découvrent. Parfois, nos chemins vers la découverte sont loin d’être idéaux. D’autres fois, les ressources ne sont pas optimisées pour leurs expériences sur la page.

Voici des moyens de lutter contre les causes les plus courantes de ralentissement des temps de chargement des ressources :

  1. Optimisez et compressez les images.

    Personne n’a besoin d’un fichier png de 10 Mo. Il existe rarement un cas d’utilisation pour l’envoi d’un fichier image volumineux. Ou un png.

  2. Précharger des ressources importantes.

    Si une ressource fait partie du chemin critique, un simple rel="preload" L’attribut indique au navigateur de le récupérer dès que possible.

  3. Compresser les fichiers texte.

    Encodez, compressez, répétez.

  4. Diffusez différents actifs en fonction de la connexion réseau (service adaptatif).
    Un appareil mobile sur un réseau 4G n’aura probablement pas besoin/vouloir/tolérer le temps de chargement des actifs prêts pour un moniteur ultra 4K. Utilisez l’API d’informations réseau qui permet aux applications Web d’accéder aux informations sur le réseau de l’utilisateur.
  5. Mettre en cache les actifs à l’aide d’un agent de service.
    Bien que Googlebot n’exécute pas de service workers, l’appareil d’un utilisateur sur une connexion réseau d’une valeur de dé à coudre le fera certainement. Travaillez avec votre équipe de développement pour tirer parti de l’API Cache Storage.

Diagnostiquer un LCP médiocre en raison du rendu côté client

Où regarder: Pour des coups d’œil ponctuels, affichez la source de la page. S’il s’agit de quelques lignes de charabia, la page est rendue côté client.

Les éléments d’une page peuvent être rendus côté client. Pour repérer les éléments, comparez la source de la page initiale avec le HTML rendu. Si vous utilisez un robot d’exploration, comparez la différence de nombre de mots rendus.

Les Core Web Vitals sont un moyen de mesurer l’efficacité de nos stratégies de rendu.

Toutes les options de rendu ont le même résultat (elles créent toutes des pages Web), mais les métriques CWV mesurent la rapidité avec laquelle nous livrons ce qui compte quand cela compte.

Le rendu côté client est rarement la réponse à moins que la question ne soit : « Quels changements sont entrés en production en même temps que le trafic organique a commencé à chuter ?

Comment réparer le rendu côté client

« Stop » n’est vraiment pas une réponse utile. Précis, mais pas utile. Donc au lieu:

  1. Minimisez le JavaScript critique.

    Utilisez le fractionnement du code, l’arborescence et les fonctions en ligne dans la tête pour les fonctionnalités au-dessus de la ligne de flottaison. Gardez ces scripts en ligne <1kb.

  2. Utilisez le rendu côté serveur.

    En faisant en sorte que vos serveurs exécutent des éléments JS, vous pouvez renvoyer du code HTML entièrement rendu. Notez que cela augmentera votre TTFB car les scripts sont exécutés avant que votre serveur ne réponde.

  3. Utilisez le pré-rendu.

    Au moment de la construction, exécutez vos scripts et préparez le HTML pour les demandes entrantes. Cette option offre un meilleur temps de réponse du serveur, mais ne fonctionnera pas pour les sites dont l’inventaire ou les prix changent fréquemment.

Pour être clair : le rendu dynamique n’est pas une solution au rendu côté client. Cela donne les problèmes de rendu côté client à un ami.

Premier délai d’entrée (FID)

Représente: Réactivité à l’entrée de l’utilisateur.

La mesure: le temps entre le moment où un utilisateur interagit pour la première fois avec une page et le moment où le navigateur est réellement capable de commencer à traiter les gestionnaires d’événements en réponse à cette interaction.

Comportements clés: FID n’est disponible que sous forme de données de terrain.

Objectif: 75 % des chargements de page atteignent le FID en <= 100 millisecondes.

Disponible en: Données de terrain.

Utiliser le temps de blocage total (TBT) pour les tests de laboratoire

Étant donné que le FID n’est disponible que sous forme de données de laboratoire, vous devrez utiliser le temps de blocage total pour les tests de laboratoire. Les deux obtiennent le même résultat final avec des seuils différents.

Le TBT représente: Réactivité à l’entrée de l’utilisateur.

Mesure du TBT: Temps total pendant lequel le thread principal est occupé par des tâches prenant plus de 50 ms à accomplir.

Objectif: <= 300 millisecondes.

Disponible en: Données de laboratoire.

Qu’est-ce qui cause un mauvais FID ?

const jsHeavy = true;
    While (jsHeavy) {
        console.log("FID fail")
    }

JavaScript lourd. C’est ça.

Un FID médiocre provient de JS occupant le thread principal, ce qui signifie que les interactions de votre utilisateur sont obligées d’attendre.

Quels éléments sur la page sont impactés par le FID ?

Le FID est un moyen de mesurer l’activité du thread principal. Avant que les éléments de la page puissent répondre à l’interaction de l’utilisateur, les tâches en cours sur le fil principal doivent être terminées.

Voici quelques-uns des éléments les plus répandus que votre utilisateur exploite avec frustration :

  1. Champs de texte.
  2. Cases à cocher.
  3. Boutons radio (<input> et <textarea>).
  4. Sélectionnez les listes déroulantes (<select>).
  5. Liens (<a>).

Où regarder: Pour confirmer qu’il s’agit d’un problème pour les utilisateurs, consultez Crux Dashboard v2 – First Input Delay (FID) (page 3). Utilisez Chrome DevTools pour identifier les tâches exactes.

Comment voir TBT à l’aide de Chrome DevTools

  1. Ouvrez la page dans Chrome.
  2. Accédez au panneau Réseau des outils de développement (Command + Option + I sur Mac ou Control + Shift + I sous Windows et Linux).
  3. Cochez la case pour désactiver le cache.
  4. Accédez au panneau de performances et cochez la case Web Vitals.
  5. Cliquez sur le bouton de rechargement pour démarrer une trace des performances.
  6. Recherchez les blocs bleus étiquetés Tâches longues ou les marqueurs rouges du coin droit dans le coin droit des tâches. Ceux-ci indiquent des tâches longues qui ont pris plus de 50 ms.
  7. Trouvez le TBT pour la page au bas du résumé.

Comment voir TBT à l'aide de Chrome Devtools

Comment réparer un mauvais FID

Arrêtez de charger autant de scripts tiers.

Le code tiers place vos performances derrière la pile d’une autre équipe.

Vous dépendez de l’exécution succincte et performante de leurs scripts pour que votre côté soit considéré comme performant.

Libérez le fil principal en décomposant les tâches longues.

Si vous expédiez un bundle JS massif pour chaque page, il y a beaucoup de fonctionnalités dans ce bundle qui ne contribuent pas à la page.

Même si elles ne contribuent pas, chaque fonction JS doit être téléchargée, analysée, compilée et exécutée.

En divisant ce gros paquet en plus petits morceaux et en n’expédiant que ceux qui contribuent, vous libérerez le fil principal.

Vérifiez votre gestionnaire de balises.

Le déploiement de balises prêt à l’emploi déclenche des écouteurs d’événements qui immobiliseront votre fil principal.

Les gestionnaires de balises peuvent être des gestionnaires d’entrée de longue durée qui bloquent le défilement. Travaillez avec les développeurs pour éviter les rebonds de vos gestionnaires d’entrée.

Optimisez votre page pour la préparation à l’interaction.

Expédiez et exécutez ces bundles JS dans un ordre qui compte.

Est-ce au-dessus du pli ? Il devient prioritaire. Utilisation rel=preload.

Assez important mais pas assez pour bloquer le rendu ? Ajouter le async attribut.

Sous le pli ? Retardez-le avec le defer attribut.

Utilisez un Web Worker.

Les Web Workers permettent à JavaScript de s’exécuter sur un thread d’arrière-plan plutôt que sur le thread principal sur lequel votre FID est noté.

Réduisez le temps d’exécution de JavaScript.

Si vous expédiez un bundle JS massif pour chaque page, il y a beaucoup de fonctionnalités dans ce bundle qui ne contribuent pas à la page.

Même si elles ne contribuent pas, chaque fonction JS doit être téléchargée, analysée, compilée et exécutée.

En divisant ce gros paquet en plus petits morceaux (division de code) et en n’expédiant que ceux qui y contribuent (secouage d’arbre), vous libérerez le fil principal.

Changement de mise en page cumulé

Représente: Stabilité visuelle.

La mesure: Un calcul basé sur le nombre d’images dans lesquelles le ou les éléments se déplacent visuellement et la distance totale en pixels sur laquelle le ou les éléments se sont déplacés.

score de changement de disposition = fraction d’impact * fraction de distance

Comportements clés: CLS est le seul Core Web Vital non mesuré dans le temps. Au lieu de cela, CLS est une métrique calculée. Les calculs exacts sont activement itérés.

Objectif: 75 % des chargements de page ont une métrique calculée par CLS de > 0,10.

Disponible en: Données de laboratoire et de terrain.

Diagnostiquer un mauvais CLS

Où regarder: Pour confirmer qu’il s’agit d’un problème pour les utilisateurs, consultez Crux Dashboard v2 – Cumulative Layout Shift (CLS) (page 4). Utilisez n’importe quel outil avec Lighthouse pour identifier le ou les éléments rebondissants.

Advanced Core Web Vitals : un guide technique de référencement

Chrome DevTools fournira de meilleures informations sur les coordonnées de l’élément excitable et sur le nombre de fois qu’il se déplace.

Comment voir CLS à l’aide de Chrome DevTools

  1. Ouvrez la page dans Chrome.
  2. Accédez au panneau Réseau des outils de développement (Command + Option + I on Mac ou Control + Shift + I sous Windows et Linux).
  3. Cochez la case pour désactiver le cache.
  4. Accédez au panneau de performances et cochez la case Web Vitals.
  5. Cliquez sur le bouton de rechargement pour démarrer une trace des performances.
  6. Cliquez sur le(s) marqueur(s) rouge(s) dans la section Expérience.
  7. Recherchez le nom du nœud, la mise en surbrillance du nœud sur la page et les coordonnées de chaque déplacement de l’élément.

Comment voir CLS à l'aide de Chrome DevTools

Que peut-on compter dans CLS ?

Si un élément apparaît dans la fenêtre d’affichage initiale, il fait partie du calcul de la métrique.

Si vous chargez votre pied de page avant votre contenu principal et qu’il apparaît dans la fenêtre d’affichage, alors le pied de page fait partie de votre score CLS (probablement atroce).

Qu’est-ce qui cause un mauvais CLS ?

Est-ce votre avis sur les cookies ? Il s’agit probablement de votre avis sur les cookies.

Sinon, recherchez :

  1. Images sans dimensions.
  2. Annonces, intégrations et iframes sans dimensions.
  3. Contenu injecté dynamiquement.
  4. Polices Web causant FOIT/FOUT.
  5. Chaînes pour ressources critiques.
  6. Actions attendant une réponse du réseau avant de mettre à jour le DOM.

Comment réparer un mauvais CLS

Toujours inclure width et height attributs de taille sur les images et les éléments vidéo.

C’est aussi simple que <https://www.searchenginejournal.com/technical-seo-core-web-vitals-guide/402501/stable-layout.jpg" width="640" height="360" /> mais pas non plus. La conception Web réactive a vu le déclin des déclarations de hauteur et de largeur. L’impact négatif de ceci est que les pages refluent une fois que l’image est apparue à l’écran.

La meilleure pratique consiste à tirer parti des feuilles de style de l’agent utilisateur pour les dimensions déclarées systématiquement en fonction du rapport d’aspect de l’image.

Réservez de l’espace pour les espaces publicitaires (et ne le réduisez pas).

Si vous êtes un site de publication, vous ne gagnerez jamais un argument sur l’impact négatif des publicités tierces sur les performances.

Au lieu de cela, identifiez la plus grande taille d’annonce qui pourrait être utilisée dans un créneau et réservez de l’espace. Si l’annonce ne se remplit pas, conservez l’espace réservé. L’écart vaut mieux qu’un changement de mise en page.

Évitez d’insérer du nouveau contenu au-dessus du contenu existant.

Un élément ne doit pas entrer dans l’arène de combat s’il n’est pas prêt à être compté.

Faites attention lorsque vous placez des publicités non collantes près du haut de la fenêtre d’affichage.

En règle générale, évitez les publicités près du haut de la page. Vous verrez probablement ceux signalés dans le nouveau rapport d’expérience de la page GSC.

Préchargez les polices et les ressources critiques.

Un chargement tardif de la police provoque un flash complet et une réécriture.

Preload indique au navigateur que vous souhaitez le récupérer plus tôt que le navigateur ne le découvrirait autrement, car vous êtes certain qu’il est important pour la page en cours.

<link rel="preload" href="https://www.searchenginejournal.com/assets/Pacifico-Bold.woff2" as="font" type="font/woff2" crossorigin>

Évitez les chaînes pour les ressources nécessaires à la création de contenu au-dessus de la ligne de flottaison.

Les chaînes se produisent lorsque vous appelez une ressource qui appelle une ressource. Si un actif critique est appelé par un script, il ne peut pas être appelé tant que ce script n’est pas exécuté.

Éviter de document.write()

Les navigateurs modernes prennent en charge l’analyse spéculative du thread principal.

Lire comme : Ils travaillent en avant pendant que les scripts sont téléchargés et exécutés – comme lire avant les devoirs dans une classe. document.write() arrive et change le manuel. Maintenant, ce travail de lecture était inutile.

Il y a de fortes chances que ce ne soit pas le travail de vos développeurs. Parlez à votre point de contact pour cet outil tiers « magique ».

L’avenir des métriques CWV

Google a l’intention de mettre à jour les composants Page Experience sur une base annuelle. Les futures métriques CWV seront documentées de la même manière que le déploiement initial du signal.

Imaginez un monde où les professionnels du référencement seraient avertis un an à l’avance de l’arrivée de Panda !

Les Core Web Vitals représentent déjà 55% de votre score Lighthouse v7.

Actuellement, Largest Contentful Paint (LCP) et First Input Delay (FID) sont chacun pondérés à 25 %. Le changement de mise en page cumulé n’est que de 5 %, mais nous pouvons nous attendre à ce qu’ils s’égalisent.

L’argent intelligent est au quatrième trimestre 2021 une fois que l’équipe Chromium a affiné le calcul de la métrique.

En tant que professionnels du référencement technique, nous sommes en mesure de diagnostiquer et de fournir des solutions pour une meilleure expérience centrée sur l’utilisateur. Voici la chose – ces investissements et améliorations ont un impact sur tous les utilisateurs.

Le retour sur investissement se retrouve sur tous les supports. Chaque canal.

La performance organique est un reflet global de la santé du site. Tirez parti de cette position tout en continuant à plaider et à itérer. Partagez ce que vous apprenez.

Le plus important :

| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
N’ayez pas peur de
apprendre en public
|___________|
(__/) ||
(•ㅅ•) ||
/ づ


Compte à rebours de Noël SEJ 2021 :

  • #12 – Le nouveau profil d’entreprise Google : un guide complet pour le référencement local
  • #11 – Comment automatiser le clustering de mots-clés SEO par intention de recherche avec Python
  • #10 – Familiarisez-vous avec Google Analytics 4 : un guide complet
  • #9 – 7 choses que j’aurais aimé savoir plus tôt dans ma carrière SEO
  • #8 – Un guide d’optimisation pour Google News, Top Stories et Discover
  • #7 – Clusters de mots-clés : comment améliorer votre stratégie de contenu SEO
  • #6 – Advanced Core Web Vitals : un guide SEO technique

Crédits image

Image en vedette : Piscine26/Shutterstock
Toutes les captures d’écran prises par l’auteur