Home Articles techniques Comment optimiser Core Web Vitals pour les sites Web de commerce électronique
Applications

Comment optimiser Core Web Vitals pour les sites Web de commerce électronique

About The Author

Outline

La prochaine mise à jour de Google page Experience introduit des signaux dérivés de Core Web Vitals (CWV) dans l’algorithme de classement officiel. Core Web Vitals est un ensemble de mesures qui mesurent la vitesse à laquelle les pages se chargent, deviennent interactives et se stabilisent visuellement pour les utilisateurs réels qui interagissent avec elles. Les sites Web qui échouent au test Core Web Vitals seront classés plus bas qu’ils ne le sont actuellement au début de 2021.

CWV se compose de mesures à 3 vitesses qui ont un impact significatif sur l’expérience perçue d’un utilisateur. Il s’agit notamment de la plus grande peinture Contentful Paint (LCP) pour mesurer les temps de chargement, du premier retard d’entrée (FID) pour mesurer l’interactivité et la réactivité, et du décalage de mise en page cumulatif (CLS) pour mesurer la stabilité visuelle. Bien que la vitesse du site Web ait été à l’avant-garde pour de nombreuses entreprises de commerce électronique, elle est sur le point de devenir l’un des facteurs les plus importants du paysage en ligne. Voici les indicateurs sur lesquels vous devez vous concentrer et comment améliorer la vitesse pour chacun.

Quels sont les Core Web Vitals

Faire une bonne première impression en ligne est essentiel. Les acheteurs veulent voir les produits immédiatement, naviguer rapidement et passer des commandes facilement, sans interruption. Si leurs attentes ne sont pas satisfaites, ils rebondiront et ne reviendront jamais. Core Web Vitals aide à résoudre ce problème en évaluant l’expérience que les pages fournissent aux acheteurs mobiles lorsqu’ils naviguent sur un site en temps réel.

Alors que la plupart des outils Google reposent sur des tests synthétiques dans des environnements simulés (appelés données de laboratoire), Core Web Vitals sont mesurés à l’aide de données de terrain collectées à partir de Google Chrome User Experience (Crux), une base de données utilisateur Chrome réelle. Les données de terrain capturent les effets dramatiques des variables utilisateur réelles, telles que l’appareil, les conditions du réseau et/ou les paramètres. Selon les conditions de l’utilisateur, les performances d’un site peuvent varier considérablement et avoir un impact sur vos scores Core Web Vital.

Chaque mesure CWV a différents seuils à considérer comme bon, modéré ou mauvais. Cependant, ils ont tous une chose en commun : Google utilise le 75e percentile pour classer les pages dans ces groupes : une page qui atteint le seuil pour être considérée comme rapide pour 75% des chargements de page ou plus est une bonne expérience.

Vous ne pouvez pas optimiser ce que vous ne savez pas, alors apprenons à connaître chacune des trois métriques qui composent les Core Web Vitals.

Source : https://web.dev/vitals/

Peinture la plus complète (LCP)

Les utilisateurs ont généralement le sentiment que la page a été chargée lorsque le plus grand élément de contenu est entièrement visible à l’écran, c’est-à-dire à la vitesse de la plus grande peinture Contentful, ou LCP. Les éléments de contenu peuvent inclure des éléments de niveau bloc, des images (y compris des images dans des fichiers SVG) et des vidéos. Pour le commerce électronique, les LCP mesurent généralement la vitesse à laquelle l’image du produit ou l’image du héros se charge. Si cela est lent, les utilisateurs supposent que toute l’expérience sera similaire, ce qui les amène à partir pour le site d’un concurrent.

Les LCP de 2,5 secondes ou moins sont considérés comme rapides, les pages avec des LCP entre 2,6 et 4,0 secondes doivent être améliorées et les LCP de plus de 4,0 secondes sont lentes.

TheTieBar.comcharge LCP en 800 ms sur Layer0 (Edgio)

Dans l’exemple ci-dessus, le LCP de la Tie Bar est marqué à 900 ms lorsque l’image principale est entièrement peinte. Tie Bar fournit régulièrement des chargements de pages inférieurs à la seconde aux acheteurs mobiles tout en offrant une personnalisation, des recherches d’inventaire en temps réel et une tarification dynamique sur ses milliers de pages sur Edgio.

Généralement, le LCP est affecté par l’un des éléments suivants :

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

