Qu'est-ce que le Jamstack ?

Qu'est-ce que le Jamstack ?

Le Jamstack est une approche d'architecture qui découple la couche d'expérience web des données et de la logique métier, c'est ainsi que jamstack.org le décrit aujourd'hui. Le nom signifiait à l'origine JavaScript, APIs et Markup, un terme inventé en 2015 par Matt Biilmann, alors PDG de Netlify. Dans le schéma classique, les pages sont générées à l'avance, servies depuis un CDN et rendues dynamiques par du JavaScript côté client qui appelle des API.

Fonctionnement

1. Build. Un générateur de site statique ou un framework transforme contenu et gabarits en fichiers HTML, CSS et JavaScript. Exemples : Hugo, Eleventy, Astro et Gatsby.
2. Diffusion. Les fichiers sont placés sur un CDN : le visiteur reçoit les pages depuis un point proche, sans attendre qu'un serveur les génère.
3. Appels d'API. Tout ce qui est dynamique, comme la recherche, le paiement, les commentaires ou un CMS, est un service tiers ou votre propre API, appelée depuis le navigateur ou au moment du build.

Exemple

Un site de documentation est construit à partir de fichiers Markdown à chaque commit et publié sur un CDN. La zone de recherche interroge une API de recherche hébergée et un formulaire de contact envoie vers un point d'accès serverless. Il n'y a aucun serveur d'application à patcher ou à dimensionner pour les pages elles-mêmes, mais plusieurs API dont le site dépend désormais.

Où en est le Jamstack aujourd'hui

Le terme est devenu plus rare. La page d'accueil de jamstack.org parle désormais d'une "composable architecture", n'explicite plus l'ancien acronyme et ne mentionne ni fichiers statiques ni CDN. Les idées sont partout, sous d'autres noms, et la frontière entre statique et dynamique s'est brouillée : des frameworks comme Next.js et Astro permettent de prérendre certaines routes et d'en rendre d'autres à la demande, et l'hydratation ajoute de l'interactivité au HTML précompilé. Voyez "Jamstack" comme une description utile d'une approche orientée statique et API, pas comme une spécification stricte.

Erreurs courantes

• Croire que c'est toujours plus rapide. Une page précompilée est rapide, mais un gros bundle JavaScript ou des API tierces lentes peuvent annuler ce gain.
• Oublier la durée du build. Un site de dizaines de milliers de pages peut mettre longtemps à être reconstruit après chaque changement de contenu.
• Considérer les API comme le problème d'un autre. Chaque API tierce est une dépendance qui peut être lente ou indisponible.
• Dire qu'il n'y a "pas de backend". Le backend est passé dans des services et des fonctions, il n'a pas disparu.

Jamstack, tests de charge et supervision

Des fichiers statiques sur un CDN ont rarement besoin d'un test de charge. Les parties qui en ont besoin sont les API et fonctions serverless derrière les formulaires, la recherche et le paiement : lancez un test de charge sur ces points d'accès et surveillez-les avec la supervision d'API. Lisez aussi notre article sur la façon dont l'architecture serverless change les tests de performance (en anglais).

Questions fréquentes

Que signifie Jamstack ?

JavaScript, APIs et Markup. L'acronyme est la définition d'origine, même si jamstack.org décrit aujourd'hui l'approche comme le découplage de la couche d'expérience web des données et de la logique métier.

Le Jamstack est-il la même chose qu'un site statique ?

Pas tout à fait. La génération statique est la voie classique, mais un site de style Jamstack appelle aussi des API pour les fonctions dynamiques, et les frameworks modernes peuvent rendre certaines pages à la demande.

Le Jamstack est-il mort ?

Le terme est moins employé, mais ses briques sont devenues courantes : pages précompilées, diffusion par CDN et services basés sur des API. Peu d'équipes le choisissent encore comme catégorie nommée.

Un site Jamstack est-il bon pour le SEO ?

Le HTML précompilé est facile à lire pour les moteurs de recherche et se charge souvent vite. Le classement dépend toujours de la qualité du contenu et du reste du site.