JAMstack, ou comment faire des sites statiques modernes et rapides

Ludwine Probst : Bonjour à tous et à toutes et bienvenue. Vous écoutez le podcast Human Coders. Dans chaque épisode, j'invite un ou une développeuse pour parler de techno, de pratiques de développement ou tout simplement de sujets en lien avec l'informatique. Au programme également, des parcours de développeurs qui, j'espère, vous inspireront.

Aujourd'hui, c'est un épisode un petit peu spécial puisque à mes côtés se trouve Matthieu Segret, co-fondateur de Human Coders.

Matthieu Segret : Bonjour !

Ludwine Probst : Et on reçoit Konstantin Bifert pour parler de la JAMstack. Alors si vous ne savez pas ce que c'est, restez avec nous puisque Konstantin va expliquer ce que c'est, comment et quand l'utiliser, et surtout vous donner des conseils pour vous lancer. Merci Konstantin d'être parmi nous. Pour commencer, est-ce que tu pourrais te présenter ?

Konstantin Bifert : Je suis actuellement développeur sur Bordeaux, essentiellement Front JavaScript, et j'ai commencé à parler en public de la JAMstack récemment.

Qu'est-ce que la JAMstack ?

Ludwine Probst : Justement, qu'est-ce que la JAMstack ?

Konstantin Bifert : La JAMstack, si on commence par l'acronyme, c'est tout simplement JavaScript, APIs et Markup. Le JavaScript pour l'aspect dynamique, le Markup pour tout ce qui sera affichage statique (HTML, CSS, JSON), et les APIs qui vont connecter des services à la partie statique. Globalement, la JAMstack repose sur le fait de dégrouper certaines données back et front.

Matthieu Segret : Si je comprends bien, la grande différence avec un site web classique est que le rendu dynamique ne se fait pas au fur et à mesure de la navigation, mais en amont. Tout est généré lors d'une phase de compilation de l'intégralité du site. On obtient des pages statiques qu'on peut ensuite héberger, et le site est "figé" une fois déployé. C'est ça ?

Konstantin Bifert : C'est même mieux que ça. Il y a effectivement une partie où tu "buildes" ton app, ce qui génère des fichiers statiques. C'est excellent pour le SEO, l'arborescence est claire et c'est très rapide à charger.

Aujourd'hui, si tu écris un blog avec 12 articles, quand tu vas envoyer ton code sur Netlify, il va générer tes 12 pages statiques. Ce qui est génial, c'est que ton application va ensuite "s'hydrater". C'est le principe technique : ton JavaScript arrive de manière asynchrone sur la page et transforme ta page statique en une Single Page App (SPA). Sans même que tu le vois, elle devient dynamique. Tu n'as plus de rafraîchissement de page à chaque navigation et tu profites de tous les bénéfices de réactivité. Tu peux utiliser ton framework JS favori comme React, Vue.js, Gridsome, Next.js, Nuxt.js ou Gatsby.

C'est le meilleur des deux mondes : d'un côté c'est performant, optimisé pour le SEO et sécurisé (puisqu'au début ce ne sont que des fichiers statiques), et de l'autre, tu peux utiliser des technos modernes.

Matthieu Segret : Pour le SEO, c'est idéal car Google peut parser le site de manière statique, mais on ne perd pas le côté dynamique puisque le JavaScript reprend la main ensuite.

Konstantin Bifert : Exactement. Par défaut, c'est déjà pré-configuré pour la performance. Si vous ouvrez un navigateur Chrome et que vous faites un audit, vous verrez que Google aime beaucoup les sites sous JAMstack. Ils compressent les images, utilisent le protocole HTTP/2 et le principe "PRPL" de Google. Tout est optimisé sans que vous ayez à vous en occuper.

Déploiement et gestion du cache

Matthieu Segret : Cela change beaucoup l'approche par rapport à ce que je connais, étant développeur Ruby on Rails. Pour la partie administrateur, le déploiement se fait à chaque fois que l'admin modifie un contenu. Est-ce qu'il y a des inconvénients, par exemple sur l'invalidation du cache de ton CDN ?

Konstantin Bifert : En réalité, il n'y a aucun problème. Netlify se charge de toute l'invalidation du cache pour toi, que ce soit pour les assets ou le texte. Pour le "build", quand tu soumets une modification, il y a un petit temps d'attente (environ 2 minutes) pour que le site soit reconstruit, contrairement à Rails où le rendu est immédiat côté serveur. Mais pour un client qui publie un article toutes les deux semaines, ce n'est pas une réelle limitation.

Matthieu Segret : Donc si je corrige une faute d'orthographe et que je valide, je dois attendre 2 minutes pour voir le résultat en ligne ?

Konstantin Bifert : Pour le site en ligne, oui. Mais il existe de nombreux CMS "headless" qui permettent d'avoir une prévisualisation immédiate (preview) en live pour voir le rendu avant de lancer le build définitif. Techniquement, la partie admin ressemble à un site standard.

