Amélioration de Core Web Vitals, une étude de cas Smashing Magazine

"Pourquoi mes Core Web Vitals échouent-ils ?" De nombreux développeurs se sont posé cette question ces derniers temps. Parfois, il est assez facile de trouver la réponse à cette question et le site a juste besoin d' investir dans la performance . Parfois cependant, c'est un peu plus délicat et, bien que vous pensiez que votre site était excellent en termes de performances pour une raison quelconque, il échoue toujours. C'est ce qui est arrivé à notre propre smashingmagazine.com et comprendre et résoudre le problème a pris un peu de temps.

Un appel à l'aide

Tout a commencé par une série de tweets en mars dernier avec un appel à l'aide :

Eh bien, cela a piqué ma curiosité ! Je suis un grand fan de Smashing Magazine et je suis très intéressé par les performances Web et les Core Web Vitals. J'ai déjà écrit quelques articles ici sur Core Web Vitals et je suis toujours intéressé de voir ce qu'il y a dans leur liste de contrôle annuelle des performances Web. Ainsi, Smashing Magazine connaît les performances Web, et s'ils éprouvaient des difficultés, cela pourrait être un cas de test intéressant à examiner !

Quelques-uns d'entre nous ont fait des suggestions sur ce fil de discussion quant à la nature du problème après avoir utilisé certains de nos outils d'analyse de performances Web préférés tels que WebPageTest ou PageSpeed ​​Insights.

Enquêter sur le problème LCP

Le problème était que LCP était trop lent sur mobile. LCP, ou Largest Contentful Paint, est l'un des trois Core Web Vitals que vous devez "passer" pour obtenir le meilleur classement de recherche de Google dans le cadre de leur mise à jour de l'expérience de page. Comme son nom l'indique, LCP vise à mesurer le moment où le plus grand contenu de la page est dessiné (ou "peint") à l'écran. Il s'agit souvent de l'image du héros ou du texte du titre. Il est destiné à mesurer ce que le visiteur du site est probablement venu voir ici.

Les métriques précédentes mesuraient les variations de la première peinture à l'écran (il s'agissait souvent d'un en-tête ou d'une couleur d'arrière-plan) ; contenu accessoire qui n'est pas vraiment ce que l'utilisateur souhaite réellement retirer de la page. Le contenu le plus volumineux est souvent un bon indicateur ou ce qui est le plus important. Et la partie « contenu » du nom indique que cette métrique est destinée à être ignorée (par exemple, les couleurs d'arrière-plan) ; ils peuvent être le contenu le plus volumineux, mais ils ne sont pas "contenus", donc ne comptent pas pour LCP et à la place l'algorithme essaie de trouver quelque chose de mieux.

LCP ne regarde que la fenêtre d'affichage initiale. Dès que vous faites défiler vers le bas ou que vous interagissez avec la page, l'élément LCP est fixe et nous pouvons calculer le temps qu'il a fallu pour dessiner cet élément à partir du moment où la page a commencé à se charger - et c'est votre LCP !

Il existe de nombreuses façons de mesurer vos Core Web Vitals, mais la manière définitive - même si ce n'est pas la meilleure, comme nous le verrons bientôt - est dans Google Search Console (GSC). Du point de vue du référencement, peu importe ce que les autres outils vous disent, GSC est ce que voit Google Search. Bien sûr, l'expérience de vos utilisateurs est plus importante que ce que voit un robot d'exploration de moteur de recherche, mais l'un des grands avantages de l'initiative Core Web Vitals est qu'elle mesure l'expérience utilisateur réelle plutôt que ce que voit Google Bot ! Donc, si GSC dit que vous avez de mauvaises expériences, alors vous avez de mauvaises expériences selon vos utilisateurs .

Search Console a déclaré à Smashing Magazine que leur LCP sur mobile pour la plupart de leurs pages devait être améliorée. Une sortie assez standard de cette partie de GSC et assez facile à traiter : faites simplement en sorte que votre élément LCP dessine plus rapidement ! Cela ne devrait pas prendre trop de temps. Certainement pas six mois (du moins le pensions-nous). Donc, la première étape consiste à découvrir ce qu'est l'élément LCP.

