Comment optimiser la mise à jour de l'expérience de la page au niveau de l'entreprise (étude de cas internationale)
Publié: 2021-06-23Le SEO dans sa globalité est un vaste sujet, sans parler de l'aspect technique.
Au cours des deux derniers mois, il a été difficile de se promener dans le domaine du référencement technique sans toucher ou entendre parler de Google Page Experience Update et de Core Web Vitals.
Vous vous demandez peut-être ce que c'est et comment cela vous affectera ou peut-être doutez-vous de la façon de travailler avec pour optimiser votre site Web - et pour de bonnes raisons !
L'objectif est de vous donner les informations nécessaires sous forme d'étude de cas que vous pourrez utiliser sur votre propre site Web (ou celui de votre client) dans les derniers jours avant le « lancement ».
Mais nous devons ramper avant de marcher, alors commençons par les bases.
Qu'est-ce que CWV et pourquoi le réparer ?
Core Web Vitals est un ensemble de mesures spécifiques que Google utilise pour évaluer l'expérience utilisateur d'un site Web.
L'intention est d'utiliser ces mesures pour évaluer le classement d'un site Web sur son contenu et assurer une expérience utilisateur satisfaisante.
C'est comme si un vrai utilisateur décidait de quitter un site à chargement lent ou un site avec une interface difficile, quelle que soit la qualité du contenu.
Core Web Vitals se compose de trois estimations de vitesse de page spécifiques et de valeurs d'interaction utilisateur :
- La plus grande peinture de contenu
- Premier délai d'entrée
- Changement de mise en page cumulé
Les valeurs sont évaluées individuellement sur les ordinateurs de bureau et mobiles pour tenir compte de l'expérience sur différentes fenêtres d'affichage et adaptateurs réseau.
LCP (Largest Contentful Paint) - Expérience de chargement
LCP exprime le temps qu'il faut avant que la plupart du contenu d'un site Web soit disponible (rendu) sur l'écran de l'utilisateur.
Lorsque Core Web Vitals estime qu'une optimisation est disponible pour ce paramètre, elle se base souvent sur les fichiers frontaux (HTML, CSS, fichiers Image).
En effet, trop de fichiers sont nécessaires pour afficher le site dans le navigateur de l'utilisateur. Il se peut également que les fichiers soient trop volumineux ou que le serveur n'ait pas la capacité suffisante pour les livrer à temps.
Une solution suggérée peut être de s'assurer que ces fichiers sont plus petits, sont envoyés via moins de requêtes HTTP et dimensionnent le serveur pour qu'il corresponde au trafic et à la taille du site Web.
FID (First Input Delay) – Interactivité
Le FID exprime le temps qu'il faut avant qu'un utilisateur puisse interagir avec les pressions sur les boutons du site, les pressions sur l'écran tactile, les entrées au clavier, etc.
Les problèmes de cette catégorie sont souvent causés par la quantité d'interaction et de rendu DOM dynamique ou basé sur Javascript.
Le navigateur a donné la priorité au chargement de ces scripts et n'a pas accepté l'interaction de l'utilisateur avant le chargement. Plus il est difficile de charger et d'exécuter ces scripts, plus il faudra de temps avant d'interagir avec le site Web.
Le FID est théoriquement amélioré en réduisant le temps entre l'affichage de la page jusqu'à ce qu'il permette une interaction. En d'autres termes, il est possible de diviser vos fichiers JavaScript en parties plus petites si nécessaire.
Ce faisant, vous pouvez donner la priorité au chargement des éléments essentiels pour utiliser le site Web (clics, tapotements, interactions de curseur, etc.) - laissant les animations, effets et autres fonctionnalités extraordinaires à charger en second lieu.
En pratique, le FID est mesuré comme une métrique utilisateur individuelle - il ne mesure pas le temps avant qu'un utilisateur puisse interagir avec lui, mais plutôt le temps avant qu'un utilisateur n'interagisse avec lui. Il est possible d'obtenir un score élevé sur cette métrique si l'utilisateur obtient des informations indiquant que le site n'est pas disponible, par exemple, par des animations de chargement ou des espaces réservés pour de grands ensembles de données.
CLS (changement de mise en page cumulé)
CLS indique si le site Web place de nouveaux boutons, textes ou images après d'autres éléments de contenu sur un site - si le site charge des éléments de manière asynchrone, cela peut modifier la structure de la mise en page d'origine et perturber considérablement l'expérience utilisateur.
Les fichiers image non optimisés provoquent souvent cela ou d'éventuelles polices Web qui ne peuvent pas être préchargées et qui s'affichent après la mise en place du balisage initial. Les widgets tiers intégrés peuvent également entraîner un changement dans la mise en page.
La solution consiste souvent à précharger le contenu. De cette façon, les éléments capables de modifier la mise en page seront en place avant que la page ne s'affiche pour la première fois.
Vous pouvez également utiliser des conteneurs verrouillés pour votre contenu. De cette façon, le placement du contenu initial ne change pas lorsque certains éléments commencent à apparaître.
[Étude de cas] Augmenter le budget de crawl sur les pages stratégiques
Lire l'étude de casIl est temps de marcher
Maintenant que nous nous sommes occupés des bases, il est temps de l'utiliser, et c'est exactement ce que nous avons fait avec un cas client.
Ce cas spécifique était amusant car il comportait différents types d'erreurs et se concentrait donc sur différents domaines d'optimisation.
Il y a de nombreux domaines d'intérêt et points d'action à remarquer tout au long de l'étui - alors attachez votre ceinture et profitez du voyage.
Je vais vous guider à travers :
- L'affaire
- Ce que nous avons fait sur l'affaire
- Pourquoi nous avons fait comme nous l'avons fait
- Points clés à retenir
Le cas : Logpoint ; Entreprise internationale de cybersécurité
Le site, Logpoint.com, travaille dans le domaine de la cybersécurité et est une marque bien connue dans le monde entier.
Être une grande entreprise internationale signifie que beaucoup de trafic passe par le site Web. Par conséquent, il est essentiel de s'assurer que les visiteurs obtiennent la meilleure expérience possible - et donc un cas encore plus avancé pour les Core Web Vitals.
L'expérience utilisateur est composée de nombreux facteurs différents, mais les Core Web Vitals sont particulièrement importants pour constituer et mesurer l'expérience dans son ensemble.
L'image ci-dessus illustre la situation avant de commencer notre optimisation de Core Web Vitals. Le point de départ de Logpoint n'était pas si mauvais, comparé à de nombreuses autres entreprises plus importantes, mais comme le montre le graphique, il y a place à l'amélioration.
Cela peut aussi être quelque chose auquel vous pouvez vous identifier.
Il est crucial de s'assurer que chaque URL possible soit dans la catégorie d'une "bonne URL" car elle se traduit par la meilleure expérience utilisateur et parce que Google fait de Core Web Vitals un facteur de classement à la mi-juin 2021 avec leur mise à jour : Google Page Vivre.
Ce que nous avons fait sur l'affaire
Au cours de notre optimisation, toute la situation de Core Web Vitals a beaucoup changé. Lorsque nous avons commencé, les principaux problèmes étaient les problèmes LCP et CLS sur les formats mobiles et de bureau - et, bien sûr, la vitesse des pages.
Le monde change et les sites Web aussi - donc si vous avez optimisé pour CWV il y a six mois, cela pourrait sembler différent maintenant.
Console de recherche Google (Core Web Vitals)
La première chose que nous avons faite a été de nous plonger dans les différents types d'erreurs et de déterminer quelles URL étaient affectées. Comme vous le savez peut-être déjà, Google Search Console et son onglet Core Web Vitals ont un aperçu du format mobile et de bureau.
En allant plus loin dans les rapports des formats, un aperçu des types d'erreurs apparaît, où il est possible d'aller encore plus loin dans une erreur spécifique.
À partir de la vue d'ensemble, il est possible de franchir une dernière étape, et c'est à partir de là que notre travail a commencé.
Chaque URL affectée par le type d'erreur est affichée à cette étape spécifique, ce qui permet de démarrer notre analyse.
Informations sur la vitesse de la page
Connaissant les URL concernées, notre prochaine étape consistait à les analyser pour identifier les éléments à l'origine des erreurs. C'est là que PageSpeed Insights entre en jeu. En analysant les URL, nous avons compris le score de santé PageSpeed, mais nous avons également pu examiner les éléments contribuant aux erreurs.
Chrome DevTool - Analyse des performances
Pour être clair sur les types d'erreurs et les éléments qui les provoquent, nous avons utilisé l'analyse des performances trouvée dans le DevTool. En comparant cet outil avec PageSpeed Insights et les rapports Core Web Vitals, nous nous sommes assurés d'avoir une vue plus globale des informations fournies par les différents moyens et de la manière dont ils sont liés les uns aux autres.
Chaque outil fournit à lui seul une perspective unique sur les détails, qui à son tour crée le plus grand ensemble.
Une fois le profilage effectué, un tas de cases rouges sont apparues dans la section Expérience . Ceux-ci indiquaient un chargement d'élément, qui modifiait en quelque sorte la disposition en se déplaçant ou en poussant des éléments adjacents.
Cliquer sur un élément révèle un ensemble d'informations utiles :
- Score
Cette valeur indique le nombre de points que cet élément particulier ou cet événement de chargement occupe lors du calcul du score CLS accumulé. éléments adjacents autour. - Note cumulée
Cette valeur indique le total de tous les points d'événement CLS pour déterminer la gravité de la situation accumulée pour la page donnée. Pour répondre aux normes de Google, le score CLS accumulé ne peut pas dépasser 0,1 point. Il est recommandé que le score soit encore plus bas, car le CLS est une valeur calculée individuellement et peut être moins bien noté par le robot d'exploration de Google que lors du calcul du score sur son ordinateur. - A eu une entrée récente
Cette valeur indique si l'élément a été interagi avec jusqu'à ce que le changement de disposition se produise. Pour une page HTML statique, c'est rarement une valeur dont il faut se préoccuper. Généralement, il indique si une entrée utilisateur a provoqué ou non le changement de mise en page. - Déplacé de / Déplacé vers
Cette valeur indique où se trouvait initialement l'élément et où se trouvait sa nouvelle position après le déplacement. Il n'est pas rare que le composant ait plusieurs valeurs déplacées de / déplacées vers s'il a été déplacé plusieurs fois. Le survol des valeurs affiche un aperçu à l'écran de l'emplacement de l'élément avant et après le changement de disposition. - Nœud associé
Cette valeur fait référence au nœud DOM dans le flux de documents, qui a été déplacé. En fonction de l'emplacement de l'erreur, cela donnera un bon pointeur dans la direction de quel élément a provoqué le décalage ou a été affecté par un élément adjacent qui, à son tour, a provoqué le décalage.
La cause des erreurs
La principale raison des erreurs LCP était due à une image de héros apparaissant sur chaque page du site Web.
Bien sûr, il existe de nombreuses façons d'optimiser une image de héros comme celle-ci en la compressant et en la redimensionnant, ce qui aurait été l'une des choses à faire si Logpoint voulait conserver sa conception et sa mise en page. Cependant, ce n'était pas le cas, nous avons donc supprimé l'image du héros qui s'occupait de la plupart des erreurs LCP.
Une autre cause des erreurs LCP était la structure du code. Logpoint utilise un constructeur de page, ce qui permet au constructeur de définir les limites de la manière de structurer à la fois la conception et le code.
À certains endroits sur le site Web, l'ensemble de la mise en page présentait des défauts, comme les balises p imbriquées dans h1 , ce qui faisait que les éléments de texte devenaient la plus grande peinture de contenu. Pour résoudre ce problème, nous avons balayé le site Web pour rationaliser et optimiser la structure du code.
Comme mentionné, le CLS faisait également partie du problème, et il a été principalement déclenché par deux éléments - qui en fait s'affectaient mutuellement.
Les deux éléments
Tout d'abord, Logpoint avait des intégrations Youtube sur son site Web, et pour aider avec le temps de chargement, ils ont implémenté une vignette. Le problème était que la vignette et la vidéo étaient chargées simultanément, après quoi la vidéo était supprimée par le code JavaScript. Cela a entraîné d'importants changements de mise en page sur le site Web.
Le deuxième élément affectant CLS était le CookieBot mis en œuvre sur le site Web. Comme prévu, le CookieBot a donné des autorisations concernant les vidéos, de sorte qu'elles ne pouvaient pas être visionnées tant que le consentement n'avait pas été donné.
C'est là que les deux éléments interagissent. Le code JavaScript supprimant la vidéo a été créé sur mesure par le développeur et a été programmé pour interagir avec le consentement de CookieBot.
Pour résoudre le problème, nous avons modifié le script en retardant le chargement de l'élément vidéo et le chargement du script lui-même.
Il est essentiel de mentionner que Logpoint est un grand site Web avec de nombreux composants qui interagissent tous les uns avec les autres de différentes manières. Cela, combiné au constructeur de thèmes et de pages, rend le site Web complexe et limite également certaines des options d'optimisation.
PageSpeed a été affecté
Cela, bien sûr, a affecté la PageSpeed, donc tout en nous concentrant sur Core Web Vitals, nous avons également travaillé à l'optimiser. Pour ce faire, nous avons installé les plugins : WP Engine pour obtenir un hébergement rapide, WP Rocket pour obtenir une excellente mise en cache et une optimisation de HTML, CSS et JS, et enfin, CloudFlare , pour obtenir un excellent fournisseur DNS.
Les variations de langue ont créé de nouvelles erreurs Core Web Vitals…
Pendant que nous optimisions, Logpoint a subi des changements importants sur son site Web, publiant de nombreuses nouvelles pages dans différentes langues, avec de nouveaux éléments et une nouvelle mise en page qui ont entraîné l'apparition de nouvelles erreurs Core Web Vital - un nouveau type d'erreur CLS devait maintenant être corrigé.
Encore une fois, nous avons suivi notre processus d'analyse. Dans ce cas particulier, les changements de mise en page ont été causés par un plugin de chat tiers. Le plus souvent, cette erreur est corrigée en ajoutant et en modifiant des règles CSS, mais en raison de la mise en œuvre du chatbot par un tiers, nous n'avons pas pu y ajouter efficacement de CSS personnalisé.
Par conséquent, notre objectif était à la fois de publier une demande de mise à jour auprès des développeurs du plugin, car l'ajout avait un impact visible sur un site par ailleurs très performant, et alternativement, de trouver un plugin de chat avec une meilleure hiérarchisation des charges.
Pourquoi nous avons fait ce que nous avons fait
Le fait que Core Web Vitals devienne un facteur de classement est un changement fondamental dans le fonctionnement des classements par les moteurs de recherche. Un site Web mal conçu qui ne se concentre pas sur l'expérience utilisateur ne le coupera tout simplement plus.
L'objectif de Google est d'aider les propriétaires de sites Web à créer des sites axés sur l'expérience utilisateur, et en incluant Core Web Vitals comme facteurs de classement, ils le font précisément.
Google n'est pas connu pour jouer avec des cartes ouvertes ou pour nous informer à l'avance de leurs mises à jour, mais avec leurs Core Web Vitals et Page Experience Update, nous avons en fait été informés au début du processus.
Cela nous a bien sûr donné le temps de maîtriser les connaissances de Core Web Vitals, mais cela signifiait également que de nombreux éléments et idées n'étaient pas encore définitivement décidés et modifiés au cours de la période allant de l'introduction à aujourd'hui.
Cela incluait les résultats d'avoir un score Core Web Vitals parfait - seulement de bonnes URL.
Au début, il était incertain de quelle manière le facteur de classement Core Web Vitals affecterait les URL. C'est un sujet depuis un certain temps – mais en juin, nous en saurons tous plus sur l'impact à coup sûr.
"Les pages qui reçoivent un score de" bon "sur Core Web Vitals atteignent un niveau d'expérience utilisateur ambitieux et pourraient bénéficier d'un coup de pouce dans le composant d'expérience de page du classement."
– Documents Google
Dans le même ordre d'idées, il est également difficile de savoir si un rapport Core Web Vitals ne maîtrisant pas tous les types d'erreurs serait affecté négativement ou s'il a encore un effet positif.
"Si vous avez des pages qui ne sont pas "bonnes" sur au moins une des métriques Core Web Vitals ou qui ne répondent pas aux autres critères d'expérience de page, nous vous recommandons de vous concentrer sur les améliorations de ces dimensions au fil du temps. Bien que tous les composants de l'expérience de la page soient importants, nous donnerons la priorité aux pages contenant les meilleures informations dans l'ensemble, même si certains aspects de l'expérience de la page sont inférieurs.
– Documents Google
De plus, une idée de badge Core Web Vitals est sur la planche à dessin - tout comme nous le savons grâce au badge AMP. Cela reste également à déterminer définitivement.
"La ligne directrice générale est que nous aimerions également utiliser ces critères pour afficher un badge dans les résultats de recherche, et je pense qu'il y a eu des expériences autour de cela. Et pour cela, nous avons vraiment besoin de savoir que tous les facteurs sont conformes. Donc, si ce n'est pas sur HTTPS, alors essentiellement même si le reste est OK, cela ne suffirait pas.
– John Mueller, analyste des tendances pour les webmasters, Google
Alors même s'il y a eu beaucoup d'incertitudes, une chose est sûre ! Core Web Vitals est là pour rester et deviendra une grande partie de la bataille pour le trafic organique - et c'est pourquoi nous avons déployé des efforts supplémentaires pour corriger les erreurs Core Web Vitals sur Logpoint.
Points clés à retenir
Au bout du chemin, il est tout à fait approprié de revenir sur nos débuts - et j'espère que ce cas vous a donné les connaissances et les outils nécessaires pour commencer à marcher par vous-même.
Core Web Vitals est quelque chose que je prédis être l'avenir du référencement. Nous avons de plus en plus recours au trafic organique pour influer sur la croissance, et Core Web Vitals n'est rien d'autre qu'un rapport pour perfectionner l'expérience utilisateur.
Lorsque nous responsabilisons l'utilisateur et lui donnons un produit qui vaut son temps, alors, bien sûr, il voudra interagir avec lui.
Logpoint, étant la star de l'émission, a subi une transformation grâce aux informations de Core Web Vitals, nous permettant de traiter les problèmes LCP et CLS ainsi que les intégrations tierces et la structure globale du code désordonné.
En adhérant aux meilleures pratiques tout en mettant en perspective les informations fournies par Core Web Vitals, nous avons pu transformer les aspects techniques du site de manière à ce qu'il se démarque de la foule - c'est à Google de décider .
Un conseil final
Un conseil amical de ma part avant de conclure est de vous concentrer sur l'optimisation de vos Core Web Vitals - non seulement à cause du facteur de classement, mais aussi parce qu'il a un impact massif sur les visiteurs de votre site Web - et n'est-ce pas ce que le référencement est tout sur?
Non seulement cela augmentera le temps passé sur le site, mais cela diminuera également le taux de rebond et, espérons-le, se traduira par des quantités plus élevées de classements et de conversions.
Rédigé en collaboration avec Andre Vestergaard, spécialiste SEO technique chez Bonzer.