Introduction
Depuis son introduction en mai 2020, la suite Core Web Vitals (CWVS) de Google est devenue une mesure importante pour mesurer les performances des sites Web. Étant donné que Google considère ces valeurs comme faisant partie de son algorithme de classement de page, maximiser les performances de votre site Web en termes de CWV améliore non seulement l’expérience de vos utilisateurs, mais améliore également votre classement dans les moteurs de recherche. Cet article explorera des conseils et des techniques pour vous aider à améliorer vos scores de page, augmenter la satisfaction des utilisateurs et augmenter vos résultats.
Qu’est-ce que Core Web Vitals ?
Comme tant d’autres choses dans la technologie, les Web Vitals de Google sont un essaim d’acronymes à trois lettres, chacun représentant un aspect mesurable de la performance d’un site Web. Pour définir la scène, définissons les trois indicateurs clés qui définissent les principaux éléments vitaux Web :
Peinture de plus grande qualité
LCP (Greatest Contentful Paint) : mesure la vitesse de chargement perçue en se concentrant sur le temps nécessaire au contenu visible au-dessus du pli pour se charger. Pour offrir une expérience utilisateur idéale, LCP doit être déclenché dans les 2,5 secondes dans la chronologie de chargement de la page.
Délai de la première entrée
Délai de première entrée (FID) : mesure la réactivité de la page en mesurant le délai entre les actions de l’utilisateur et la réponse de la page. Pour offrir une expérience utilisateur idéale, les pages doivent avoir un FID de 100 millisecondes ou moins.
Décalage de mise en page cumulé
Décalage de mise en page cumulatif (CLS) : mesure la stabilité visuelle à l’aide d’une mesure composite des décalages de mise en page sur la page lors du rendu. Pour offrir une expérience utilisateur idéale, les pages doivent conserver un CLS de 0,1 ou moins ; tout ce qui se trouve entre 0,1 et 0,25 est considéré comme modéré et supérieur à 0,25 est médiocre.
… et pourquoi sont-ils importants?
Pour de nombreuses entreprises, la performance du site Web a une corrélation directe avec le succès de l’entreprise. La recherche indique que les sites Web avec des scores CWV réussis peuvent bénéficier jusqu’à 37% de visibilité en plus dans les résultats de recherche par rapport aux pages qui n’en ont pas (Beus) ; et que l’amélioration des scores CWV peut augmenter à la fois le revenu par visiteur ainsi que le taux de conversion (Duong et al.).
Lors de l’utilisation de Akira, Une boutique de mode féminine, Edgio a pu améliorer les CWV du site Web, portant les temps de chargement de la première page de 5 secondes à ~1 seconde, améliorant les mesures CWV et offrant finalement une augmentation de +30% du trafic organique, une amélioration de +61% des initiations de caisse et une augmentation de 37% du taux de conversion.
En termes simples, les sites Web plus rapides permettent de meilleurs classements SEO et des utilisateurs plus heureux – en particulier dans le contexte des sites Web de commerce électronique ; ces derniers se combinent pour diminuer les taux de rebond et augmenter les conversions.
Alors, comment pouvons-nous les améliorer?
Délai de la première entrée
Commençons par le fruit facile à accrocher : premier délai d’entrée. La bonne nouvelle est que les sites Web ont des scores FID plus souvent qu’autrement, ce qui est génial à voir! Si, cependant, ce n’est pas le cas, souvent, le coupable est les scripts tiers chargés tôt dans le cycle de vie du site Web, qui peuvent bloquer l’exécution du thread principal nécessaire pour recevoir les entrées de l’utilisateur. Les outils qui capturent les erreurs et effectuent l’enregistrement d’écran sont des candidats de choix pour un examen plus approfondi.
En fait, tout ce qui bloque le thread d’exécution principal peut contribuer à de mauvaises performances du FID. Gardez un œil attentif sur les tâches JavaScript gourmandes en ressources ou de longue durée, et envisagez de refactoriser le code non lié à l’interface utilisateur vers un Web worker, ainsi que d’utiliser des techniques de lazy-loading et de fractionnement du code pour vous assurer que seul le JavaScript requis est chargé et seulement quand il est nécessaire.
En outre, bien que techniquement pas un élément central des CWV, il convient de mentionner une autre métrique connexe : interaction to Next Paint (INP). INP mesure le temps écoulé entre l’interaction avec une page et la mise à jour de page suivante reflétant cette interaction. Alors que INP et FID mesurent tous deux la réactivité globale de la page, INP se préoccupe de toutes les interactions de la page plutôt que de la première interaction, visant à s’assurer que la page reste réactive tout au long de la session, et pas seulement des interactions initiales. INP suit les pires performances d’interaction dans l’expérience d’un utilisateur et le signale à Crux. Il est très probable que bientôt INP remplacera FID comme mesure de la réactivité de la page, il vaut donc la peine de garder un œil sur.
Peinture de plus grande qualité
Sans doute la mesure la plus importante et la plus impactante pour les performances de page est LCP. De façon assez prévisible, l’exemple le plus courant de Greatest Contentful Paint est une image « héros » – une grande image ou vidéo, qui occupe généralement toute la largeur de la fenêtre d’affichage au-dessus du « pli ». Bien que les techniques d’optimisation de cet élément soient les mêmes que n’importe quelle autre ressource de page, le temps qu’il faut pour que cette ressource s’affiche est d’une importance capitale car c’est le premier élément principal qu’un utilisateur expérimentera.
En attente dans la file d’attente
Décomposer le timing de la requête pour l’élément LCP est extrêmement utile pour optimiser ses performances. Toute demande effectuée par un navigateur commence par la file d’attente. Chaque milliseconde de requêtes LCP passées dans la file d’attente est une milliseconde qui contribuera au score LCP, donc si vous constatez que ces éléments passent un temps disproportionné à traîner dans la file d’attente du navigateur, étudiez ce qui est demandé avant et pourquoi, et prenez des mesures pour prioriser les ressources LCP. Peut-être que les ressources sont en dessous du pli, ou d’autres scripts qui peuvent être chargés en pazy ou autrement différés. L’ordre des opérations est essentiel.
En attente sur le serveur
Après avoir lancé la requête réseau, le client navigateur doit attendre que le serveur reçoive, traite et réponde à cette requête. Cette métrique est appelée Time-to-first-byte (TTFB). Si le serveur est lent à répondre à la requête, votre score LCP en souffrira. Il s’agit de l’un des domaines où le fait d’avoir un CDN peut avoir un impact significatif sur l’amélioration de la vitesse, car les CDN peuvent conserver une copie en cache de la ressource dans un emplacement géographiquement proche de vos utilisateurs finaux et répondre avec cette ressource plus rapidement qu’avec un seul serveur d’applications. D’autres aspects importants de l’utilisation d’un CDN incluent les WAF de sécurité intégrés et la capacité de répondre à des pics de trafic importants. Si vous optez pour la vitesse, vous devriez utiliser un CDN.
Large sur le fil
À ce stade, espérons-le, le navigateur demandera les ressources LCP au début du cycle de vie de la page, et le serveur devrait y répondre rapidement. L’élément suivant à considérer est la taille globale de la ressource demandée. Chaque octet qui doit voyager « sur le fil » vers le navigateur prendra un certain temps, et plus il y aura de ces octets, plus il faudra de temps pour que la requête se termine. Il faut donc veiller à ce que les ressources soient aussi petites que raisonnablement possible afin de réduire au minimum le temps consacré à leur transfert. Cela peut inclure l’utilisation d’optimisation d’image tierces parties et de services d’hébergement tels que kraken.io ou imgix.com, qui peuvent à la fois optimiser et servir des fichiers multimédias dans des formats « NextGen » tels que WebP, réduisant encore la taille.
Aidez le navigateur à sortir
En plus des optimisations de taille, envisagez d’utiliser <>des balises d’image, qui permettront au navigateur de choisir la bonne ressource à demander pour l’appareil de manière plus intelligente. Un navigateur de bureau peut avoir de larges pans d’écran pour afficher des images de résolution supérieure ; cependant, ces mêmes ressources encombreront un appareil mobile avec un écran plus petit. En utilisant des ressources optimisées et des requêtes multimédia CSS, vous pouvez vous assurer que le navigateur demande la bonne ressource pour son type de périphérique et réduire le temps passé à transférer des octets du serveur au client.
De plus, vous pouvez donner un coup de main au navigateur en lui demandant de précharger les ressources LCP et en spécifiant une priorité de récupération. Ceux-ci donneront au navigateur des indices pour prioriser les ressources clés avant les ressources moins critiques. Plus vite les choses arrivent dans le navigateur, plus vite elles peuvent être rendues, et plus vite le LCP se produit, mieux c’est.
Décalage de mise en page cumulé
Nous le voyons tout le temps. Après avoir envoyé votre navigateur pour aller chercher un site Web, la page commence à se charger ; pendant que la page se construit, vous voyez la pièce qui vous intéresse et vous déplacez pour cliquer dessus lorsque soudainement toute la page change et le lien que vous pensiez que vous étiez sur le point de cliquer est soudainement ailleurs! Ce phénomène est appelé décalage de disposition. C’est ennuyeux pour tout le monde, généralement auto-infligé, et nous devrions nous efforcer de le minimiser pour le bien de l’humanité.
Les suspects habituels
Les coupables typiques des scores CLS plus élevés sont :
- Barres de coupe collantes
- Bannières promo ou « héros » chargées et rendues côté client
- Bulletins d’information, coupons et avis GPDR
- Autres intégrations tierces parties qui sont injectées dynamiquement dans la page
Définissez quelques limites
Vous souvenez-vous de l'<>élément d’image que nous avons référencé lors de la discussion LCP ? N’oubliez pas d’ajouter des cotes aux différents éléments qu’il contient. Omettre ces valeurs vous fait sortir du siège du conducteur lorsque vous dirigez le navigateur sur la façon de rendre ces éléments. En définissant les dimensions, le navigateur peut mettre de côté la quantité correcte d’espace dans lequel l’image sera peinte, réduisant ainsi le décalage.
Il en va de même pour tout contenu qui pourrait être ajouté dynamiquement à la page. Les publicités, <iframe> ou tout autre contenu ajouté dynamiquement peuvent contribuer à CLS. Le contenu de la page changera moins en réservant de l’espace pour ces éléments à l’avance. Évitez également d’ajouter le contenu au-dessus du contenu de la page existante, car cela provoquerait le décalage de la page entière en dessous.
Aider le navigateur à découper l’espace à l’avance réduira le CLS mais peut se faire au détriment de l’expérience utilisateur globale car l’utilisateur attend que ces parties de la page autrement vierge soient remplies de contenu utile. En tant que terrain d’entente, la mise en œuvre de squelettes de chargement d’éléments peut être une technique utile pour communiquer à l’utilisateur qu’il y a plus à venir, donnant l’impression d’une expérience plus rapide pendant que le navigateur fait le reste du travail lourd pour coordonner le contenu de la page supplémentaire. De plus, celles-ci peuvent et doivent être implémentées en utilisant des animations CSS plutôt que des GIF animés, ce qui signifie que seules quelques lignes de CSS peuvent être utilisées pour implémenter cette technique sur l’ensemble de votre site Web.
Conclusion
À première vue, Core Web Vitas peut sembler être les dernières pièces de l’algorithme légendaire et ombragé de Google pour déterminer le rang de page dans leurs résultats de recherche – et dans une certaine mesure, cela pourrait être correct. Cependant, plus que cela, les Core Web Vitals représentent un cadre plus concret pour mesurer les performances des pages et établir une base de référence pour décrire les choses importantes en termes d’expérience utilisateur. Bien que non exhaustives, les techniques mentionnées ci-dessus devraient vous aider à vous donner une longueur d’avance lors du dépannage et de l’optimisation des performances de votre site Web, ce qui, espérons-le, entraînera des améliorations dans l’expérience utilisateur, le classement des pages et les revenus.
