Sommaire

Core Web Vitals Google : comment optimiser le Cumulative Layout Shift (CLS)

Voici un guide sur les techniques pour éviter les Layout Shifts (changements de disposition soudains des éléments à l’écran), afin d’améliorer l’expérience utilisateur.

Télécharger le dossier Core Web Vitals
Les changements de mise en page peuvent être perturbants pour les utilisateurs ; par exemple, si vous lisez un article, que les éléments changent brusquement de place et que vous devez alors rechercher où vous en étiez dans votre lecture. C’est très courant sur les pages web, et surtout très agaçant lorsque vous consultez des actualités ou lorsque vous essayez de cliquer sur les boutons « Rechercher » ou « Ajouter au panier ».
Ces phénomènes surviennent généralement parce que des éléments visibles sont forcés de se déplacer pour laisser la place à un nouvel élément sur la page, ou à un élément redimensionné.

Le Cumulative Layout Shift (CLS) – métrique Core Web Vital – évalue l’instabilité du contenu en additionnant les scores de Layout Shift générés par les changements de mise en page qui se produisent après les 500 ms qui suivent une action de l’utilisateur. Il permet de mesurer la quantité de contenu visible déplacé dans le viewport, ainsi que la distance parcourue par ces éléments.

Ce guide détaille les causes courantes de Layout Shift, et comment améliorer l’expérience utilisateur en réduisant ces changements de disposition inattendus.

Ainsi, les causes les plus courantes d’un mauvais CLS, et que nous allons détailler, sont :

  • Les images sans dimensions
  • Les publicités, éléments embarqués et iframes sans dimensions
  • Le contenu intégré dynamiquement
  • Les fonts web provoquant un FOIT / FOUT
  • Les actions en attente d’une réponse du réseau avant de mettre à jour DOM

(NdT : nous proposons régulièrement des techniques et astuces pour vous aider à améliorer l’ensemble de vos métriques webperf dans notre newsletter mensuelle, vous pouvez vous y abonner ici.)

Cumulative Layout Shift : le problème des images sans dimensions 

En résumé : incluez toujours des attributs width  et height sur vos images et éléments vidéo. Sinon, réservez l’espace requis avec des CSS aspect ratio boxes. Cette technique garantit que le navigateur peut réserver la bonne quantité d’espace pendant le chargement de l’image.

Images sans largeur ni hauteur spécifiées (source Google)

Images avec largeur et hauteur spécifiées (source Google)

Core Web Vitals - Cumulative Layout Shift : dimensionnement des images

Lighthouse : impact de la définition des dimensions de l’image sur le CLS

Historique du dimensionnement des images

Au début du web, les développeurs ajoutaient des attributs width et height à leurs balises <img> pour garantir qu’un espace suffisant serait prévu sur la page avant que le navigateur ne commence à récupérer les images. Cela permettait de minimiser la réorganisation des éléments, et donc les déplacements inopportuns.

[pastacode lang= »markup » manual= »%3Cimg%20src%3D%22puppy.jpg%22%20width%3D%22640%22%20height%3D%22360%22%20alt%3D%22Puppy%20with%20balloons%22%3E » message= » » highlight= » » provider= »manual »/]

Vous aurez remarqué que width et height ci-dessus n’incluent pas d’unités. Ces dimensions en « pixels » assuraient un emplacement de 640×360. L’image devait alors s’étirer pour s’adapter à cet espace, que les vraies dimensions correspondent ou non.

Lorsque le Responsive Design a été introduit, les développeurs ont commencé à délaisser width et height et à utiliser les CSS pour redimensionner les images à la place :

[pastacode lang= »javascript » manual= »img%20%7B%0A%C2%A0width%3A%20100%25%3B%20%2F*%20or%20max-width%3A%20100%25%3B%20*%2F%0A%C2%A0height%3A%20auto%3B%0A%7D » message= » » highlight= » » provider= »manual »/]

