Core Web Vitals for Enterprise Businesses : Q/A avec Kathy Brown et Karl Kleinschmidt

Core Web Vitals for Enterprise Businesses : Q/A avec nos propres Kathy Brown et Karl Kleinschmidt

Le 18 février, nous avons organisé notre session Core Web Vitals for Enterprise Businesses pour aborder la nouvelle mise à jour du facteur de classement de l'expérience de page de Google. La session s'est concentrée sur ce qu'étaient les Core Web Vitals et pourquoi ils étaient importants. Nos experts se sont penchés sur la signification de chacun des nouveaux signaux de classement et sur leur impact sur le référencement. Bien que nous ayons fourni des astuces et des conseils pratiques, il restait encore de nombreuses questions concernant le FID, le LCP, le CLS, etc.

Vous trouverez ci-dessous les questions recueillies auprès de notre public et nos experts Kathy et Karl y répondent.

Quelle est la différence entre les données de terrain et de laboratoire ?

Kathy : Les données de laboratoire sont les données de performance que vous voyez dans un environnement spécifique. Des outils tels que Chrome Dev Tools, ainsi que des outils tels que webpagetest.org vous fournissent des données de laboratoire. Les données de terrain sont des données collectées auprès des nombreux utilisateurs qui utilisent Chrome pour parcourir les pages de votre site. Vous pouvez voir les données de terrain dans Google Search Console et souvent dans Google Page Speed ​​Insights (qui rapportera à la fois les données de laboratoire et de terrain pour une page). Pour les besoins d'automatisation, les données Field sont accessibles via BigQuery. N'oubliez pas que les données de laboratoire sont destinées aux tests, les données de terrain sont destinées au classement. Sur la base des commentaires de John Mueller, nous prévoyons qu'initialement, CWV n'aura d'impact que sur les classements mobiles et que vous devrez être "dans le vert" pour que les trois mesures soient mieux classées.

Que faites-vous lorsqu'il n'y a pas de données de terrain disponibles ?

Kathy : S'il n'y a pas de données disponibles sur le terrain, cela signifie probablement que la page ne reçoit pas beaucoup de trafic. Utilisez Google Page Speed ​​Insights pour vérifier vos pages les plus populaires pour voir si les données de champ sont disponibles pour ces pages. Vous pouvez ensuite extrapoler les résultats pour toutes vos pages appartenant à ce type de page. Essayez de configurer un rapport CrUX pour voir s'il y en a un pour votre origine (votre domaine). Vous pouvez trouver un modèle Google Data Studio prédéfini, qui vous fournira des données de performances pour votre site dans son ensemble.

Si vous ne trouvez toujours aucune donnée Field, déterminez les appareils et les navigateurs les plus courants qui accèdent à votre site et testez à l'aide de ces environnements. N'oubliez pas de définir les contrôles de limitation et de bande passante pour simuler au plus près les environnements de vos visiteurs.

Pendant le développement, nos sites Web sont exécutés sur des serveurs secondaires qui sont beaucoup plus lents que nos serveurs de production. Comment procédez-vous pour tester la vitesse de la page dans cette situation ?

Kathy : Une part importante de la notation Core Web Vital dépendra du client et du code qu'il exécute. Ainsi, un mauvais score CLS n'a rien à voir avec un serveur lent. Cependant, LCP peut être affecté par un serveur lent en raison de poignées de main de connexion plus lentes et du temps nécessaire pour que les ressources soient envoyées. Une approche à considérer consiste à créer une comparaison pour vos serveurs pour des métriques telles que le TTFB (temps au premier octet) pour une variété de pages, ainsi qu'à comparer le temps de livraison de chaque 1 Ko de données. De plus, si vous avez des opérations de base de données ou JS côté serveur, il serait également utile de connaître les différences entre ces temps d'exécution sur chaque serveur. Comparez les graphiques en cascade entre les deux et voyez combien de temps d'attente supplémentaire il y a dans l'environnement de développement. Connaître ces différences permettrait d'évaluer plus facilement les performances LCP sur votre serveur de développement.

Pensez-vous que le préchargement des liens (pour les pages suivantes) aura un impact sur LCP OU pensez-vous que LCP dépend uniquement de la première page que l'utilisateur charge ?

