Retour d'expérience : GatsbyJS et mauvais CLS (Cumulative Layout Shift)

Nous allons voir dans cet article une problématique (désagréable :)) que nous avons eue lorsque nous avons développé notre nouveau site web.

GatsbyJS est un formidable framework qui permet de développer des applications et des sites web très rapidement et qui est extrêmement performant en utilisant le framework React.

Lors de la 2e version de notre site web réalisée dans cette technologie, nous avons eu des problèmes de performance avec Google Page Speed. Nous avons mis un long moment à comprendre pourquoi notre CLS était moins beau que d'habitude.

Cumulative Layout Shift (CLS) : définition

Pour rappel, le CLS (Cumulative Layout Shift) mesure le temps pendant lequel des changements s’opèrent lors du rendu de votre page. En gros, l’idée est de minimiser l’effet du mouvement sur le site avant d'être stable.

Problématique de performance avec Gatsby

Notre objectif : avoir toujours presque 100% sur Google Page Speed. Or, depuis quelques semaines ce temps était passé en territoire orange, c’est-à-dire pas terrible !

D’ailleurs petite remarque, on a l’impression de se battre contre un titan avec cet outil, car chaque mois, la barre à atteindre est plus haute !

Comprendre le fonctionnement de GatsbyJS et son impact sur le CLS

A priori le fonctionnement de GatsbyJS est le suivant :

• Les templates développés en React sont hydratés avec une source de données, chez nous Strapi pendant la phase de build.
• GatsbyJS génère l'intégralité des pages HTML/CSS (SSR). Lors du déploiement nous n'avons pas forcément fait attention, mais sur certaines pages, le HTML généré était presque vide.

En regardant de plus près GatsbyJS utilisait le framework React pour aller chercher les données et construire la page côté navigateur. Ceci implique que la page mettait plus de temps à être calculée : le CLS était mécaniquement dégradé.

CLS et Gatsby : la source du problème

En regardant en détail dans le code et en recherchant de la documentation sur Internet, nous nous sommes aperçus que GatsbyJS, de manière transparente, déterminait sur chacune des pages s'il était possible de la générer en amont (SSR - server side rendering) ou s'il était nécessaire de la générer at runtime.

En nous penchant sur le sujet, nous avions utilisé les méthodes useEffect ou useState pour les générer des sommaires de l’article en se basant sur les h1 et h2 et h3… Et en effet, ces méthodes se basent sur la page Rendered côté navigateur…

C’est évident une fois qu’on l'a trouvé… Non ?

Google Page Speed, CLS et Gatsby : nos conclusions

En supprimant l'utilisation de ces méthodes et en pré-calculant le sommaire côté serveur sans utiliser ces méthodes, nous avons constaté lors de la phase de build, que les pages étaient effectivement remplies du contenu précalculé par GatsbyJS. Nous avons relancé des analyses Google Page Speed et effectivement la performance CLS était bien meilleure.

C'est évident que GatsbyJS était obligé de faire ce qu'il faisait, mais ce n'était pas si évident que ça pour le développeur. En tout cas on s'est bien fait avoir. Il me paraîtrait très intéressant que lors de la compilation de GatsbyJS, on puisse avoir l'information de savoir si la page est entièrement calculée Server Side du côté navigateur.

En tout cas, ce qui est clair, c'est qu'il n'est pas pertinent d'utiliser ces méthodes si vous souhaitez avoir une performance maximale sur Google Page Speed. Nous avons néanmoins utilisé ces méthodes pour certaines pages du site lorsque nous avions des formulaires et où des filtres, là où nous avions réellement besoin de toute la puissance de ReactReact est un framework de développement JavaScript populaire..

En conclusion : faites bien attention si vous souhaitez utiliser useEffect ou useState lors de votre développement sur GatsbyJS.

Pour discuter de votre projet Gatsby, n'hésitez pas à nous contacter !