L'exécution d'une page d'article défaillante via WebPageTest a mis en évidence l'élément LCP :

Amélioration de l'image LCP

OK, donc la photo de l'auteur de l'article est l'élément LCP. Le premier réflexe est de se demander ce que nous pourrions faire pour accélérer cela ? Cela implique de plonger dans les cascades, de voir quand l'image est demandée, combien de temps il faut pour le télécharger, puis de décider comment optimiser cela. Ici, l'image a été bien optimisée en termes de taille et de format (généralement la première option, et la plus simple, pour améliorer les performances des images !). L'image était servie à partir d' un domaine d'actifs distinct (souvent mauvais pour les performances), mais il n'allait pas être possible de changer cela à court terme, et Smashing Magazine avait déjà ajouté un indice de ressource de preconnect pour accélérer cela au mieux. pouvait.

Comme je l'ai déjà mentionné, Smashing Magazine connaît les performances Web, n'avait travaillé que récemment sur l'amélioration de leurs performances et avait tout fait ici, mais échouait toujours. Intéressant…

D'autres suggestions ont été apportées, notamment la réduction de la charge, le retardement du service worker (pour éviter les conflits) ou l'examen des priorités HTTP/2, mais elles n'ont pas eu l'impact nécessaire sur la synchronisation LCP. Nous avons donc dû chercher dans notre boîte à outils de performances Web tous les trucs et astuces pour voir ce que nous pouvions faire d'autre ici.

Si une ressource est essentielle au chargement de la page, vous pouvez l'intégrer afin qu'elle soit incluse dans le code HTML lui-même. De cette façon, la page comprend tout le nécessaire pour faire la peinture initiale sans délai. Par exemple, Smashing Magazine intègre déjà le CSS critique pour permettre une première peinture rapide, mais n'intègre pas l'image de l'auteur. L'inlining est une épée à double tranchant et doit être utilisé avec prudence. Cela renforce la page et signifie que les pages vues ultérieurement ne bénéficient pas du fait que les données sont déjà téléchargées. Je ne suis pas fan de l'over-inlining à cause de cela et je pense qu'il doit être utilisé avec prudence.

Donc, il n'est normalement pas recommandé d'insérer des images. Cependant, ici, l'image nous posait de réels problèmes, était raisonnablement petite et était directement liée à la page. Oui, si vous lisez beaucoup d'articles de cet auteur, c'est un gaspillage de retélécharger la même image plusieurs fois au lieu de télécharger l'image de l'auteur une fois et de la réutiliser, mais selon toute vraisemblance, vous êtes ici pour lire différents articles par différents auteurs .

Il y a eu quelques avancées dans les formats d'image récemment, mais AVIF fait sensation car il est déjà là (au moins dans Chrome et Firefox), et il a des résultats de compression impressionnants par rapport aux anciens formats JPEG traditionnellement utilisés pour les photographies. Vitaly ne voulait pas intégrer la version JPEG des images de l'auteur, mais a cherché à savoir si l'intégration de la version AVIF fonctionnerait. Compresser l'image de l'auteur à l'aide d'AVIF, puis base64 l'image dans le HTML a entraîné une augmentation de 3 Ko du poids de la page HTML - ce qui est minuscule et donc acceptable.

Étant donné qu'AVIF n'était pris en charge que dans Chrome à l'époque (il est venu à Firefox après tout cela), et puisque Core Web Vitals est une initiative de Google, l'optimisation pour un navigateur Google a semblé légèrement "dérangeante" à cause d'un édit de Google. Chrome est souvent à l'avant-garde de la prise en charge de nouvelles fonctionnalités et cela mérite d'être félicité, mais il se sent toujours un peu décalé lorsque ces deux aspects de son activité se touchent. Pourtant, il s'agissait d'un nouveau format d'image standard plutôt que d'un format propriétaire réservé à Chrome (même s'il n'était initialement pris en charge que dans Chrome), et constituait une amélioration progressive des performances (les utilisateurs de Safari obtiennent toujours le même contenu, mais pas aussi rapidement ), donc avec l'ajout de la torsion AVIF, Smashing a pris la suggestion et aligné l'image et a effectivement vu des résultats impressionnants dans les outils de laboratoire. Problème résolu!

