Il y a un faux choix que la plupart des équipes acceptent sans le remarquer : soit les rédacteurs ont un système de contenu agréable et le site rend le contenu dans le navigateur, soit le site est du HTML statique rapide et éditer veut dire toucher au code. Vous n'avez pas à choisir. Le patron snapshot donne aux rédacteurs un CMS headless et aux visiteurs un site entièrement statique, en déplaçant une seule chose : la récupération se fait au build, pas à la requête.
Récupérer au build, pas à la requête
Au moment du build, le site tire chaque élément publié du CMS dans un instantané local, prérend chaque page à partir de cet instantané, et déploie du HTML simple. Le CMS devient une entrée de build plutôt qu'une dépendance d'exécution. Un visiteur ne l'attend jamais. Il peut être lent, ou hors service, sans que le site le soit, car au moment où quelqu'un charge une page, le contenu y est déjà cuit. Les rédacteurs gardent une vraie interface d'écriture ; les utilisateurs gardent un site statique. Rien dans ces deux objectifs n'est réellement en conflit.
Le seul compromis : publier veut dire rebuild
Comme le contenu est cuit au build, une modification dans le CMS n'est pas en ligne avant le prochain build. Pour la plupart des sites de contenu, c'est un détail, pas un problème. Une équipe qui publie quelques fois par semaine peut déclencher un build à la publication et voir le changement en ligne en quelques minutes. Le patron ne devient le mauvais outil que si vous avez besoin de modifications en ligne en quelques secondes, ou si le contenu doit vraiment différer par requête. Nommez ce besoin honnêtement avant de décider, car c'est toute la décision.
Quand c'est le bon défaut
Le patron snapshot convient au contenu qui évolue à un rythme humain, où être trouvé et charger vite comptent et où la fraîcheur par requête ne compte pas : sites vitrines, documentation, blogs, bases de connaissances. Cela décrit l'essentiel de ce qu'une organisation publie. Pour ceux-là, un instantané au build vous donne l'expérience d'édition d'un site dynamique et le profil de performance, de sécurité et de résilience d'un site statique, avec un seul compromis bien compris.
Faites du CMS une entrée de build, pas une dépendance d'exécution.
Sites statiques et systèmes de contenu agréables aux rédacteurs sont d'ordinaire présentés comme opposés. Ils ne le sont pas. Déplacez la récupération au build, acceptez que publier veuille dire un rebuild, et vous obtenez les deux. Pour du contenu qui évolue à un rythme humain, c'est très proche de la forme idéale.