Le PRPL pattern, une des nombreuses optimisations embarquées dans GatsbyJS

Avec le nombre de bibliothèques et de frameworks sur le marché, on finit parfois par oublier qu’ils ont pour but de nous faciliter la vie.

Quand on démarre sur un nouvel outil, on peut avoir l’impression qu’il a été créé simplement pour justifier la mise à jour de nos projets.
Il faut prendre du recul pour entrevoir ce que peut apporter une nouvelle technologie, une nouvelle méthode, un nouvel outil…

Le PRPL pattern est un schéma d’architecture web qui impacte la manière dont on charge une application.
C’est un processus implémenté dans GatsbyJS, tu n’as pas à t’en soucier…


Un pattern mis en avant par Google

Le PRPL permet d’améliorer les performances de chargement des pages Web.

Il se décompose en 4 étapes :

• Push (ou preload) : les ressources les plus importantes
• Render : générer le rendu initial le plus tôt possible
• Pre-cache : mettre en cache les autres ressources
• Lazy load : charger à la demande les adresses (routes) et ressources non-critiques

Google a poussé l’utilisation de ces fonctionnalités pour améliorer le TTI en ajoutant des fonctionnalités dans Chrome.

Le TTI (Time To Interactive) est une mesure de performance qui permet de définir le temps nécessaire pour que l’utilisateur soit en mesure d'interagir avec la page en question.


Dans les faits, tu peux avoir une application qui propose un premier chargement rapide mais qui reste inutilisable pendant un laps de temps dû à des problèmes de performances.

Inutile de préciser que ces métriques sont importantes pour la SEO, les robots des moteurs de recherche mesurent ce type d’indicateurs.

Un mauvais TTI peut avoir un impact direct sur la note SEO attribuée et ainsi détériorer les performances SEO.


Comment GatsbyJS tire partie du PRPL pattern ?

L’avantage de générer du contenu statique est que ça facilite l’identification des ressources importantes.

GatsbyJS tire partie de la couche de données embarquée et de son api pour identifier les ressources à charger en priorité.

Un exemple type est le chargement de la home de ton site.

La marche à suivre serait de charger tout ce qui est nécessaire pour afficher ta page.
La deuxième étape consiste à pré-charger les données des pages accessibles depuis la home.

Dans sa configuration de base, GatsbyJS va précharger les données de la page suivante au survol du lien.

Cela permet de gagner de précieuses millisecondes pour afficher la page le plus rapidement possible.

Le PRPL pattern fait partie des optimisations embarquées par GatsbyJS out-of-the-box.
Il existe d’autres fonctionnalités propres à la Jamstack en générale…


Pourquoi chercher à optimiser à ce point ?

On pourrait se poser la question : pourquoi chercher à optimiser alors que nos appareils sont tous les jours de plus en plus rapides ?

Une chose qu’on a tendance à oublier en tant que développeur, c’est l’aspect empirique des performances.
Un problème anodin pour une volumétrie basse peut vite devenir bloquant quand la volumétrie explose.

Ignorer volontairement un problème de performance au début du développement peut avoir de lourdes conséquences après plusieurs mois ou années…

Je l’ai vu de mes propres yeux, des problèmes allant jusqu'à faire planter systématiquement un navigateur au bout de 15 minutes d’utilisation.

Attention à ne pas tomber dans l’optimisation prématurée.

C’est une pratique qui peut te couter beaucoup de temps aussi.

L’autre problème des développeurs vis-à-vis des performances est un problème de contexte.

Quand tu testes ton application, tu es souvent dans des conditions plus qu’ idéales: tu as un réseau fibre d’entreprise, les données sont parfaites parce que tu as un accès direct à la base de données, tu testes méthodiquement le cas de figure décrit dans ta User Story.

Mais il y a des choses auxquelles tu ne penseras peut-être pas.
Tu peux avoir cet utilisateur qui va appuyer dix fois sur la même action et déclencher 10 fois le même traitement.

Tu peux avoir celui qui utilise ton application dans le métro avec une connexion Edge ultra-lente où seul le mode hors-ligne fonctionne.


Les performances ne devraient pas être une option

Tu as bien compris mon positionnement sur le sujet.

N’importe quel développeur devrait être en mesure d’analyser les performances de son application.

Aujourd’hui, c’est très simple, tu peux commencer par faire audit Lighthouse.
C’est intégré dans Google Chrome et simple d’utilisation.

Mais comprendre toutes les métriques est un autre défi.
Ca ne s’invente pas, l’avantage de Gatsby est qu’il embarque les bonnes pratiques.

A demain,

Captain Dev