L’un des inconvénients de cette approche était que l’espace ne pouvait être alloué à une image qu’une fois qu’elle avait commencé à être téléchargée, et que le navigateur pouvait déterminer ses dimensions. Au fur et à mesure que les images se chargeaient, la page se réorganisait selon leur apparition à l’écran. Du texte pouvait alors surgir dans la fenêtre, l’expérience utilisateur n’était vraiment pas bonne.

C’est là que aspect ratio entre en jeu. Le ratio d’une image est le rapport entre sa largeur et sa hauteur. Ce ratio s’exprime généralement sous la forme de deux nombres séparés par deux points (par exemple 16:9 ou 4:3). Pour un ratio x:y, l’image fait x unités de large et y unités de haut.

Cela signifie que si nous connaissons l’une des dimensions, l’autre peut être déterminée. Pour un format d’image 16:9 comme suit :

  • Si chien.jpg a une hauteur de 360 ​​px, la largeur est de 360 ​​x (16/9) = 640 px
  • Si chien.jpg a une largeur de 640 px, la hauteur est de 640 x (9/16) = 360 px

La connaissance du rapport hauteur / largeur permet au navigateur de calculer et de réserver un espace suffisant pour la hauteur et la zone associée.

Les bonnes pratiques pour la gestion de l’aspect ratio des images

Les navigateurs modernes définissent désormais le ratio par défaut des images en fonction des attributs width et height, il est donc nécessaire de les définir pour éviter les Layout Shifts. Grâce au CSS Working Group, les développeurs ont juste besoin de définir la largeur et la hauteur normalement :

[pastacode lang= »markup » manual= »%3C!–%20set%20a%20640%3A360%20i.e%20a%2016%3A9%20-%20aspect%20ratio%20–%3E%0A%3Cimg%20src%3D%22chiot.jpg%22%20width%3D%22640%22%20height%3D%22360%22%20alt%3D%22Chiot%20dans%20l%E2%80%99herbe%22%3E » message= » » highlight= » » provider= »manual »/]

… et l’UA stylesheets de tous les navigateurs ajoutent alors un default aspect ratio basé sur les attributs width and height des éléments existants :

[pastacode lang= »javascript » manual= »img%20%7B%0A%C2%A0%C2%A0%C2%A0aspect-ratio%3A%20attr(width)%20%2F%20attr(height)%3B%0A%7D » message= » » highlight= » » provider= »manual »/]

Cela permet de définir un ratio basé sur les attributs width et height avant le chargement de l’image, et disposer de ces informations au tout début du calcul du layout. Dès qu’une image est définie comme ayant une certaine largeur (par exemple width: 100%), le ratio est utilisé pour calculer la hauteur.

Tip : Si vous avez du mal à calculer le ratio par vous-mêmes, cet outil va vous aider.

Les changements dans le calcul de l’aspect ratio sont présentes dans Firefox et Chromium et arrivent sur WebKit (Safari).

Pour aller plus loin sur le sujet des aspect ratio, et pour une réflexion sur les images responsive, vous pouvez consulter (en anglais) jank-free page loading with media aspect ratios.

Si votre image est dans un conteneur, vous pouvez utiliser CSS pour redimensionner l’image à la largeur de ce conteneur. Nous définissons alors height: auto; pour éviter que la hauteur de l’image soit une valeur fixe (par exemple 360px).

[pastacode lang= »javascript » manual= »img%20%7B%0A%C2%A0height%3A%20auto%3B%0A%C2%A0width%3A%20100%25%3B%0A%7D » message= » » highlight= » » provider= »manual »/]

Qu’en est-il des images responsive ?

Lorsque vous travaillez avec des images responsive, l’attribut srcset définit ce que le navigateur va choisir comme image et à quelles dimensions. Pour garantir que les attributs de largeur et de hauteur <img> peuvent être paramétrés, chaque image doit utiliser le même rapport hauteur / largeur. Par exemple :

[pastacode lang= »markup » manual= »%3Cimg%20width%3D%221000%22%20height%3D%221000%22%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0src%3D%22puppy-1000.jpg%22%0A%C2%A0%C2%A0%C2%A0srcset%3D%22puppy-1000.jpg%201000w%2C%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0puppy-2000.jpg%202000w%2C%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0puppy-3000.jpg%203000w%22%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0alt%3D%22Puppy%20with%20balloons%22%2F%3E » message= » » highlight= » » provider= »manual »/]