Pour optimiser votre LCP, tenez compte des points suivants :

  1. Optimisez les temps de réponse des serveurs en acheminant le trafic vers le CDN POP le plus proche disponible, en mettant en cache les actifs, en utilisant un service worker et en établissant des connexions tierces tôt avec « rel= »preconnect ».
  2. Réduisez le temps de blocage JavaScript en minimisant le code (par exemple, en supprimant les espaces blancs), en compressant les données avec des outils comme Broti ou gzip, en divisant les paquets et en envoyant uniquement ce qui est nécessaire au début, et en servant du code avec une syntaxe plus récente avec des outils comme Babel. Réduisez les CSS en supprimant les CSS inutilisés ou les caractères inutiles tels que l’espacement, l’indentation ou les commentaires, et en insérant les CSS critiques en les incluant directement dans la tête de la page.
  3. Pour réduire les temps de chargement des ressources, optimisez et compressez les fichiers image et texte, préchargez les ressources essentielles et distribuez différentes ressources en fonction de la connexion réseau et mettez en cache les ressources à l’aide d’un service worker.
  4. Optimisez le rendu côté client en réduisant le temps de blocage JavaScript (voir #2 pour optimiser pour cela), en utilisant le rendu côté serveur (SSR) et le pré-rendu.

Délai de première entrée (FID)

Bien que la première impression d’un utilisateur soit impactée par la vitesse à laquelle la plus grande image est rendue, il est tout aussi crucial que votre site soit réactif une fois que votre utilisateur essaie d’interagir avec elle. First Input Delay, ou FID, mesure le temps entre le moment où un utilisateur interagit pour la première fois avec une page (clique, appuie ou appuie sur une touche) et le moment où le navigateur peut répondre à cette interaction.

En général, un délai d’entrée se produit parce que JavaScript est exécuté sur le thread principal, et tout JavaScript bloque le rendu par défaut. Cela signifie que lorsque le navigateur rencontre un fichier JavaScript, il doit mettre en pause ce qu’il fait pour télécharger, analyser, compiler et exécuter ce JavaScript. Plus cela prend de temps, plus l’expérience de l’utilisateur est retardée et moins Google verra la page comme utilisable.

Google considère un FID de 100 millisecondes ou moins comme rapide, entre 1,1 et 3,0 secondes comme nécessitant une amélioration, et plus de 3,0 secondes comme lent. Bien qu’il soit important de viser le 75e percentile pour tous les Core Web Vitals, Google recommande de regarder les 95e et 99e percentiles pour FID sur mobile et ordinateur de bureau, car cela représentera les pires expériences utilisateur et vérifiera les domaines qui ont le plus besoin d’amélioration (car il se concentrera sur le FID pour plus de 95% des chargements de page).

Il est également important de noter que contrairement au LCP et au CLS, le FID ne peut être mesuré que sur le terrain (et ne se retrouve pas dans les données de laboratoire), car il nécessite une réelle interaction de l’utilisateur.

Les raisons courantes de lenteur des FID sont les suivantes :

  1. Tâches longues qui bloquent le thread principal pendant 50 millisecondes ou plus
  2. L’exécution du script de première partie retardant la préparation à l’interaction
  3. Temps d’exécution JavaScript élevé

‍How à optime pour FID :

  1. Décomposez le code à exécution longue en tâches asynchrones plus petites et utilisez la division de code.
  2. Déplacez le chargement (et l’exécution) de scripts lourds pour les composants non essentiels hors du chemin critique et réduisez l’extraction de données en cascade et la quantité de données à post-traiter côté client.
  3. Utilisez un Web worker, tel que Comlink, Workway ou Workerize, qui permet d’exécuter JavaScript sur un thread d’arrière-plan, de diviser votre bundle JavaScript en plusieurs morceaux (également appelé lazy-loading) et de charger tous les scripts tiers avec defer ou async.

Décalage cumulé de la mise en page (CLS)

La stabilité visuelle d’une page est un autre facteur qui influe sur l’expérience utilisateur et peut empêcher les acheteurs de poursuivre sur la voie de l’achat. La troisième et dernière mesure de Core Web Vitals est cumulative Layout Shift, ou CLS, qui mesure la fréquence à laquelle les utilisateurs subissent des changements de disposition inattendus.

Vous avez rencontré ces cas : vous êtes sur le point d’appuyer sur un lien ou une image de produit, mais juste avant de toucher l’écran, la page se déplace, et bam, vous cliquez sur autre chose involontairement. Dans le meilleur des cas, ces situations sont une légère gêne, mais dans le pire des cas, vous envoyez les acheteurs à la recherche d’une expérience plus fluide et moins fougueuse sur le Web.

Google calcule ces mouvements de page en multipliant la fraction d’impact, ou la quantité de contenu visible déplacée dans la fenêtre, par la fraction de distance, ou la distance qu’un élément instable a déplacée dans le cadre divisé par la plus grande dimension de l’écran (hauteur ou largeur). Le total de tous les scores individuels (fraction d’impact x fraction de distance) pour chaque changement de mise en page inattendu qui se produit lorsqu’un acheteur navigue entraîne le CLS d’une page.

Google considère un CLS inférieur à 0,1 comme bon, entre 0,1 et 0,25 comme modéré, et supérieur à 0,25 comme mauvais.

Si vous trouvez un mauvais CLS, c’est probablement dû à l’une des causes suivantes :

  1. Une image ou une vidéo qui se redimensionne elle-même
  2. Redimensionnement des annonces
  3. 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 les dimensions exactes de vos images et éléments vidéo.
  2. Évitez les publicités popup ou les bannières. Au lieu de cela, réservez statiquement un grand espace pour l’emplacement d’annonce.
  3. Évitez les flashs de texte non stylisé ou invisible (foi/fout) avec des outils tels que l’affichage des polices et l’ API de chargement des polices.

Comment Layer0 aide à optimiser la vitesse pour chaque métrique Core Web Vitals

Les grands sites Web de commerce électronique complexes avec des millions de pages, 1000s de SKU, des tests A / B et la personnalisation, la tarification dynamique et les recherches d’inventaire en temps réel peuvent atteindre des vitesses inférieures à quelques secondes avec Layer0. En fait, Layer0 est la seule plate-forme sur le marché à garantir des LCP médians inférieurs à 500ms.

Sur Layer0, le contenu s’affiche instantanément, ou peint, sur une page et devient immédiatement tapable grâce à notre CDN configurable JavaScript compatible avec les applications appelé CDN -as-JavaScript. Il utilise la prélecture prédictive avancée et l’informatique de périphérie pour diffuser du contenu dynamique (JSON/SSR/HTML) de la périphérie vers le navigateur de l’utilisateur, avant même qu’il ne soit demandé. Cela garde les sites 5 secondes d’avance sur les robinets des acheteurs à tout moment.

Les sites Web sur Layer0 ont un taux de réussite du cache de plus de 95% pour les données HTML et JSON à la périphérie, tandis que les sites sur CDN traditionnels ont une moyenne de 6%. C’est une énorme différence dans la livraison du contenu qui rend généralement un site Web lent.

Résultat

Les chargements de page rapides différencient entre ravir les acheteurs et les effrayer pour le site de votre concurrent. Core Web Vitals prend en compte la première impression de l’utilisateur en termes de vitesse, d’interactivité et de stabilité visuelle en mesurant la peinture Contentful la plus grande, le délai de première entrée et le décalage de mise en page cumulatif. Si les vitesses sont supérieures à 2,5 s pour LCP, 100 ms pour FID ou .1 pour CLS, vous pouvez supposer que les utilisateurs et Google perçoivent votre site comme lent. Google abaissera votre rang, et les consommateurs rebondiront et ne reviendront jamais.

En seulement quelques mois, une mauvaise expérience de page nuira à la réputation de votre marque et impactera votre classement SEO. Protégez votre SEO durement gagné en utilisant les tactiques d’optimisation proposées ci-dessus, ou allez instantanément avec Layer0 (maintenant Edgio).

Layer0 est votre solution tout-en-un pour développer, déployer, prévisualiser, expérimenter, surveiller, et exécutez votre frontend. Shoe Carnival, REVOLVE et 1-800-Flowers ne sont que quelques exemples de sites Web de commerce électronique qui offrent des vitesses inférieures à la seconde et en récoltent les avantages. Si vous avez des questions sur la mise à jour de l’expérience de page ou sur la façon d’accélérer votre site, nous serions heureux de vous mettre en contact avec un expert en vitesse de site dès aujourd’hui.

La prochaine mise à jour de Google page Experience introduit des signaux dérivés de Core Web Vitals (CWV) dans l’algorithme de classement officiel. Core Web Vitals est un ensemble de mesures qui mesurent la vitesse à laquelle les pages se chargent, deviennent interactives et se stabilisent visuellement pour les utilisateurs réels qui interagissent avec elles. Les sites Web qui échouent au test Core Web Vitals seront classés plus bas qu’ils ne le sont actuellement au début de 2021.