En quelques mois, le principal site Web d'actualités du Royaume-Uni a réussi à améliorer son CLS de 75e centile de 250% de 0,25 à 0,1.
Le défi de la stabilité visuelle
Les décalages de mise en page peuvent être très perturbateurs. Chez Telegraph Media Group (TMG), la stabilité visuelle est particulièrement importante, car les lecteurs se servent principalement de nos applications pour consommer les actualités. Si la mise en page change lors de la lecture d'un article, le lecteur risque de perdre sa place. Cela peut être une expérience frustrante et gênante.
D'un point de vue technique, il peut être difficile de s'assurer que les pages ne se déplacent pas et n'interrompent pas le lecteur, en particulier lorsque des zones de votre application sont chargées de manière asynchrone et ajoutées à la page de manière dynamique.
Chez TMG, plusieurs équipes contribuent au code côté client:
- Ingénierie de base. La mise en œuvre de solutions tierces dans des domaines tels que les recommandations et les commentaires de contenus.
- Marketing. Exécuter des tests A/B pour évaluer la manière dont nos lecteurs interagissent avec les nouvelles fonctionnalités ou les modifications
- Publicité. Gestion des demandes d'annonces et pré-enchères
- Rédaction : Intégrer du code dans des articles tels que des tweets ou des vidéos, ainsi que des widgets personnalisés (par exemple, un outil de suivi des cas de coronavirus)
Il peut être difficile de s'assurer que chacune de ces équipes n'entraîne pas de saccades de la mise en page. En utilisant la métrique Cumulative Layout Shift pour mesurer la fréquence à laquelle elle se produit pour nos lecteurs, les équipes ont pu mieux comprendre l'expérience utilisateur réelle et définir un objectif clair. Ainsi, notre CLS au 75e centile est passé de 0,25 à 0,1, et notre bucket de transmission est passé de 57% à 72%.
250%
Amélioration du CLS au 75e centile
15 %
Plus d'utilisateurs avec un bon score CLS
Nos débuts
Les tableaux de bord CrUX nous ont permis de déterminer que nos pages se déplaçaient plus que prévu.
Idéalement, nous voulions qu'au moins 75% de nos lecteurs aient une "bonne" expérience. Nous avons donc commencé à identifier les causes de l'instabilité de la mise en page.
Comment nous avons mesuré les décalages de mise en page
Nous avons combiné les outils de développement Chrome et WebPageTest pour identifier la cause du décalage de la mise en page. Dans les outils de développement, nous avons utilisé la section Expérience de l'onglet Performances pour mettre en évidence les instances individuelles de changement de mise en page et la manière dont elles ont contribué au score global.
WebPageTest indique de manière utile où le décalage de mise en page se produit dans la vue chronologique lorsque l'option "Highlight Layout Shifts" est sélectionnée.
Après avoir examiné chaque changement constaté dans nos modèles les plus consultés, nous avons établi une liste d'idées d'améliorations.
Réduire les décalages de mise en page
Nous nous sommes concentrés sur quatre domaines dans lesquels nous pourrions réduire les décalages de mise en page : - les publicités - les images - les en-têtes - les intégrations
Publicités
Les annonces se chargent après le rendu initial via JavaScript. Certains des conteneurs qu'ils ont chargés ne présentaient aucune hauteur réservée.
Bien que nous ne connaissions pas la hauteur exacte, nous pouvons réserver de l'espace en utilisant la taille d'annonce la plus courante chargée dans l'emplacement.
Nous avions mal jugé la hauteur moyenne de l'annonce dans certains cas. Pour les lecteurs de tablettes, l'emplacement se réduisait.
Nous avons revu l'emplacement et ajusté la hauteur pour utiliser la taille la plus courante.
Images
De nombreuses images du site Web sont chargées de manière différée et disposent d'un espace qui leur est réservé.
Toutefois, aucun espace n'était réservé au conteneur pour les images intégrées en haut des articles, ni les attributs de largeur et de hauteur associés aux balises. Cela provoquait un décalage de la mise en page lors du chargement.
En ajoutant simplement les attributs de largeur et de hauteur aux images, vous avez assuré que la mise en page ne s'était pas déplacée.
En-tête
L'en-tête se trouvait sous le contenu du balisage et était positionné en haut avec CSS. L'idée initiale était de donner la priorité au chargement du contenu avant la navigation, mais cela provoquait un décalage momentané de la page.
Déplacer l'en-tête en haut du balisage a permis à la page de s'afficher sans ce décalage.
Intégrations
Le format de certains éléments intégrés fréquemment utilisés est défini. Par exemple, les vidéos YouTube. Pendant le chargement du lecteur, nous extrayons la miniature de YouTube et l'utilisons comme espace réservé pendant le chargement de la vidéo.
Mesurer l'impact
Nous avons pu mesurer assez facilement l'impact au niveau des fonctionnalités à l'aide des outils mentionnés au début de l'article. Toutefois, nous voulions mesurer CLS à la fois au niveau du modèle et au niveau du site. De manière synthétique, nous avons utilisé SpeedCurve pour valider les modifications en préproduction et en production.
Nous pouvons ensuite valider les résultats dans nos données RUM (fournies par mPulse) une fois que le code est en production.
La vérification des données RUM nous permet de nous assurer que les modifications que nous apportons ont un impact positif sur nos lecteurs.
Les chiffres finaux que nous avons examinés concernent les données RUM que Google collecte. Cela est particulièrement pertinent maintenant, car ils auront bientôt un impact sur le classement des pages. Pour commencer, nous avons utilisé le rapport d'expérience utilisateur Chrome, à la fois dans les données mensuelles au niveau de l'origine disponibles via le tableau de bord CrUX, ainsi que dans l'interrogation de BigQuery pour récupérer les données historiques p75. Ainsi, pour l'ensemble du trafic mesuré par CrUX, le CLS de notre 75e centile est passé de 0,25 à 0,1, et notre bucket de passage est passé de 57 % à 72 %.
En outre, nous avons pu utiliser l'API Chrome UX Report et créer des tableaux de bord internes divisés en modèles.
Éviter les régressions CLS
Pour améliorer les performances, il est important d'éviter les régressions. Nous avons configuré des budgets de performances de base pour nos métriques clés et y avons inclus le CLS.
Si le test dépasse le budget, il envoie un message à un canal Slack afin que nous puissions en rechercher la cause. Nous avons également configuré des rapports hebdomadaires. Ainsi, même si les modèles restent dans le budget, nous sommes au courant de toute modification ayant un impact négatif.
Nous prévoyons également d'augmenter nos budgets pour utiliser les données RUM et les données synthétiques, en utilisant mPulse pour définir à la fois des alertes statiques et, éventuellement, la détection d'anomalies, ce qui nous informerait de toute modification inhabituelle.
Il est important pour nous d'aborder les nouvelles fonctionnalités en tenant compte du CLS. La plupart des modifications que j'ai mentionnées sont celles que nous avons dû corriger après leur mise à disposition pour nos lecteurs. À l'avenir, la stabilité de la mise en page sera prise en compte pour la conception de la solution de toute nouvelle fonctionnalité, afin d'éviter tout décalage de mise en page inattendu dès le départ.
Conclusion
Les améliorations que nous avons apportées jusqu'à présent ont été assez faciles à mettre en œuvre et ont eu un impact important. La plupart des modifications décrites dans cet article n'ont pas pris beaucoup de temps. Elles ont été appliquées à tous les modèles les plus couramment utilisés, ce qui signifie qu'elles ont eu un impact positif global sur nos lecteurs.
Certaines sections du site doivent encore être améliorées. Nous étudions des moyens d'améliorer notre logique côté client côté serveur afin d'améliorer encore plus le CLS. Nous continuerons de suivre et de surveiller nos métriques afin de les améliorer constamment et d'offrir à nos lecteurs la meilleure expérience utilisateur possible.