Kathy : En ce qui concerne les données de terrain, les performances de toutes les pages seront importantes. La mise en cache des actifs statiques (qui aide pour les visites et les pages ultérieures) aidera vos scores de terrain. Le préchargement des styles CSS à l'aide du lien, le préchargement aidera probablement également les performances de toutes les pages.

Un CDN avec une bonne optimisation du cache pourrait-il réduire considérablement le score LCP ?

Kathy : C'est certainement possible si le LCP apparaît plus rapidement pour tous les utilisateurs (nouveaux et anciens), alors votre score LCP s'améliorera.

Comment utilisez-vous les fenêtres contextuelles sans qu'elles n'affectent Core Web Vitals ?

Karl : Pour les problèmes LCP, vérifiez que les popups n'occupent pas un pourcentage trop important de la fenêtre d'affichage, en particulier sur mobile.

Pour les problèmes CLS, vérifiez que les popups ne font pas bouger le reste de vos éléments, mais qu'ils sont devant eux.

Comment devrions-nous penser à CWV dans le contexte de l'indexation mobile-first ?

Karl : CWV va être déployé d'abord sur les mobiles et retardé sur les ordinateurs de bureau (nous ne savons pas de combien). CWV ne concerne pas vraiment la façon dont Google explore votre site, mais plutôt la façon dont les visiteurs interagissent avec votre site, donc l'indexation mobile d'abord ne devrait pas faire de différence.

Quelle est la différence entre le temps de blocage total (TBT) et le FID ?

Karl : Le temps de blocage total est le nombre total de millisecondes que les tâches de blocage du thread principal bloquent l'interaction (100 ms sont soustraites par tâche). Le FID est la moyenne du temps nécessaire à votre site Web pour répondre aux interactions des visiteurs. Le temps de blocage total est donc le nombre total de millisecondes dans le chargement de la page où vous pourriez avoir un FID supérieur à 0, tandis que le FID capture la façon dont les utilisateurs interagissent réellement avec votre site.

Nous constatons des changements de score dans Google Search Console sans que nous apportions de modifications/améliorations de notre côté.

Quelle serait la raison de ces fluctuations au sein de la console de recherche ?

Karl : Pour la Search Console, ce sont des données de champ, cela dépend de la façon dont les utilisateurs interagissent avec votre site. Des changements dans le comportement des utilisateurs peuvent signifier des scores CLS différents parce que les visiteurs défilent différemment ou des scores LCP différents parce qu'un pourcentage plus élevé de visiteurs reviennent des clients, de sorte qu'ils ont certaines images mises en cache. Il existe de nombreuses causes possibles aux fluctuations des métriques et rappelez-vous que les données sont retardées d'environ 28 jours, vous avez donc peut-être publié quelque chose il y a 28 jours et voyez maintenant les changements dans les données.

Si quelqu'un obtient des résultats différents de la Search Console et de PageSpeedTest, devrions-nous nous soucier uniquement de ce qui est signalé sur la Search Console ?

Karl : En dehors des données de terrain par rapport aux données de laboratoire, il existe deux causes principales pour les différences de données entre la console de recherche et les informations sur la vitesse des pages. Si l'une de vos pages n'a pas reçu suffisamment de trafic, Google utilise des données de page similaires dans les informations sur la vitesse des pages, tandis que dans la console de recherche sont regroupées les pages similaires qui pourraient avoir suffisamment de données. Il est donc également possible qu'une de vos pages ait suffisamment de trafic, mais qu'aucune des pages similaires n'ait suffisamment de trafic, ce qui pourrait également entraîner une différence de scores. Il y a également eu une mise à jour des rapports de la console de recherche, qui aurait pu avoir un impact.

Besoin de ressources supplémentaires ?

Nous avons beaucoup de contenu intéressant sur ce sujet. Consultez notre page Core Web Vitals où nous avons rassemblé une bibliothèque de ressources expertes telles que des podcasts, des webinaires et des blogs. Vous pouvez trouver tout ce dont vous avez besoin pour vous préparer à la mise à jour du facteur de classement Page Experience de Google.