La partie dynamique et les services tiers

Matthieu Segret : J'ai l'impression qu'il y a deux aspects. D'un côté, la source de données (Markdown, Firebase, bases de données classiques) que l'on récupère au moment de la construction pour générer le HTML. De l'autre, si on a besoin d'interaction en live comme le paiement avec Stripe, cela se fait via des APIs externes ?

Konstantin Bifert : Tout à fait. Toute la logique dynamique s'exécute via du "Serverless". Une fois que ton application est hydratée en JavaScript, elle appelle des services tiers. Si tu as besoin de paiement, de traduction ou d'autres fonctions, tu branches des services comme Stripe, Snipcart, Firebase ou AWS. C'est l'avantage par rapport à un WordPress classique qui est très figé. Ici, c'est statique au départ, mais extrêmement dynamique via les APIs par la suite.

Quand utiliser la JAMstack ?

Ludwine Probst : Quand recommandes-tu cette approche ? Est-ce indiqué dans tous les cas ?

Konstantin Bifert : On peut l'utiliser dans énormément de cas, mais il y a des limites. Le cas d'usage le moins pratique serait un e-commerce avec des stocks qui bougent très rapidement. Si tu as 1 000 produits qui partent en 10 secondes, la JAMstack n'est pas adaptée car elle a besoin d'un temps de build. Pour du contenu très dynamique comme Twitter, ce n'est pas l'idéal non plus.

En revanche, pour un site comme Smashing Magazine (qui était sous WordPress avant), le passage à la JAMstack a permis un gain de performance phénoménal, environ 80 %. Ils ont pu centraliser leurs données (Shopify d'un côté, WordPress de l'autre auparavant) grâce à un CMS Headless comme Contentful ou Sanity.

Ludwine Probst : As-tu d'autres exemples de sites connus ?

Konstantin Bifert : PayPal a passé une partie de ses sites sous JAMstack. Vous pouvez aussi aller sur le site de Gatsby pour voir leur "showcase". Il y a de tout : des sites d'agences, du design, de la vente de produits. C'est très inspirant.

Frameworks et outils

Matthieu Segret : Quels sont les grands frameworks pour faire de la JAMstack ?

Konstantin Bifert :
- Si vous faites du React : Le plus connu est Gatsby, très orienté contenu. Il y a aussi Next.js, plus orienté "application" (si vous voulez faire un équivalent de Gmail par exemple).
- Si vous préférez Vue.js : Il y a Gridsome pour le statique, VuePress pour la documentation, et Nuxt.js pour le côté application.
- Pour Ruby : Il y a Jekyll.
- Pour Go : Hugo est extrêmement rapide.

Vous pouvez retrouver une liste quasi exhaustive sur le site StaticGen. Pour les CMS Headless, allez voir HeadlessCMS.org, vous y trouverez Netlify CMS, Strapi et bien d'autres.

Ludwine Probst : Quels sont les prérequis pour s'y mettre ? Faut-il bien connaître JavaScript ?

Konstantin Bifert : Pas forcément pour commencer. Il existe un outil appelé Stackbit. Vous choisissez un template, un générateur de site statique (Gatsby, Hugo, etc.) et un CMS Headless, et en trois clics il génère toute l'infrastructure pour vous. Vous n'avez pas besoin d'écrire une seule ligne de code pour avoir un site fonctionnel et éditable. C'est un peu le "WordPress.com" de la JAMstack. Ils ont même présenté un outil à la JAMstack Conf de San Francisco qui permettra d'éditer le texte directement sur le site, ce qui mettra à jour le CMS et relancera le build automatiquement.

Ludwine Probst : Et pour le client final, c'est aussi simple que WordPress ?

Konstantin Bifert : Pour l'utilisateur qui édite le contenu, c'est identique. Il poste son article ou ses photos, clique sur "Build" et c'est tout. L'énorme avantage est aussi financier : vous ne payez pas de serveur. Netlify ou GitHub Pages permettent d'héberger vos fichiers statiques gratuitement sans limitation. C'est sécurisé, rapide et robuste. Vous ne recevrez pas d'appel à 3 heures du matin parce que le serveur a crashé, car c'est une infrastructure gérée par des professionnels.

Ressources pour se lancer

Ludwine Probst : Si on veut se lancer, quels sont tes conseils ?

Konstantin Bifert :
1. Regardez la chaîne YouTube de la JAMstack Conf. Il y a des talks de grande qualité, notamment de Sarah Drasner ou Vitaly Friedman.
2. Rejoignez le Slack officiel de la JAMstack ou les communautés sur Twitter.
3. Essayez par vous-même, ne serait-ce que pour voir si l'approche vous plaît.

Ludwine Probst : Merci beaucoup Konstantin. J'espère que cela vous a donné envie de vous lancer dans de nouveaux projets. Vous pouvez retrouver toutes les ressources sur le blog Human Coders. Si vous avez aimé cet épisode, n'hésitez pas à le commenter et à le partager. À très bientôt pour un prochain épisode !