Un LCP alternatif

Donc, nous avons laissé ce lit et attendu les 28 jours habituels environ pour que les chiffres de Core Web Vitals deviennent tous verts… mais ils ne l'ont pas fait. Ils oscillaient entre le vert et l'orange, donc nous avions certainement amélioré les choses, mais n'avions pas complètement résolu le problème. Après être resté longtemps dans la section ambre "à améliorer", Vitaly a demandé s'il y avait d'autres idées.

L'image se dessinait rapidement. Pas tout à fait instantanément (il faut encore du temps pour traiter une image après tout) mais aussi près que possible. Pour être honnête, j'étais à court d'idées mais j'ai jeté un autre coup d'œil avec des yeux neufs. Et puis une autre idée m'a frappé : optimisions-nous le bon élément LCP ? Les auteurs sont importants bien sûr, mais est-ce vraiment ce que le lecteur est venu voir ici ? Même si nos ego aimeraient dire oui, et que nos belles tasses brillantes sont bien plus importantes que le contenu que nous écrivons, les lecteurs ne pensent probablement pas cela (lecteurs, hein - que pouvez-vous faire !).

Le lecteur est venu chercher l'article, pas l'auteur. L'élément LCP doit donc refléter cela, ce qui pourrait également résoudre le problème de dessin d'image LCP. Pour ce faire, nous avons simplement placé le titre au-dessus de l'image de l'auteur et augmenté un peu la taille de la police sur mobile. Cela peut sembler une astuce sournoise pour tromper les dieux du référencement Core Web Vital aux dépens des utilisateurs, mais dans ce cas, cela aide les deux ! Bien que de nombreux sites essaient d'opter pour le piratage rapide et facile ou d'optimiser GoogleBot par rapport aux utilisateurs réels, ce n'était pas le cas et nous étions assez à l'aise avec la décision ici. En fait, d'autres ajustements suppriment complètement l'image de l'auteur sur la vue mobile, où l'espace est limité et cet article ressemble actuellement à ceci sur mobile, avec l'élément LCP en surbrillance :

Ici, nous montrons le titre, les informations clés sur l'article et le début du résumé - bien plus utile à l'utilisateur, que de prendre tout le précieux espace de l'écran mobile avec une grande photo !

Et c'est l'une des principales choses que j'aime dans les Core Web Vitals : ils mesurent l'expérience utilisateur.

Pour améliorer les métriques, vous devez améliorer l'expérience.

"

Et MAINTENANT, nous avions enfin terminé. Le texte s'affiche beaucoup plus rapidement que les images, ce qui devrait résoudre le problème LCP. Merci beaucoup à tous et bonne nuit !

Je déteste ce graphique CWV dans Google Search Console…

Encore une fois, nous avons été déçus. Cela n'a pas résolu le problème et il n'a pas fallu longtemps avant que le graphique de la Google Search Console ne redevienne orange :

À ce stade, nous devrions parler un peu plus des regroupements de pages et des Core Web Vitals. Vous avez peut-être remarqué sur le graphique ci-dessus que pratiquement tout le graphique oscille en même temps. Mais il y avait aussi un groupe central d'environ 1 000 pages qui restaient vertes la plupart du temps. Pourquoi donc?

Eh bien, Google Search Console catégorise les pages en groupes de pages et mesure les métriques Core Web Vitals de ces groupes de pages. Il s'agit d'une tentative de remplir les données manquantes pour les pages qui n'obtiennent pas suffisamment de trafic pour avoir des données d'expérience utilisateur significatives. Il y a un certain nombre de façons dont ils auraient pu s'attaquer à ce problème : ils n'auraient tout simplement pas donné d'amélioration au classement de ces pages, ou peut-être ont-ils supposé le meilleur et donné une impulsion complète aux pages sans aucune donnée. Ou ils auraient pu se rabattre sur les données vitales Web de base au niveau de l'origine. Au lieu de cela, ils ont essayé de faire quelque chose de plus intelligent, qui était une tentative d'être utile, mais qui est à bien des égards aussi plus déroutant : les regroupements de pages .

