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 page Experience de Google introduit des signaux dérivés de Core Web Vitals (CWV) dans l’algorithme de classement officiel. Core Web Vitals sont 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 se classent moins bien qu’ils ne le font actuellement au début de 2021.

La VFC consiste en des mesures à 3 vitesses qui ont un impact significatif sur l’expérience perçue par l’utilisateur. Il s’agit notamment de la plus grande peinture Contentful Paint (LCP) pour mesurer les temps de chargement, du premier délai d’entrée (FID) pour mesurer l’interactivité et la réactivité, et du décalage de disposition cumulatif (CLS) pour mesurer la stabilité visuelle. Alors que la vitesse des sites Web a é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 dans le paysage en ligne. Voici les indicateurs sur lesquels vous devez vous concentrer et comment améliorer la vitesse pour chacun d’eux.

Quels sont les principaux éléments vitaux Web

Faire une bonne première impression en ligne est essentiel. Les acheteurs veulent voir les produits immédiatement, naviguer rapidement et passer commande 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 spectaculaires des variables utilisateur réelles, telles que les conditions de l’appareil, du réseau et/ou des 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 des seuils différents pour être considérée comme bonne, modérée ou mauvaise. Cependant, ils ont tous une chose en commun : Google utilise le 75e percentile lors de la classification des pages dans ces groupes : une page qui atteint le seuil pour être considérée comme rapide pour 75% des charges 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 de plus grande qualité (LCP)

Les utilisateurs ont généralement l’impression que la page s’est chargée lorsque le plus grand élément de contenu est entièrement visible à l’écran, c’est-à-dire par la vitesse de la plus grande peinture Contentful Paint, 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/image principale se charge. Si cela est lent, les utilisateurs supposent que l’expérience entière 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 de 2,6 à 4,0 secondes doivent être améliorées et les LCP de plus de 4,0 secondes sont lents.

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

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

En général, 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 éléments suivants :

  1. Optimisez les temps de réponse du serveur en acheminant le trafic vers le pop CDN le plus proche disponible, en mettant en cache les actifs, en utilisant un service worker et en établissant des connexions tierces précocement avec « rel= »preconnect ».
  2. Réduisez le temps de blocage JavaScript en miniaturisant 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 le code avec une syntaxe plus récente avec des outils comme Babel. Réduisez le CSS en supprimant tout CSS inutilisé ou les caractères inutiles tels que l’espacement, l’indentation ou les commentaires, et en insérant le CSS critique en l’incluant directement dans le en-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 des ressources de cache à 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 la première entrée (FID)

Bien que la première impression d’un utilisateur soit affectée par la vitesse à laquelle la plus grande image est rendue, il est tout aussi crucial pour votre site d’être réactif une fois que votre utilisateur tente d’interagir avec lui. Le délai de première entrée, ou FID, mesure le temps entre le moment où un utilisateur interagit pour la première fois avec une page (clic, appui ou appui sur une touche) et le moment où le navigateur peut répondre à cette interaction.

Généralement, un délai d’entrée se produit parce que JavaScript est exécuté sur le thread principal, et que 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 les expériences utilisateur sont retardées et moins Google verra la page comme utilisable.

Google considère qu’un FID de 100 millisecondes ou moins est aussi 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 centile pour tous les Core Web Vitals, Google recommande de regarder les 95e à 99e centiles 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 charges 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 sera pas trouvé dans les données de laboratoire), car il nécessite une réelle interaction de l’utilisateur. ‍

Les raisons les plus courantes des FID lents sont les suivantes :

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

‍How à optime pour FID:

  1. Décomposer le code de longue durée en tâches plus petites et asynchrones et utiliser le fractionnement du code.
  2. Déplacez le chargement (et l’exécution) de scripts lourds pour les composants non essentiels hors du chemin critique et minimisez la récupération 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 fractionner votre bundle JavaScript en plusieurs morceaux (également connu sous le nom de lazy-loading) et de charger tous les scripts tiers avec defer ou async.

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

La stabilité visuelle d’une page est un autre facteur contribuant à l’expérience utilisateur et peut empêcher les acheteurs de continuer sur le chemin 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 mise en page inattendus.

Vous avez connu ces cas : vous êtes sur le point de toucher un lien ou une image de produit, mais juste avant de toucher l’écran, la page se déplace, et BAM, vous cliquez sur quelque chose d’autre involontairement. Dans le meilleur des cas, ces situations sont un léger désagrément, mais dans le pire des cas, vous envoyez des acheteurs à la recherche d’une expérience plus fluide et moins pernicieuse sur le Web.

Google calcule ces mouvements de page en multipliant la fraction d’impact, ou la quantité de contenu visible déplacé dans la fenêtre d’affichage, par la fraction de distance , ou la distance qu’un élément instable a déplacée dans le cadre divisée 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 pendant qu’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 CLS médiocre, c’est probablement dû à l’un des facteurs suivants:

  1. Une image ou une vidéo se redimensionnant 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 éléments suivants :

  1. Incluez les dimensions exactes de vos images et éléments vidéo.
  2. Évitez les publicités contextuelles ou les bannières. Au lieu de cela, réservez statiquement un grand espace pour l’emplacement publicitaire.
  3. Évitez les flashs de texte sans style ou invisible (FOIT/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 mesure Core Web Vitals

Les sites Web de commerce électronique volumineux et complexes avec des millions de pages, 1000s de SKU, des tests A / B et la personnalisation, des prix dynamiques et des recherches d’inventaire en temps réel peuvent atteindre des vitesses inférieures à la seconde avec Layer0. En fait, Layer0 est la seule plateforme sur le marché à garantir des LCP médians inférieurs à 500 ms.

Sur Layer0, le contenu s’affiche instantanément, ou peint, sur une page et devient immédiatement accessible grâce à notre CDN configurable en JavaScript et sensible aux applications appelé CDN-as-JavaScript. Il utilise le préchargement prédictif avancé et l’informatique de bord pour diffuser du contenu dynamique (JSON/SSR/HTML) depuis le bord 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 en tout temps.

Les sites Web sur Layer0 ont un taux de réussite de cache de 95 % pour les données HTML et JSON à la périphérie, tandis que les sites sur les CDN traditionnels sont en 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 tenez compte de la première impression de vitesse, d’interactivité et de stabilité visuelle de l’utilisateur en mesurant la plus grande peinture Contentful, 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écuter 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 page Experience 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 page Experience de Google introduit des signaux dérivés de Core Web Vitals (CWV) dans l’algorithme de classement officiel. Core Web Vitals sont 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 se classent moins bien qu’ils ne le font actuellement au début de 2021.