Optimiser Gatsby

Gatsby est surpuissant niveau perf mais peut-il aller encore plus loin ? Aussi optimiser ne concerne pas que la perf !

Une vision et des ambitions

Que ce soit WordPress avec son « Gutenberg » ou ici « Gatsby », les noms ont un sens. C’est particulièrement vrai chez les développeurs, en général, ce qu’ils codent, ils le nomment avec une intention claire et précise.

Dans les deux cas que j’ai cités, l’ambition est immense pour ne pas dire universelle, on cherche à créer une révolution.

We believe that in 5 or 10 years, we’ll look back at many of these blocks like we look back at machine code or assembly language today; low-level languages that are great compile targets for higher-level languages that are easier to write in.

Source

Sous le capot ça speede

« Derrière la scène », Gatsby va en fait sélectionner uniquement ce qui est nécessaire sur la page. Rien ne sera chargé inutilement.

S’ajoute à cela un maximum de preloading qui consiste donc à pré-charger des ressources que les utilisateurs sont susceptibles d’utiliser dans un futur tout à fait proche et quasi certain.

Gatsby créé en quelque sorte une appli React survitaminée pour chacune des pages du site incluant minification, optimisation des images et j’en passe.

Il se base sur les principes de la PRPL, un modèle qui s’applique aux Progressive Web Apps (PWAs). Pour le dire de manière moins pompeuse, l’axe est mis sur l’optimisation de la performance pour le web mobile en partant du constat que ce dernier est beaucoup trop gras en général.

Source

On peut encore optimiser ?

Premièrement, Gatsby « lui-même » (au sens de la communauté) a pu identifier des points d’améliorations et des défauts. Dans ses premières versions, pour un site avec plus de 5,000 pages, la taille des fichiers références dans le système Gatsby, qui sont interrogés tout le temps, comme le manifest, était trop importante, sur mobile avec une connexion 3G (voire des conditions encore moins bonnes ) ça devenait critique !

Il a fallu revoir l’architecture-même de l’outil pour tenter de résoudre ce problème.

Source

5,000 pages c’est relativement vite atteint, certains sites peuvent en avoir jusqu’à 100 fois plus…

Deuxièmement, la taille du site influence aussi les temps de génération puisque Gatsby fonctionne ainsi. Il génère des builds. Mais il regénère l’ensemble à chaque modification donc aussi bien pour dév que pour mettre en prod, y a pas intérêt à avoir un trop gros site ou alors faut avoir du temps à gaspiller ^^.

Source

Depuis le 1er jour, la communauté Gatsby est consciente du problème d’ailleurs :

But static sites, despite how much developers love them, have never gained widespread usage. They have real limitations in real-world use cases—they can’t handle frequent content updates and can’t scale to large and complex sites.

Un problème inhérent au principe des générateurs de sites statiques. La solution viendra peut-être des « incremental builds » annoncés pour bientôt à l’heure où j’écris ce billet.

Les chiffres parlent

Lighthouse

Gatsby explose les scores de performance et autre :

Ce résultat d’audit a été obtenu sans insister plus que ça sur la performance fourni par l’outil de base.

Source

73 est un blog perso. J’ai obtenu le même type de scores sur d’autres projets incluant documentation, vitrine, etc. Tous ont en commun leur faible taille et un périmètre réduit.

Une V2 calibrée !

La V2 aura réussi à :

  • diminuer les temps de build de 75%
  • diminuer la taille du code js global de 31%
  • inclure webpack 4, Babel 7, React 16.5

Source

Des chiffres impressionnants mais en grande partie dus aux améliorations des librairies comme React sur laquelle se base Gatsby.

Ce point est d’ailleurs tout à fait transparent dans la communication de la commnauté et des équipes de Gatsby. Au passage cette communication est toujours très claire, pédagogique et documentée !

Donc y a rien à faire ?

La rapidité et la qualité des mises à jour est exceptionnelle ! Cela n’empêche, c’est vous qui êtes aux manettes donc il y aura toujours une possibilité pour annuler ces gains de perf en fonction de votre niveau d’expérience dans React ET Gatsby.

A suivre, quelques astuces et bonnes pratiques que je recommande.

Le defaulting

Imaginons le composant MyComponent.js. Au lieu de faire :

import React, {Component} from "react"

class MyComponent extends Component {
   render() {
       (
          <div className="my-compo">{children}</div>
       );
   }
}

et pour le récupérer :

import {MyComponent} from './MyComponent.js';

Faites plutôt :

import React from "react"

export default ({children}) => (
    <div className="my-compo">{children}</div>
);