Fondamentalement, chaque page se voit attribuer un groupe de pages. La manière dont ils procèdent n'est pas claire, mais les URL et les technologies utilisées sur la page ont déjà été mentionnées. Vous ne pouvez pas non plus voir quels groupes Google a choisis pour chacune de vos pages, et si leur algorithme a bien fonctionné, ce qui est une autre chose frustrante pour les propriétaires de sites Web, bien qu'ils donnent des exemples d'URL pour chaque score Core Web Vitals différent sous le graphique. dans Google Search Console à partir de laquelle le regroupement peut parfois être implicite.

Les regroupements de pages peuvent bien fonctionner pour des sites comme Smashing Magazine. Pour d'autres sites, les regroupements de pages peuvent être moins clairs et de nombreux sites peuvent n'avoir qu'un seul regroupement. Le site Smashing, cependant, a plusieurs types de pages différents : articles, pages d'auteurs, guides, etc. Si une page d'article est lente parce que l'image de l'auteur est l'image LCP est lente à charger, cela sera probablement le cas pour toutes les pages d'article. Et le correctif sera probablement le même pour toutes les pages d'articles. Il est donc logique de les regrouper (en supposant que Google puisse déterminer avec précision les regroupements de pages).

Cependant, là où cela peut devenir déroutant, c'est lorsqu'une page reçoit suffisamment de visiteurs pour obtenir son propre score Core Web Vitals et qu'elle réussit, mais qu'elle est regroupée avec un groupe défaillant. Vous pouvez appeler l'API CrUX pour toutes les pages de votre site, voir que la plupart d'entre elles passent, puis être confus lorsque ces mêmes pages s'affichent comme défaillantes dans la Search Console, car elles ont été regroupées dans un groupe avec des URL défaillantes et la plupart des le trafic pour ce groupe est en échec. Je me demande toujours si la Search Console devrait utiliser les données Core Web Vital au niveau de la page, plutôt que de toujours utiliser les données de regroupement.

Quoi qu'il en soit, cela explique les grandes fluctuations. Fondamentalement, tous les articles (dont il y en a environ 3 000) semblent être dans le même groupement de pages (pas sans raison !) et ce groupement de pages est soit réussi, soit échoué. Lorsqu'il bascule, le graphique se déplace de façon spectaculaire .

Vous pouvez également obtenir des données plus détaillées sur les Core Web Vitals via l'API CrUX. Ceci est disponible au niveau de l'origine (c'est-à-dire pour l'ensemble du site) ou pour des URL individuelles (où suffisamment de données existent), mais malheureusement pas au niveau du groupement de pages. J'avais suivi le LCP au niveau de l'origine à l'aide de l'API CrUX pour obtenir une mesure plus précise du LCP et cela montrait également une histoire déprimante :

Nous pouvons voir que nous n'avons jamais vraiment « résolu » le problème et que le nombre de pages « bonnes » (la ligne verte ci-dessus) était encore trop proche du taux de réussite de 75 %. De plus, le score LCP p75 (la ligne pointillée qui utilise l'axe de droite) ne s'est jamais vraiment éloigné suffisamment du seuil de 2500 millisecondes. Il n'était pas étonnant que les pages qui passaient et passaient tournaient d'avant en arrière. Une mauvaise journée, avec quelques chargements de page plus lents, a suffi à faire basculer l'ensemble des pages regroupées dans la catégorie "besoin d'amélioration". Nous avions besoin de quelque chose de plus pour nous donner une certaine marge de manœuvre pour pouvoir absorber ces « mauvais jours ».

