La Jamstack n'est rapide que si vous y veillez

Source : JAMstack is fast only if you make it so de Nicolas Hoizey

La Jamstack se présente souvent comme un excellent moyen de fournir des sites performants. C’est même le premier avantage répertorié sur jamstack.wtf, un guide¹ pour “comprendre le concept de Jamstack simplement, de manière à encourager d’autres développeurs à adopter ce workflow”. Mais trop de sites Jamstack sont encore trop lents.

Vous avez peut-être vu les diatribes fréquentes d'Alex Russell à propos de Gatsby :

Looking across the full set of traces, modern Gatsby seems to produce pages that take 2-3x as long as they should to become interactive.

This is not OK. Gatsby/NPM/React regressively tax access to content.

In less generous moments, I'd go as far as to say it's unethical.

— Alex Russell (@slightlylate) October 17, 2019

Gatsby est une cible facile (parmi tant d’autres) car il n’est actuellement pas optimisé pour être performant par défaut, malgré ce qui est présenté. Il est possible de corriger cela, notamment avec ce plugin, et je pense que de bons développeurs React peuvent améliorer les choses, mais cela devrait être le cas par défaut, et non après coup.

Eleventy est très différent, comme Zach Leatherman nous le rappelle dans Eleventy’s New Performance Leaderboard :

Eleventy n’effectue aucune optimisation particulière pour rendre vos sites plus rapides. Cela ne vous empêchera pas de créer un site lent. Mais Eleventy n’ajoute rien qui ralentisse votre site.

Le problème avec la plupart des sites Jamstack lents est qu’ils chargent tout un tas de JavaScript. N’oubliez pas que tout code JavaScript ajouté doit être envoyé au navigateur, qui nécessitera davantage de ressources pour le traiter. Cela impactera inéxorablement les performances.

Parfois, la génération côté serveur suffit pour obtenir des données depuis une API et servir le HTML à tous les visiteurs, ce qui est nettement plus performant.

Par exemple, swyx a écrit Clientside Webmentions à propos de l’implémentation de Webmention avec Svelte. Tout article faisant la promotion de Webmention et facilitant son adoption est le bienvenu ! Mais même si c’est une bonne démo de Webmention et Svelte, je ne recommanderais pas de le faire côté client.

Privilégier le côté serveur

Je préfère le faire sur le serveur.

Cela permet :

• D’appeler l’API webmention.io seulement au moment de générer le site, ce qui devrait être moins fréquent que la consultation des pages par les visiteurs.
• De mettre en cache le résultat des requêtes à webmention.io et l’horodatage de la dernière, afin que la prochaine requête demande uniquement les nouvelles webmentions.

Cela sollicite moins webmention.io, avec une unique requête simple par génération, alors que le client effectue une requête bien plus volumineuse (voire plusieurs, avec pagination) pour chaque page vue.

Par exemple :

• Mon site web a reçu 75 Webmentions en avril 2020. Je l’ai probablement généré une centaine de fois durant la même période, ce qui correspond à 100 requêtes à Webmention.io avec des réponses peu volumineuses.
• Pendant la même période, 3 746 pages de mon site web ont été vues (sous estimé, je continue à utiliser Google Analytics 🤷‍♂️), ce qui équivaudrait à 3 746 requêtes à Webmention.io avec des réponses volumineuses.

Utiliser la génération côté serveur pour récupérer les Webmentions offre de multiples avantages :

• La performance pour les utilisateurs est largement meilleure, avec du HTML déjà compilé sur le serveur et servi de manière statique.
• Beaucoup moins d’appels d’API, ce qui requiert beaucoup moins de temps de compilation et d’énergie.
• Tout le monde devrait savoir qu'Aaron Parecki propose l’impressionnant service webmention.io gratuitement, et la majorité des utilisateurs de Webmention l’utilisent aujourd’hui, et ne pas surcharger son API donne bien meilleure conscience.

Améliorer le côté client, s’il est indispensable

Si vous savez que vous recevez beaucoup de Webmentions très utiles que vous devez afficher à vos visiteurs, vous pouvez améliorer la liste générée côté serveur via le côté client.

Mais rappelez-vous que chaque JavaScript ajouté à la page a un coût, donc les quelques Webmentions supplémentaires doivent être vraiment utiles.

Alors, au lieu de le faire pour chaque page vue :

• Essayez d’attendre un peu après la génération du site avant de faire les appels API côté client. Garder l’horodatage de génération du site côté client via JavaScript, et attendez une heure, une journée, en fonction de la fréquence des Webmentions. Vous pouvez même utiliser l’« âge » de la page pour moins requêter webmention.io pour le contenu plus ancien, qui reçoit probablement moins de Webmentions, comme l’a fait Aaron Gustafson pour les appels côté serveur dans son plugin Jekyll.
• Gardez une trace des appels API, pour un utilisateur, dans le localStorage ou l’IndexDB, afin que vous ne répétiez pas ces appels tout de suite. Vous pouvez même utiliser un Service Worker pour mettre en cache les requêtes et leur horodatage.

Les appels à l’API uniquement côté client ont parfois plus de sens

Je suis d’accord que les Webmentions ne sont pas le cas d’usage le plus complexe pour expliquer que la plupart du temps vous devez appeler les API côté serveur au moment de la génération plutôt que côté client :

• Les Webmentions à afficher sont les mêmes pour tous les visiteurs.
• Ne pas générer les plus récentes n’est sûrement pas un problème.

Alors oui je comprends bien que de nombreux autres cas d’usage rendent les appels côté client nécessaires, ou meilleurs que ceux côté serveur.

Ce que je dis c’est que ça ne devrait pas être le cas par défaut.

Promouvoir la AJMstack Mstack

C’est aussi quelque chose que je n’aime pas vraiment dans la tendance actuelle de la Jamstack, promouvoir JavaScript et les API bien plus que le balisage (NDT : « balisage » peut se traduire par « Markup » en anglais).

Voici pour l’exemple ce que vous pouvez voir sur jamstack.wtf (simplifié) :

Comme suggéré par Yann, j’aimerais commencer par utiliser cette meilleure présentation :

Cela rend plus évident qu’il s’agit d’une pile de choses, très utile pour une « pile » (NDT : « stack » peut être traduit « pile » en français).

Mais j’aimerais suggérer cette modification :

Bien sûr, cela se lit AJMstack au lieu de Jamstack, donc je parie que je n’aurais pas de succès dans la promotion… 🤷‍♂️

Mais au final ça semble plus adéquat, et cela montre que JavaScript fait le lien entre les APIs et le balisage.

Cela permet de présenter cela comme une excellente plate-forme d’amélioration progressive, car nous pouvons commencer avec du bon vieux (ai-je entendu « ennuyeux » ?) HTML…

Voici la Mstack :

Assurez-vous déjà que cette « couche » soit au top, et ensuite améliorez-la avec du JavaScript et des APIs au besoin.