Quid du design ?

En termes de design UI, les pages peuvent nécessiter une photo recadrée sur des écrans étroits (mobile) et une image complète sur un écran desktop.

[pastacode lang= »markup » manual= »%3Cpicture%3E%0A%C2%A0%3Csource%20media%3D%22(max-width%3A%20799px)%22%20srcset%3D%22puppy-480w-cropped.jpg%22%3E%0A%C2%A0%3Csource%20media%3D%22(min-width%3A%20800px)%22%20srcset%3D%22puppy-800w.jpg%22%3E%0A%C2%A0%3Cimg%20src%3D%22puppy-800w.jpg%22%20alt%3D%22Puppy%20with%20balloons%22%3E%0A%3C%2Fpicture%3E » message= » » highlight= » » provider= »manual »/]

Il est tout à fait possible que ces images aient des proportions différentes et les navigateurs évaluent toujours la solution la plus efficace, y compris si les dimensions doivent être spécifiées sur toutes les sources. Jusqu’à ce qu’une solution soit définie, la réorganisation des éléments est toujours possible.

Cumulative Layout Shift : les problèmes posés par les publicités, éléments embarqués et iframes sans dimensions

Publicités et CLS

La publicité est l’une des principales causes de Layout Shift sur les pages web. Les réseaux publicitaires et les éditeurs prennent souvent en charge les tailles d’annonces dynamiques. Les tailles d’annonces favorisent les performances et les revenus en raison d’un taux de clics plus élevé et d’une concurrence plus importante pour l’enchère. Malheureusement, cela peut conduire à une expérience utilisateur dégradée en raison des publicités poussant le contenu consulté en bas de la page.

Au cours du cycle de vie de la publicité, de nombreux points peuvent introduire un changement de mise en page :

  • lorsqu’un site insère un bloc de pub (ad container) dans le DOM
  • lorsqu’un site redimensionne le conteneur avec un code propriétaire
  • lorsque la librairie de tags publicitaires se charge (et redimensionne le conteneur)
  • lorsque la publicité remplit un conteneur (et change de dimensions si la publicité finale a une taille différente).

La bonne nouvelle est qu’il est possible pour les sites de suivre les bonnes pratiques pour réduire le Layout Shift lié à la publicité.Il est possible de :

  • Réserver statiquement de l’espace pour l’espace publicitaire.

    • En d’autres termes, stylez l’élément avant le chargement de la librairie de tags publicitaires.
    • Si vous placez des annonces dans le flux de contenu, assurez-vous d’éviter les décalages de contenu en réservant la taille de l’emplacement. Ces annonces ne devraient pas entraîner de changements de mise en page si elles sont chargées hors viewport.
  • Soyez prudent lorsque vous placez des annonces flottantes près du haut de la fenêtre.
    • Dans l’exemple ci-dessous, il est recommandé de déplacer l’annonce en dessous du logo « World vision » et assurez-vous de réserver suffisamment d’espace pour l’emplacement.
  • Si aucune pub n’est affichée alors que son emplacement est visible par l’utilisateur, évitez de supprimer cet emplacement et affichez plutôt un placeholder.
  • Éliminez les Layout Shifts en réservant la plus grande taille possible pour l’espace publicitaire.
    • Il y a toutefois un risque de laisser un espace vide si les dimensions de la publicité sont plus petites que l’emplacement prévu.
  • Choisissez la taille la plus probable pour l’espace publicitaire en fonction des données historiques.

Sur certains sites, réduire l’espace au départ peut limiter les Layout Shifts s’il y a peu de chances pour que cet espace publicitaire soit rempli. Quoiqu’il en soit, il n’est pas facile de définir systématiquement la taille exacte, à moins que vous ne contrôliez vous-même l’annonce.

Annonces sans espace suffisant réservé (source Google)

Annonces avec suffisamment d’espace réservé (source Google)

Core Web Vitals - Cumulative Layout Shift : ads