À ce stade, il était tentant d'optimiser davantage . Nous savons que le titre de l'article était l'élément LCP, alors que pourrions-nous faire pour améliorer encore cela ? Eh bien, il utilise une police, et les polices ont toujours été un fléau pour les performances Web, nous pourrions donc nous pencher là-dessus.

Mais attendez une minute. Smashing Magazine ÉTAIT un site rapide. L'exécuter via des outils de performance Web tels que Lighthouse et WebPageTest l'a montré, même sur des vitesses de réseau plus lentes. Et il faisait tout bien ! Il a été construit comme un générateur de site statique et n'a donc pas nécessité de génération côté serveur, il a tout intégré pour la peinture initiale afin qu'il n'y ait pas de contraintes de chargement de ressources autres que le HTML lui-même, il était hébergé par Netlify sur un CDN donc doit être proche de ses utilisateurs.

Bien sûr, nous pourrions envisager de supprimer la police, mais si Smashing Magazine ne pouvait pas offrir une expérience rapide compte tenu de tout cela, alors comment quelqu'un d'autre pourrait-il le faire ? Passer Core Web Vitals ne devrait pas être impossible, ni vous obliger à être uniquement sur un site simple sans polices ni images. Quelque chose d'autre se passait ici et il était temps d'en savoir un peu plus sur ce qui se passait au lieu de simplement tenter aveuglément une autre série d'optimisations.

Creuser un peu plus profondément dans les métriques

Smashing Magazine n'avait pas de solution RUM, nous avons donc plutôt fouillé dans les données du rapport d'expérience utilisateur Chrome (CrUX) que Google collecte pour les quelque 8 millions de sites Web les plus importants, puis rend ces données disponibles pour interroger sous diverses formes. Ce sont ces données CrUX qui alimentent les données de la console de recherche Google et, en fin de compte, l'impact sur le classement. Nous avions déjà utilisé l'API CrUX ci-dessus, mais avons décidé de nous plonger dans d'autres ressources CrUX.

Nous avons utilisé le plan du site et un script Google Sheets pour examiner toutes les données CrUX pour l'ensemble du site où elles étaient disponibles (Fabian Krumbholz a depuis créé un outil beaucoup plus complet pour faciliter cela !) et cela a montré des résultats mitigés pour les pages . Certaines pages réussissaient, tandis que d'autres, en particulier des pages plus anciennes, échouaient.

Le tableau de bord CrUX ne nous a pas vraiment dit grand-chose que nous ne savions pas déjà dans ce cas : le LCP était à la limite, et malheureusement pas à la baisse :

Creuser dans les autres statistiques (TTFB, First Paint, Online, DOMContentLoaded) ne nous a donné aucune indication. Il y a cependant eu une augmentation notable de l'utilisation du mobile :

Cela faisait-il partie d'une tendance générale à l'adoption du mobile ? Cela pourrait-il être ce qui affectait le LCP mobile malgré les améliorations que nous avions apportées ? Nous avions des questions mais pas de réponses ni de solutions.

Une chose que je voulais examiner était la répartition mondiale du trafic. Nous avions remarqué dans Google Analytics beaucoup de trafic en provenance d'Inde vers d'anciens articles. Cela pourrait-il être un problème ?

La connexion indienne

Les données CrUX au niveau national ne sont pas disponibles dans le tableau de bord CrUX, mais sont disponibles dans l'ensemble de données BigQuery CrUX, et l'exécution d'une requête au niveau de l'origine www.smashingmagazine.com montre une grande disparité dans les valeurs LCP (le SQL est inclus sur le deuxième onglet de ce lien au cas où vous voudriez essayer la même chose sur votre propre domaine). Sur la base des 10 premiers pays de Google Analytics, nous avons les données suivantes :

Le trafic indien représente une grande proportion pour Smashing Magazine (16%) et il n'atteint pas l'objectif de LCP au niveau de l'origine. Cela pourrait être le problème et valait certainement la peine d'être approfondi . Il y avait aussi les données des Philippines et du Pakistan avec de très mauvais scores mais c'était une quantité de trafic relativement faible.