Source

On peut toujours réaliser l’import suivant dans un autre composant par exemple :

import MyComponent from './MyComponent.js';

De toute manière ES6/7 va tester ça. Bien sûr on n’aura le droit qu’à une seul default par composant donc n’utiliser cette technique que dans ce cas.

Si vous avez plusieurs composants par fichier cela ne s’appliquera pas. De toute manière je ne vous conseille pas cette approche, 1 fichier – 1 composant ça semble bien comme organisation.

La destructuration

J’en parlais notamment dans cet article et ce billet. La destructuration nous permet de gagner du temps dans l’écriture et améliore la lisibilité ainsi que le debug :

const {name, age} = this.props;

ce qui permet d’utiliser name et age directement dans le code :

{name}

au lieu d’avoir à faire un this.props.name chaque fois qu’on veut l’utiliser.

Attention avec les ternaires

Pour rappel le ternaire c’est ça :

(ma condition) ? "<p>ok</p>" : "";

une autre manière, plus synthétique d’écrire :

if (ma condition) {
    <p>ok</p>
} else {
   // ko
}

Les dévs Js / React utilisent plutôt :

{
  macondition && 
    <p>ok</p>
}

Cela porte un vrai nom : short-circuit evaluation.

Utiliser Netlify

J’en parle dans ce tuto, le service est tout simplement le meilleur actuellement sur le créneau des sites générateurs statiques comme Gatsby.

En perspective, déploiements automatiques, build à la volée, optimisations CDN, compressions, optimisation des urls, gestions des redirections et règles de cache, etc.

Leur interface est l’une des plus intuitives que j’ai pu voir !

A combiner avec le plugin Gatsby Netlify.

Faites de votre site une PWA

D’après la superbe doc de Gatsby, une PWA c’est simplement un site web qui tire parti des fonctionnalités apportés par les navigateurs récents pour avoir des avantages et des fonctionnalités comparables aux applis.

Source

Ajouter un manifest

Grâce au plugin Gatsby manifest cela se fera assez facilement.

The web app manifest is a simple JSON file that tells the browser about your web application and how it should behave when ‘installed’ on the user’s mobile device or desktop.

Ajouter le support pour le offline

Grâce au plugin Gatsby Offline. Ce support hors connexion se développe de plus en plus dans le web notamment.

Optimiser le SEO

Au-delà des meta classiques type meta title, description, twitter cards, open graph, j’ajoute un sitemap.

« Bizarrement » un plugin Gatsby existe pour cela.

Respectez React (ou pas)

On trouve ce genre d’initiatives. Leur but est de supprimer React ! Ils ne sont pas fous rassurez-vous.

Le point critique, de performance ici, est la taille du bundle js généré par Gatsby, plus vous y mettez de packages, librairies et autres joyeuseries plus il grossit, plus il est lourd.

Dans certains cas, comme vu plus haut, on se retrouve obligé de tordre l’outil…

Attention tout de même avec ces approches, ça demande une excellente compréhension et une maîtrise totale, autrement vous allez juste tout casser !

Si donc vous choisissez d’être prudent, respectez React !

React suit des patterns (des modèles) et un fonctionnement précis (cycle de vie), ne pas prendre le temps de les connaître vous amènerait vers des déboires.

C’est similaire à certaines offres d’emploi que l’on peut recevoir :

on va passer sur les dernières technos

Tout cela est beaucoup plus complexe bien entendu. Je ne jette pas du tout la pierre, il s’agit d’un argument pour envoyer un signal de modernité mais cela n’attirera pas je pense des profils expérimentés (je peux me tromper) car c’est beaucoup trop vague.

En soit cela ne veut rien dire « les dernières technos » à moins de vouloir faire une appli juste pour la hype qui va être refaite dans 6 mois. Je n’ai pas de doute que certaines organisations ont des budgets quasi illimités mais à quoi bon.

Eh bien côté dév c’est exactement pareil ! Il faut être cohérent. Si vous choisissez Gatsby apprenez-le en prodondeur :

Javascript deeply !

Conclusion

Après avoir joué avec l’outil, expérimenté le bon comme le mauvais, Gatsby a un potentiel quasi universel.

Son très très haut niveau d’abstraction peut paradoxalement s’avérer un piège. « Deeply », pas le choix, il va falloir creuser. Personnellement c’est une des composantes du métier que je préfère alors ça ne me dérange pas.

Il me reste beaucoup de chemin dans cet univers Gatsby/React/Js. J’en sais assez pour savoir que je veux en savoir beaucoup plus.