Cumulative Layout Shift (CLS)
(web.dev)Indicateur de performance centré sur l’utilisateur qui vérifie l’instabilité visuelle susceptible d’entraîner des clics involontaires, en mesurant à quel point la mise en page d’une page web change à cause du chargement lent des images/publicités, des opérations asynchrones, de modifications dynamiques du DOM, etc.
"Un bon score CLS est inférieur ou égal à 0,1"
L’API Layout Instability fournit une mesure appelée Layout Shift Score
- Layout Shift Score = impact fraction ( quelle proportion de l’élément déplacé est concernée ) * distance fraction ( de combien l’élément se déplace )
- Les changements de mise en page provoqués par une action de l’utilisateur sont acceptables : s’il y a eu une entrée utilisateur dans les 500 ms, `hadRecentInput` est défini et peut donc être exclu du calcul
- Au lieu de modifier `height`/`width`, utiliser `transform:scale()`
- Au lieu de modifier `top`,`right`,`bottom`,`left`, utiliser `transform: translate()`
Méthodes pour améliorer le CLS
- Toujours définir la taille des images/vidéos ou réserver leur emplacement avec des CSS Aspect Ratio Boxes, etc.
- En dehors des interactions utilisateur, ne pas ajouter de nouveau contenu au-dessus du contenu existant
- Animer les transitions entre états avec CSS Transform, etc.
4 commentaires
Il arrive souvent qu’au moment précis où l’on va appuyer, la mise en page bouge soudain légèrement et provoque un mauvais clic ou toucher, ce qui est vraiment agaçant ; il existe enfin une méthode pour mesurer cela de façon quantitative. Personnellement, je me dis que si on mesurait ça sur les sites des médias, on obtiendrait sans doute des chiffres catastrophiques.
Les médias coréens ont tellement de publicités, et en plus ces publicités elles-mêmes sont lentes et clignotent, que la mesure en elle-même semble sans doute dénuée de sens...
Sur un autre sujet, j'utilise https://github.com/disjukr/just-news et Tampermonkey pour ne voir que le corps de l'article sur les médias coréens. Les sites web sont beaucoup trop encombrés.
Il m’est déjà arrivé d’essayer d’écrire en Python un [programme qui, lorsqu’on lui donne un lien vers un article de presse, le convertit automatiquement en lien vers l’article sur un portail d’actualités]. Mais j’ai bêtement perdu le code source (je l’avais enregistré par erreur sur un RAM drive, puis j’ai redémarré), et après un moment de lucidité(?) je l’ai laissé tomber.
Les métriques de performance centrées sur l’utilisateur
https://web.dev/user-centric-performance-metrics
https://developers.google.com/web/fundamentals/…
Les indicateurs existants comme
loadetDOMContentLoadedne sont pas de bons métriques.First contentful paint (FCP) : moment où le premier contenu commence à s’afficher à l’écran
Largest contentful paint (LCP) : moment où le plus grand bloc de texte ou la plus grande image de la page s’affiche
First input delay (FID) : temps écoulé entre le moment où l’utilisateur peut interagir et celui où le navigateur réagit réellement
Time to Interactive (TTI) : temps nécessaire entre le chargement et le moment où l’interaction utilisateur devient possible
Total blocking time (TBT) : durée totale entre le FCP et le TTI
Cumulative layout shift (CLS) : indicateur des changements de mise en page