À ce stade, j'avais une idée de ce qui pourrait se passer ici, et une solution potentielle a donc demandé à Smashing Magazine d'installer la bibliothèque web-vitals pour collecter les données RUM et les renvoyer à Google Analytics pour analyse. Après quelques jours de collecte, nous avons utilisé le rapport Web Vitals pour nous donner beaucoup de données d'une manière que nous n'avions pas pu voir auparavant, en particulier la répartition au niveau des pays :

Et voilà. Tous les pays les plus performants dans les analyses ont obtenu de très bons scores LCP, sauf un : l'Inde. Smashing Magazine utilise Netlify qui est un CDN mondial et il a une présence à Mumbai, il devrait donc être aussi performant que d'autres pays, mais certains pays sont juste plus lents que d'autres (plus à ce sujet plus tard).

Cependant, le trafic mobile pour l'Inde était juste en dehors de la limite de 2500, et ce n'était que le deuxième pays le plus visité. Les bons scores des États-Unis auraient-ils dû suffire à compenser cela ? Eh bien, les deux graphiques ci-dessus montrent l'ordre des pays par trafic. Mais CrUX compte séparément le trafic mobile et de bureau (et tablette btw, mais personne ne semble jamais s'en soucier !). Que se passe-t-il si nous filtrons le trafic uniquement sur le trafic mobile ? Et un peu plus loin - juste le trafic Chrome mobile (puisque seul Chrome alimente CrUX et donc seul Chrome compte pour CWV) ? Eh bien, nous obtenons une image beaucoup plus intéressante:

L'Inde est en fait le premier visiteur Chrome mobile, de loin - presque le triple du deuxième visiteur le plus élevé (États-Unis) ! Les Philippines, avec leur mauvais score, se sont également hissées à la troisième place, et le Nigeria et le Pakistan, avec leurs mauvais scores, s'inscrivent également dans le top 10. Maintenant, les mauvais scores globaux du LCP sur mobile commençaient à avoir un sens.

Alors que le mobile a dépassé le bureau comme moyen le plus populaire d'accéder à Internet dans le soi-disant monde occidental , il existe toujours un juste mélange de mobile et de bureau ici - souvent lié à nos heures de travail où beaucoup d'entre nous sont assis dans devant un bureau. Le prochain milliard d'utilisateurs ne sera peut-être pas le même, et le mobile joue un rôle beaucoup plus important dans ces pays. Les statistiques ci-dessus montrent que cela est même vrai pour des sites comme Smashing Magazine qui, selon vous, obtiendraient plus de trafic de la part des concepteurs et des développeurs assis devant des ordinateurs de bureau lors de la conception et du développement !

De plus, comme CrUX ne mesure que les utilisateurs de Chrome , cela signifie que les pays avec plus d'iPhones (comme les États-Unis) auront une proportion beaucoup plus faible d'utilisateurs mobiles représentés dans CrUX et donc dans Core Web Vitals, ce qui amplifie encore l'effet de ces pays.

Les éléments vitaux Web de base sont mondiaux

Core Web Vitals n'a pas de seuil différent par pays, et peu importe si votre site est visité par différents pays - il enregistre simplement tous les utilisateurs de Chrome de la même manière. Google l'a déjà confirmé, donc Smashing Magazine n'obtiendra pas l'amélioration du classement pour les bons scores aux États-Unis, et ne l'obtiendra pas pour les utilisateurs indiens. Au lieu de cela, tous les utilisateurs entrent dans le creuset , et si le score de ces groupes de pages n'atteint pas le seuil, le signal de classement de tous les utilisateurs est affecté.

Malheureusement, le monde n'est pas un endroit égal. Et les performances Web varient énormément d'un pays à l'autre et montrent une nette fracture entre les pays riches et les pays pauvres. La technologie coûte de l'argent, et de nombreux pays se concentrent davantage sur la mise en ligne de leurs populations, plutôt que sur la mise à niveau continue des infrastructures vers les technologies les plus récentes et les plus performantes.

