There is a false choice most teams accept without noticing it: either editors get a friendly content system and the site renders content in the browser, or the site is fast static HTML and editing means touching code. You do not have to choose. The snapshot pattern gives editors a headless CMS and gives visitors a fully static site, by moving one thing: the fetch happens at build, not at request.
Fetch at build, not at request
At build time, the site pulls every published item from the CMS into a local snapshot, prerenders each page from that snapshot, and deploys plain HTML. The CMS becomes a build input rather than a runtime dependency. A visitor never waits on it. It can be slow, or down, without the site being slow or down, because by the time anyone loads a page, the content is already baked into it. Editors keep a proper writing interface; users keep a static site. Nothing about the two goals is actually in conflict.
The one tradeoff: publishing means rebuilding
Because content is baked at build, a CMS edit is not live until the next build runs. For most content sites this is a detail, not a problem. A team publishing a few times a week can trigger a build on publish and see the change live in minutes. The pattern only becomes the wrong tool when you need edits live in seconds, or when the content genuinely must differ per request. Name that requirement honestly before you decide, because it is the whole decision.
When it is the right default
The snapshot pattern fits content that changes on a human cadence, where being found and loading fast matter and per-request freshness does not: marketing sites, documentation, blogs, knowledge bases. That describes most content an organization publishes. For those, a build-time snapshot gives you the editing experience of a dynamic site and the performance, security, and resilience profile of a static one, with a single, well-understood tradeoff.
Make the CMS a build input, not a runtime dependency.
Static sites and editor-friendly content systems are usually presented as opposites. They are not. Move the fetch to build time, accept that publishing means a rebuild, and you get both. For content that changes on a human cadence, that is very close to the ideal shape.