Lighthouse : impact sur le CLS d’un espace réservé pour la bannière

Réserver un espace statique pour la publicité

Attribuez de façon statique un style aux éléments du DOM de votre emplacement de pub, et ce avec la même taille que celle transmise à vos tags de pub. Cela peut aider à faire en sorte que la librairie n’introduise pas de changements de disposition des éléments de la page lors du chargement. Si vous ne le faites pas, la librairie peut modifier la taille de l’emplacement après la mise en page.

Tenez également compte des annonces de taille inférieure à l’espace réservé. Si une annonce plus petite est servie, l’éditeur peut attribuer un style (plus grand) au conteneur pour éviter les Layout Shift. L’inconvénient de cette approche est qu’elle augmente la quantité d’espace vide, gardez bien à l’esprit ce principe.

Évitez de placer des annonces vers le haut du viewport

Les annonces situées en haut de la fenêtre peuvent entraîner un décalage de mise en page plus important que celles situées au milieu. En effet, les annonces en haut du viewport ont généralement un contenu qui va se déployer du haut vers le bas, ce qui fait que plus d’éléments devront se déplacer vers le bas. Inversement, les annonces situées vers le milieu du viewport entraînent potentiellement moins de changements sur la page web.

Eléments embarqués (embed) et iframes et CLS

Les widgets vous permettent d’embarquer du contenu dans votre page (par exemple, des vidéos de YouTube, des cartes de Google Maps, des publications sur les réseaux sociaux, etc.). Ces intégrations peuvent prendre plusieurs formes :

  • Remplacement de code HTML ou de balise JavaScript par des éléments visuels 
  • Snippet HTML inliné
  • iframe embarquée

Il n’est pas toujours possible de prévoir à l’avance la taille de ces éléments embarqués (par exemple, dans le cas d’une publication sur les réseaux sociaux : a-t-elle une image intégrée ? Une vidéo ? Plusieurs lignes de texte ?). Par conséquent, les plateformes proposant des éléments embed ne réservent pas toujours suffisamment d’espace pour ce faire, ce qui peut entraîner un Layout Shift au moment du chargement de la page.

Embed sans espace réservé (source Google)

Embed avec espace réservé (source Google)

Core Web Vitals - Cumulative Layout Shift : elements embed

Lighthouse : impact sur le CLS d’un espace réservé pour l’élément embed

Pour contourner ce problème, vous pouvez réduire le CLS en précalculant suffisamment d’espace pour les éléments embarqués avec un espace réservé ou de secours. Voici un workflow que vous pouvez utiliser pour ces intégrations :

  • Relevez la hauteur de votre intégration finale en l’inspectant avec les outils de développement de votre navigateur.
  • Une fois l’élément embed chargé, l’iframe contenue se redimensionnera pour s’adapter à son contenu.

Prenez note des dimensions et créez un espace réservé pour l’intégration en conséquence. Vous devrez peut-être tenir compte des légères différences entre les tailles d’annonces / emplacements prévus à l’aide des media queries.

Contenu dynamique et CLS

En résumé : évitez d’insérer du nouveau contenu au-dessus du contenu existant, sauf en réponse à une interaction de l’utilisateur. Cela garantit que tous les changements de disposition qui se produisent sur la page sont attendus.

Vous avez probablement observé des changements de mise en page en raison de l’interface utilisateur qui apparaît en haut ou en bas de la fenêtre lorsque vous essayez de charger un site. Comme pour les publicités, cela se produit souvent avec des bannières et des formulaires qui modifient le reste du contenu de la page :

  • Abonnement à une newsletter
  • Suggestions d’articles liés
  • Push pour l’installation d’une application
  • Notice RGPD…

Contenu dynamique sans espace réservé (source Google)

Si vous devez afficher ces éléments dans l’interface utilisateur, réservez-lui suffisamment d’espace dans le viewport (par exemple, en utilisant un espace réservé ou un skeleton UI, soit une version simplifiée et stylisée du layout) afin que, lors du chargement, le contenu de la page ne se déplace pas de manière inattendue.