Le manque d'autres navigateurs (comme Firefox ou iPhone) dans CrUX a toujours été connu, mais nous l'avons toujours considéré comme un angle mort pour mesurer les performances de Firefox ou de l'iPhone. Cet exemple montre que l' impact est beaucoup plus important , et pour les sites avec un trafic mondial, il fausse considérablement les résultats en faveur des utilisateurs de Chrome, ce qui signifie souvent des pays pauvres, ce qui signifie souvent une moins bonne connectivité.

Doit-on diviser Core Web Vitals par pays ?

D'une part, il semble injuste de maintenir les sites Web au même niveau si l'infrastructure varie autant. Pourquoi Smashing Magazine devrait-il être pénalisé ou tenu à un niveau plus élevé qu'un site Web similaire qui n'est lu que par des concepteurs et des développeurs du monde occidental ? Smashing Magazine devrait-il bloquer les utilisateurs indiens pour garder les Core Web Vitals heureux (je veux être très clair ici que cela n'a jamais été abordé dans la discussion, alors s'il vous plaît, prenez cela comme l'auteur qui fait le point et non comme un tour de passe-passe sur Smashing!).

D'un autre côté, "abandonner" certains pays en acceptant leur lenteur risque de les reléguer définitivement au niveau inférieur où se trouvent beaucoup d'entre eux. Ce n'est pas la faute du lecteur indien moyen de Smashing Magazine si leur infrastructure est plus lente et à bien des égards, ce sont les personnes qui méritent plus de mise en valeur et d'efforts, plutôt que moins !

Et ce n'est pas seulement un débat entre pays riches et pays pauvres. Prenons l'exemple d'un site Internet français qui s'adresse aux lecteurs en France, financé par la publicité ou les ventes depuis la France, et dispose d'un site Internet rapide dans ce pays. Cependant, si le site est lu par beaucoup de Canadiens français, mais souffre parce que l'entreprise n'utilise pas de CDN mondial, alors cette entreprise devrait-elle souffrir dans la recherche Google française parce qu'elle n'est pas aussi rapide pour ces utilisateurs canadiens ? L'entreprise devrait-elle être «tenue en otage» par la menace de Core Web Vitals et devoir investir dans le CDN mondial pour garder ces lecteurs canadiens, et ainsi Google heureux?

Eh bien, si une proportion suffisamment importante de vos téléspectateurs souffre, c'est exactement ce que l'initiative de Core Web Vital est censée révéler. Pourtant, c'est un dilemme moral intéressant qui est un effet secondaire de l'initiative Core Web Vitals liée à l'amélioration du classement SEO : l'argent change toujours les choses !

Une idée pourrait être de garder les mêmes limites, mais de les mesurer par pays . Le site français de recherche Google pourrait donner un coup de pouce au classement des utilisateurs en français (parce que ces utilisateurs réussissent CWV pour ce site), alors que Google Search Canada pourrait ne pas le faire (parce qu'ils échouent). Cela uniformiserait les règles du jeu et mesurerait les sites pour chaque pays, même si les objectifs sont les mêmes.

De même, Smashing Magazine pourrait bien se classer aux États-Unis et dans d'autres pays où ils passent, mais être classé par rapport à d'autres sites indiens (où le fait qu'ils soient dans le segment "besoin d'amélioration" pourrait en fait être encore meilleur que beaucoup de sites là-bas, en supposant ils subissent tous les mêmes contraintes de performance).

Malheureusement, je pense que cela aurait un effet négatif, certains pays étant à nouveau ignorés alors que les sites ne justifient l'investissement en performance Web que pour des pays plus lucratifs. De plus, comme cet exemple l'illustre déjà, les Core Web Vitals sont déjà suffisamment compliqués sans mettre en jeu près de 200 dimensions supplémentaires en en ayant une pour chaque pays du monde !

Alors, comment y remédier ?

Nous savions donc enfin pourquoi Smashing Magazine avait du mal à passer Core Web Vitals, mais que pouvait-on faire, le cas échéant? L'hébergeur (Netlify) possède déjà le CDN de Mumbai, qui devrait donc fournir un accès rapide aux utilisateurs indiens, alors était-ce un problème de Netlify pour améliorer cela ? Nous avions optimisé le site autant que possible, alors était-ce juste quelque chose avec lequel ils allaient devoir vivre ? Eh bien non, nous revenons maintenant à notre idée de tout à l'heure : optimiser un peu plus les polices Web .

Nous pourrions prendre l'option radicale de ne pas fournir de polices du tout. Ou peut-être ne pas livrer les polices à certains endroits (bien que ce soit plus compliqué, étant donné la nature SSG du site Web de Smashing Magazine). Alternativement, nous pourrions attendre et charger des polices dans le frontal, en fonction de certains critères, mais cela risquait de ralentir les polices pour d'autres pendant que nous évaluions ces critères. Si seulement il y avait un signal de navigateur facile à utiliser pour savoir quand nous devrions prendre cette mesure drastique. Quelque chose comme l'en-tête SaveData, qui est justement destiné à ça !

SaveData Et prefers-reduced-data

SaveData est un paramètre que les utilisateurs peuvent activer dans leur navigateur lorsqu'ils veulent vraiment… enregistrer des données. Cela peut être utile pour les personnes ayant des forfaits de données restreints, pour ceux qui voyagent avec des frais d'itinérance élevés ou pour ceux qui se trouvent dans des pays où l'infrastructure n'est pas aussi rapide que nous le souhaiterions.

Les utilisateurs peuvent activer ce paramètre dans les navigateurs qui le prennent en charge, puis les sites Web peuvent ensuite utiliser ces informations pour optimiser leurs sites encore plus que d'habitude. Peut-être renvoyer des images de qualité inférieure (ou désactiver complètement les images !), Ou ne pas utiliser de polices. Et la meilleure chose à propos de ce paramètre est que vous agissez à la demande de l'utilisateur et que vous ne prenez pas de décision arbitrairement pour lui (de nombreux utilisateurs indiens peuvent avoir un accès rapide et ne pas vouloir une version restreinte du site !).

Les informations sur les données de sauvegarde sont disponibles de deux manières (bientôt trois !) :

1. Un en-tête SaveData est envoyé sur chaque requête HTTP. Cela permet aux backends dynamiques de modifier le code HTML renvoyé.
2. L'API JavaScript NetworkInformation.saveData . Cela permet aux scripts frontaux de vérifier cela et d'agir en conséquence.
3. La prochaine requête multimédia prefers-reduced-data préférées, permettant au CSS de définir différentes options en fonction de ce paramètre. Ceci est disponible derrière un drapeau dans Chrome, mais pas encore activé par défaut pendant qu'il termine la normalisation.

La question est donc de savoir si de nombreux lecteurs de Smashing Magazine (et en particulier ceux des pays aux prises avec Core Web Vitals) utilisent cette option et est-ce quelque chose que nous pouvons donc utiliser pour leur proposer un site plus rapide ? Eh bien, lorsque nous avons ajouté le script web-vitals mentionné ci-dessus, nous avons également décidé de le mesurer, ainsi que le type de connexion efficace. Vous pouvez voir le script complet ici. Après un peu de temps, nous avons pu afficher les résultats dans un simple tableau de bord /Google Analytics, avec la version du navigateur Chrome :

Donc, la bonne nouvelle était qu'une grande partie des utilisateurs indiens mobiles (environ les deux tiers) avaient ce paramètre défini. L'ECT était moins utile, la plupart affichant 4g. J'ai déjà fait valoir que cette API est devenue de moins en moins utile car la plupart des utilisateurs sont classés sous ce paramètre 4g. De plus, l'utilisation efficace de cette valeur pour les chargements initiaux pose de nombreux problèmes.

Plus de bonnes nouvelles car la plupart des utilisateurs semblent être sur un Chrome à jour et bénéficieraient donc de nouvelles fonctionnalités telles que la requête multimédia prefers-reduced-data préférées lorsqu'elle sera entièrement disponible.

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

conclusion

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

Bonne optimisation !

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.