L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Améliorer les éléments essentiels du Web, une étude de cas fracassante pour un magazine
Chez Smashing, nous avons eu du mal avec le score ambre Core Web Vitals pendant un certain temps. Puis, après 6 mois, nous avons finalement réussi à le réparer. Voici une petite étude de cas sur la façon dont nous avons détecté et corrigé les goulots d'étranglement, et comment nous nous sommes retrouvés avec des scores verts, tout le chemin.
« Pourquoi mes éléments essentiels Web principaux échouent ? » De nombreux développeurs se sont récemment posé cette question. 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 recherche. 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 Web Performance Checklist annuelle. Ainsi, Smashing Magazine connaît les performances du Web, et s'ils ont des difficultés, cela pourrait être un cas de test intéressant à examiner ! de nos outils d'analyse des performances Web préférés, tels que WebPageTest ou PageSpeed Insights.
Enquête sur le problème LCP
Le problème était que LCP était trop lent sur mobile. LCP, ou Largest Contentful Paintest l'un des trois éléments essentiels du Web que vous devez « passer » pour obtenir l'amélioration complète du classement de la recherche de Google dans le cadre de leur Page Experience Update. Comme son nom l'indique, LCP vise à mesurer quand 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 susceptible de voir ici. accessoirement, un contenu qui n'est pas vraiment ce que l'utilisateur veut réellement faire sortir 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 montre que cette métrique est destinée à ignorer (par exemple, les couleurs d'arrière-plan); ils peuvent être le contenu le plus volumineux, mais ils ne sont pas « contenus », alors ne comptez pas pour le LCP et à la place, l'algorithme essaie de trouver quelque chose de mieux.
Le LCP ne regarde que la fenêtre d'affichage initiale. Dès que vous faites défiler vers le bas ou interagissez avec la page, l'élément LCP est corrigé et nous pouvons calculer combien de temps il a fallu pour dessiner cet élément à partir du début du chargement de la page – et c'est votre LCP !
Il existe de nombreuses façons de en mesurant vos Core Web Vitalsmais le moyen définitif – même si ce n'est pas le meilleur, 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 la recherche Google voit. Bien sûr, l'expérience de vos utilisateurs est plus importante que ce que voient certains robots de moteur de recherche, mais l'un des avantages de l'initiative Core Web Vitals est qu'elle mesure l'expérience utilisateur réelle plutôt que ce que Google Bot voit ! Ainsi, si GSC dit que vous avez de mauvaises expériences, alors vous avez de mauvaises expériences selon vos utilisateurs .
La Search Console a déclaré à Smashing Magazine que leur LCP sur mobile pour la plupart de leurs pages devait être amélioré. Une sortie assez standard de cette partie de GSC et assez facilement adressée : faites simplement en sorte que votre élément LCP se dessine plus rapidement ! Cela ne devrait pas prendre trop de temps. Certainement pas six mois (du moins c'est ce que nous pensions). Donc, tout d'abord, il faut 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 que pourrions-nous faire pour rendre cela plus rapide ? Cela implique d'explorer les cascades, de voir quand l'image est demandée, combien de temps il faut pour télécharger, puis de décider comment l'optimiser. Ici, l'image était bien optimisée en termes de taille et de format (généralement la première et la plus simple option pour améliorer les performances des images !). L'image a été 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 préconnexion indice de ressource pour accélérer cela du mieux qu'ils pouvaient.
Comme je l'ai mentionné précédemment, 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 échouaient toujours. Intéressant…
D'autres suggestions ont été introduites, notamment la réduction de la charge, le retard du service worker (pour éviter les conflits) ou l'enquête sur les priorités HTTP/2, mais elles n'ont pas eu l'impact nécessaire sur le timing LCP. Nous avons donc dû accéder à notre boîte à outils de performances Web pour tous les trucs et astuces pour voir ce que nous pourrions faire d'autre ici.
Si une ressource est essentielle au chargement de la page, vous pouvez l'intégrer, donc il est inclus dans le 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à des CSS critiques pour permettre une première peinture rapide, mais n'a pas intégré l'image de l'auteur. L'inline est une arme à double tranchant et doit être utilisée avec prudence. Cela renforce la page et signifie que les pages vues suivantes ne bénéficient pas du fait que les données sont déjà téléchargées. Je ne suis pas un fan de la sur-enligne à 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 causait 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 une perte 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 par rapport aux anciens formats JPEG traditionnellement utilisés pour les photographies. Vitality ne voulait pas incorporer la version JPEG des images de l'auteur, mais a cherché à savoir si l'incorporation de la version AVIF fonctionnerait. La compression de l'image de l'auteur à l'aide d'AVIF, puis la base64 de l'image dans le code HTML ont entraîné une augmentation de 3 Ko du poids de la page HTML – ce qui est minime et donc acceptable.
Étant donné qu'AVIF n'était pris en charge que dans Chrome à l'époque. (c'est arrivé à Firefox après tout cela), et puisque Core Web Vitals est une initiative de Google, cela semblait un peu "dégoûtant" d'optimiser pour un navigateur Google en raison d'un édit de Google. Chrome est souvent à l'avant-garde de la prise en charge de nouvelles fonctionnalités et c'est à féliciter, mais il se sent toujours un peu à l'écart lorsque ces deux aspects de son activité ont un impact l'un sur l'autre. Pourtant, il s'agissait d'un nouveau format d'image standard plutôt que d'un format propriétaire uniquement Chrome (même s'il n'était initialement pris en charge que dans Chrome), et il s'agissait d'une amélioration progressive des performances (les utilisateurs de Safari obtiennent toujours le même contenu , mais pas aussi rapide), donc avec l'ajout de la torsion AVIF, Smashing a pris la suggestion et a intégré l'image et a effectivement vu des résultats impressionnants dans les outils de laboratoire. Problème résolu !
Plus après le saut ! Continuez à lire ci-dessous ↓
Feature Panel" width="480" height="697″/>
]Un LCP alternatif
Alors, nous avons laissé ce lit entrer et avons attendu les 28 jours habituels environ pour que les numéros Core Web Vitals deviennent tous verts… mais ils ne l'ont pas fait. Ils oscillaient entre le vert et l'ambre, nous avions donc certainement amélioré les choses, mais nous n'avions pas complètement résolu le problème. Après être resté longtemps dans la section orange « besoin d'amélioration », 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 pris un autre regard avec des yeux neufs. Et puis une idée alternative m'a frappé – optimisions-nous l'élément LCP correct ? Les auteurs sont importants bien sûr, mais est-ce vraiment ce que le lecteur est venu voir ici ? les lecteurs ne pensent probablement pas ça (les lecteurs, hein — que pouvez-vous faire !).
Le lecteur est venu pour l'article, pas l'auteur. L'élément LCP devrait donc refléter cela, ce qui pourrait également résoudre le problème de dessin de l'image LCP. Pour ce faire, nous avons simplement mis le titre au-dessus de l'image de l'auteur et augmenté un peu la taille de la police sur mobile. Cela peut sembler être une astuce sournoise pour tromper les dieux de Core Web Vital SEO au détriment 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 optimiser pour GoogleBot par rapport à de vrais utilisateurs, 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 mis en évidence :
Ici, nous montrons le titre, les informations clés sur l'article et le début du résumé — bien plus utile pour l'utilisateur, que de prendre tout l'espace de l'écran mobile de précision avec une grande photo !
Et c'est l'un des les 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 avons enfin terminé. Le texte s'affiche beaucoup plus rapidement que les images, ce qui devrait résoudre le problème du LCP. Merci à tous et bonne nuit !
Je déteste ce graphique CWV dans la console de recherche Google…
Encore une fois, nous avons été déçus. Cela n'a pas résolu le problème et il n'a pas fallu longtemps pour que le graphique de la console de recherche Google redevienne orange :
À ce stade, nous devrions parler un peu plus des regroupements de pages et des Core Web Vitals. Vous avez peut-être remarqué à partir du graphique ci-dessus que pratiquement tout le graphique oscille à la fois. Mais il y avait aussi un noyau d'environ 1 000 pages qui restait vert la plupart du temps. Pourquoi ?
Eh bien, la console de recherche Google classe 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 ne reçoivent pas suffisamment de trafic pour avoir des données d'expérience utilisateur significatives. Ils auraient pu résoudre ce problème de plusieurs manières : ils n'auraient tout simplement pas pu améliorer le classement de ces pages, ou peut-être supposé le meilleur et donné un coup de pouce complet 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 également plus déroutant : Groupes de pages.
Fondamentalement, chaque page se voit attribuer un groupe de pages. Comment ils le font n'est pas clair, 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 regroupements Google a choisis pour chacune de vos pages, et si leur algorithme a raison, 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 la console de recherche Google à 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 : articles, pages d'auteur, guides, etc. Si une page d'article est lente parce que l'image de l'auteur est l'image LCP lente à charger, ce sera probablement le cas pour toutes les pages d'articles. Et le correctif sera probablement le même pour toutes les pages d'articles. Donc les regrouper là-bas est logique (en supposant que Google puisse déterminer avec précision les groupements de pages).
Cependant, là où cela peut devenir déroutant, c'est lorsqu'une page reçoit suffisamment de visiteurs pour obtenir son propre Core Web Vitals score et ça passe, mais c'est regroupé avec un groupe défaillant. Vous pouvez appeler l'API CrUX pour toutes les pages de votre site, voir la plupart d'entre elles passer, puis être confus lorsque ces mêmes pages s'affichent comme ayant échoué 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 pour l'échec. Je me demande toujours si la Search Console devrait utiliser les données Core Web Vital au niveau de la page quand c'est le cas, plutôt que d'utiliser toujours 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 groupe de pages (pas déraisonnablement !) et ce groupe 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 principaux 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 (lorsqu'il existe suffisamment de données), mais malheureusement pas au niveau du regroupement de pages. J'avais suivi le LCP au niveau d'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 « bonnes » pages (la ligne verte ci-dessus) était toujours 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 échouaient se retournaient d'avant en arrière. Une mauvaise journée, avec quelques chargements de pages plus lents, a suffi pour basculer le groupe de pages entier 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 l'améliorer encore ? Eh bien, il utilise une police, et les polices ont toujours été un fléau pour les performances Web, nous pourrions donc examiner cela.
Mais attendez une minute. Smashing Magazine ÉTAIT un site rapide. Son exécution via des outils de performances 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é conçu comme un générateur de site statique et ne nécessitait donc aucune génération côté serveur. devrait ê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 le pourrait-il ? Passer Core Web Vitals ne devrait pas être impossible, ni vous obliger à être uniquement sur un site simple sans polices ni images. Il y avait autre chose 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. Solution RUM, nous nous sommes donc plutôt penchés sur les données Chrome User Experience Report (CrUX) que Google collecte pour les 8 millions de sites Web les plus importants, puis nous les mettons à disposition pour des requêtes sous diverses formes. Ce sont ces données CrUX qui déterminent 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é d'explorer 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 depuis a créé un outil beaucoup plus complet pour rendre cela plus facile !) et il a montré des résultats mitigés pour les pages. Certaines pages passaient, tandis que d'autres, en particulier les pages plus anciennes, échouaient. malheureusement pas de tendance à la baisse :
L'exploration des autres statistiques (TTFB, First Paint, Online, DOMContentLoaded) ne nous a donné aucun indice. Il y a eu, cependant, une augmentation notable de l'utilisation du mobile :
Cela faisait-il partie d'une tendance générale à l'adoption du mobile ? Serait-ce 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 du pays ne sont pas disponibles dans le tableau de bord CrUX, mais L'ensemble de données BigQuery CrUX et l'exécution d'une requête au niveau d'origine www.smashingmagazine.com montre une grande disparité dans les valeurs LCP (le SQL est inclus dans le deuxième onglet de ce lien au cas où vous voudriez essayez la même chose sur votre propre domaine). Sur la base des 10 premiers pays dans Google Analytics, nous avons les données suivantes :
| Pays | Mobile p75 LCP value | % of traffic |
|---|---|---|
| États-Unis | 88,34% | 23% |
| Inde | 74,48 % | 16 % |
| Royaume-Uni | 92,07 % | 6 % |
| Canada | 93,75 % | 4% |
| Allemagne | 93,01 %[19659076]3% | |
| Philippines | 57,21 % | 3% |
| Australie | 85,88 % | 3% |
| France | 88,53 % | 2% |
| Pakistan | 56,32 % | 2% |
| Russie | 77,27 % | 2% |
Le trafic en Inde représente une grande proportion pour Smashing Magazine (16%) et il n'atteint pas l'objectif de LCP à un niveau d'origine. Cela pourrait être le problème et cela 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. 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 Web Vitals Report pour nous en dire plus sur les données d'une manière que nous n'avions pas pu voir auparavant, en particulier la répartition au niveau des pays :[19659109]Capture d'écran de la répartition par pays du rapport Web Vitals montrant les cinq principaux pays : États-Unis, Inde, Royaume-Uni, Canada et Allemagne. Tous les LCP, FID et CLS sont verts (et bien dans les "bonnes" plages) à l'exception de l'Inde qui est orange pour l'Inde à la fois pour le bureau (3 124 ms) et le mobile (2 552 ms) « />
Et voilà. Tous les meilleurs pays de l'analyse ont de très bons scores LCP, à l'exception d'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 (nous en parlerons plus tard). [19659008]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 américains auraient sûrement 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 la tablette d'ailleurs, mais personne ne semble jamais s'en soucier !). Que se passe-t-il si nous filtrer le trafic uniquement sur le trafic mobile ? Et un pas de plus : uniquement le trafic Chrome mobile (puisque seul Chrome alimente CrUX et que seul Chrome compte pour CWV) ? Eh bien, nous obtenons une image beaucoup plus intéressante :
| Pays | Mobile p75 LCP value | % of mobile traffic |
|---|---|---|
| Inde | 74,48% | 31% |
| États-Unis | 88,34 % | 13 % |
| Philippines | 57,21 % | 8 % |
| Royaume-Uni | 92,07 % | 4% |
| Canada | 93,75 % | 3% |
| Allemagne | 93,01 % | 3% |
| Nigeria | 37,45% | 2% |
| Pakistan | 56,32 % | 2% |
| Australie | 85,88 % | 2% |
| Indonésie | 75,34% | 2% |
L'Inde est en fait le premier visiteur Chrome mobile, de loin – près du triple du prochain visiteur le plus élevé (États-Unis) ! Les Philippines, avec leurs mauvais scores, 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. Désormais, les mauvais scores globaux du LCP sur mobile commençaient à avoir un sens.[19659008]Alors que le mobile a dépassé le bureau en tant que moyen le plus populaire pour accéder à Internet dans le soi-disant monde occidentalil existe toujours ici un bon mélange de mobile et de bureau – souvent lié à nos heures de travail où beaucoup d'entre nous sont assis devant un bureau. Le prochain milliard d'utilisateurs peut ne pas être 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, généreraient plus de trafic de la part des concepteurs et des développeurs assis devant les ordinateurs de bureau pendant la conception et le développement !
En outre, parce que CrUX ne mesure que les utilisateurs de Chromecela signifie que les pays avec plus d'iPhones (comme les États-Unis) auront une proportion beaucoup plus faible de leurs utilisateurs mobiles représentés dans CrUX et donc dans Core Web Vitals, amplifiant ainsi l'effet de ces pays.
Les Core Web Vitals sont. Global
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 des États-Unis, et ne l'obtiendra pas pour les utilisateurs indiens. Au lieu de cela, tous les utilisateurs entrent dans le melting potet si le score de ces groupes de pages n'atteint pas le seuil, alors le signal de classement pour tous les utilisateurs est affecté.
Malheureusement, le monde n'est pas un même endroit. Et les performances Web varient énormément d'un pays à l'autre et montrent une nette distinction 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 de l'infrastructure vers la technologie la plus récente et la plus performante.
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é.
Devrait Core. Les éléments vitaux du Web doivent-ils être divisés par pays ?
D'une part, il semble injuste de maintenir les sites Web au même niveau si l'infrastructure varie tellement. Pourquoi Smashing Magazine devrait-il être pénalisé ou soumis à un niveau plus élevé qu'un site Web similaire qui n'est lu que par des concepteurs et des développeurs du monde occidental ? Si Smashing Magazine bloque les utilisateurs indiens pour que les Core Web Vitals soient satisfaits (je veux être assez clair ici que cela n'a jamais été dans la discussion, alors veuillez considérer cela comme l'auteur faisant le point et non comme un tour de passe-passe sur Smashing !).
D'un autre côté, « renoncer » à certains pays en acceptant leur lenteur risque de les reléguer définitivement au niveau inférieur où se trouvent nombre d'entre eux. l'infrastructure est plus lente et à bien des égards, ce sont les personnes qui méritent plus d'attention et d'efforts, plutôt que moins !
Et ce n'est pas seulement un débat pays riche contre pays pauvre. Prenons l'exemple d'un site Internet français qui s'adresse à des lecteurs en France, financé par la publicité ou les ventes depuis la France, et qui dispose d'un site Internet rapide dans ce pays. Cependant, si le site est lu par de nombreux 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 en français parce qu'elle n'est pas aussi rapide pour ces utilisateurs canadiens ? L'entreprise devrait-elle être « retenue en otage » par la menace de Core Web Vitals et devrait-elle investir dans le CDN mondial pour garder ces lecteurs canadiens, et donc Google heureux ?
Eh bien, si une proportion suffisamment importante de vos téléspectateurs souffre alors c'est exactement ce que l'initiative de Core Web Vital est censée faire surface. Pourtant, c'est un dilemme moral intéressant qui est un effet secondaire de l'initiative Core Web Vitals liée au Boost du classement SEO : l'argent change toujours les choses !
Une idée pourrait être de garder les limites les mêmes, mais les mesurer par pays. Le site français de recherche Google pourrait donner un coup de pouce au classement de ces utilisateurs en français (car ces utilisateurs passent le CWV pour ce site), tandis que Google Search Canada pourrait ne pas le faire (car ils échouent). Cela égaliserait les règles du jeu et mesurerait les sites de chaque pays, même si les cibles 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 le fait qu'ils soient dans le segment « besoin d'amélioration » pourrait en fait encore être meilleur que beaucoup de sites là-bas, en supposant qu'ils subissent tous les mêmes contraintes de performance).
Malheureusement, je pense que cela aurait un effet négatif, avec certains pays à nouveau ignoré alors que les sites ne justifient l'investissement en performance web que pour les pays les plus lucratifs. De plus, comme cet exemple l'illustre déjà, les Core Web Vitals sont déjà suffisamment compliqués pour ne pas mettre en jeu près de 200 dimensions supplémentaires en en ayant un pour chaque pays du monde ! savait pourquoi Smashing Magazine avait du mal à passer Core Web Vitals, mais que pouvait-on faire à ce sujet ? The hosting provider (Netlify) already has the Mumbai CDN, which should therefore provide a fast access for Indian users, so was this a Netlify problem to improve that? We had optimized the site as much as possible so was this just something they were going to have to live with? Well no, we now return to our idea from earlier: optimizing the web fonts a bit more.
We could take the drastic option of not delivering fonts at all. Or perhaps not delivering fonts to certain locations (though that would be more complicated, given the SSG nature of Smashing Magazine’s website). Alternatively, we could wait and load fonts in the front end, based on certain criteria, but that risked slowing down fonts for others while we assessed that criteria. If only there was some easy-to-use browser signal for when we should take this drastic action. Something like the SaveData headerwhich is intended exactly for this!
SaveData And prefers-reduced-data
SaveData is a setting that users can turn on in their browser when they really want to… well save data. This can be useful for people on restricted data plans, for those traveling with expensive roaming charges, or for those in countries where the infrastructure isn’t quite as fast as we’d like.
Users can turn on this setting in browsers that support it, and then websites can then use this information to optimize their sites even more than usual. Perhaps returning lower quality images (or turning images off completely!), or not using fonts. And the best thing about this setting is that you are acting upon the user’s request, and not arbitrarily making a decision for them (many Indian users might have fast access and not want a restricted version of the website!).
The Save Data information is available in two (soon to be three!) ways:
- A
SaveDataheader is sent on each HTTP request. This allows dynamic backends to change the HTML returned. - The
NetworkInformation.saveDataJavaScript API. This allows front-end scripts to check this and act accordingly. - The upcoming
prefers-reduced-datamedia query, allowing CSS to set different options depending on this setting. This is available behind a flag in Chrome, but not yet on by default while it finishes standardization.
So the question is, do many of the Smashing Magazine readers (and particularly those in the countries struggling with Core Web Vitals) use this option and is this something we can therefore use to serve them a faster site? Well, when we added the web-vitals script mentioned above, we also decided to measure that, as well as the Effective Connection Type. You can see the full script here. After a bit of time allowing it to collect we could display the results in a simple /Google Analytics dashboard, along with the Chrome browser version:
So, the good news was that a large proportion of mobile Indian users (about two-thirds) did have this setting set. The ECT was less useful with most showing as 4g. I’ve argued before that this API has gotten less and less useful as most users are classified under this 4g setting. Plus using this value effectively for initial loads is fraught with issues.
More good news as most users seem to be on an up-to-date Chrome so would benefit from newer features like the prefers-reduced-data media query when it becomes fully available.
Ilya from Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. 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!
Conclusions
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.
Happy optimizing!
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.
(vf, yk, il)
Source link