Les fonts provoquant un FOUT / FOIT 

Le téléchargement et le rendu des fonts peuvent entraîner des changements de disposition de deux manières :

  • La font de secours est remplacée par une nouvelle (FOUT – flash de texte sans style)
  • Le texte « invisible » est affiché jusqu’à ce qu’une nouvelle font soit rendue (FOIT – flash de texte invisible)

Les outils suivants peuvent vous aider à minimiser cela :

Depuis Chrome 83, Google recommande ce qui suit :

  • Utiliser <link rel = preload> sur les fonts clés : une police préchargée aura plus de chances d’arriver au moment du First Paint, auquel cas il n’y a pas de changement de mise en page.
  • Combiner <link rel = preload> et font-display: optional.

Consultez (en anglais) Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fonts pour plus aller plus loin sur le sujet des fonts.

CLS et animations 

En résumé : préférez transform pour les animations, par rapport aux animations de propriétés qui déclenchent des changements de layout sur la page web.

Les modifications apportées aux valeurs des propriétés CSS peuvent nécessiter que le navigateur réagisse à ces modifications. Un certain nombre de valeurs déclenchent la réorganisation des éléments sur la page, l’affichage et le compositing tels que box-shadow et box-sizing. Un certain nombre de propriétés CSS peuvent être modifiées de manière moins coûteuse.

Pour en savoir plus sur les propriétés CSS qui déclenchent la mise en page, vous pouvez consulter CSS Triggers et High-performance animations.

Outils développeurs pour évaluer le Cumulative Layout Shift

Un certain nombre d’outils existent pour mesurer et optimiser le Cumulative Layout Shift (CLS).

  • Lighthouse prend en charge la mesure du CLS via les données Lab et met en évidence les points qui provoquent le plus de Layout Shift (PageSpeed Insights également).

Google Lighthouse - Performance score - CLS

  • Performance panel dans DevTools met en évidence les changements de mise en page dans la section Experience à partir de Chrome 84. La vue Summary de l’enregistrement d’un changement de mise en page comprend le score cumulé de Layout Shift ainsi qu’une visualisation des zones affectées.

Core Web Vitals - Cumulative Layout Shift : Page Experience

Après avoir enregistré une nouvelle trace dans Performance Panel, la section Experience affiche une barre rouge qui représente un changement de mise en page.
En cliquant sur l’enregistrement, vous pouvez explorer les éléments impactés.

Mesurer le Cumulative Layout Shift est possible en conditions réelles grâce à Chrome User Experience Report qui propose des valeurs de CLS agrégées pour un site donné. Les données CLS CrUX sont disponibles via BigQuery, et un sample pour observer le CLS est aussi disponible.

Vous souhaitez creuser le sujet en vidéo ? Le replay de notre webinaire dédié au CLS est ici :

Vous souhaitez savoir comment automatiser les optimisations
qui vous permettront d’améliorer votre CLS et l’ensemble de vos Core Web Vitals ?

Demandez une démo

L’article original est en anglais sur Web.dev

A lire aussi :

Sommaire
Partagez !
Recevoir la newsletter

Publié par

Partagez !

Découvrez d’autres articles…

Améliorer les performances de son site : des équipes IT témoignent
Les solutions de cache sont la base pour réduire les temps de chargement. Nous avons donc développé des fonctionnalités de cache avancées afin de rendre « cachable » un maximum de ressources et de pages : découvrez les petits plus de notre cache HTTP, le SmartCache ou encore le Cookieless Cache !
La première impression sur un site web peut être déterminante : en quelques instants seulement, l’utilisateur peut décider de poursuivre son parcours et revenir sur votre site s’il se sent bien accueilli, ou le quitter et disparaître à jamais si son expérience est mauvaise.

Mais restez informé !

S’inscrire !

Chaque mois, pas plus, recevez :

🆕 Les dernières publications sur notre blog : évolutions de la plateforme, nouvelles fonctionnalités, événements, conseils techniques, analyses…

💡 Une sélection d’articles de veille : actualités techniques, tips, tutos, et autres trouvailles sur la webperf…

Solutions