Static Site Architecture and the Jamstack, Explained

Static site architecture means building your pages ahead of time and serving them from a CDN. The browser gets finished HTML. Any live data arrives later, through APIs, once the page is already on screen.

Jamstack is the name that architecture went by from 2015 onward. The term has since faded, but the pattern did not. It became the default way content sites get built. Draftbase fits that pattern as the API layer, serving MDX entries over REST or GraphQL.

What Is Static Site Architecture?

The idea is a split. Build work happens once. Serving happens millions of times.

A build step runs on your machine or in CI. It pulls content, renders every page, and writes HTML files. Those files go to a CDN.

From then on, a request never touches your code. An edge server hands over a file that already existed. There is no database query and no template render in the request path.

That is the whole performance argument. You cannot make rendering faster than not rendering.

The tradeoff is timing. Content changes only when a build runs. Publishing means waiting for a rebuild, which is covered in more depth in static vs dynamic websites.

What Does Jamstack Actually Mean?

The acronym stands for JavaScript, APIs, and Markup. Matt Biilmann and Chris Bach of Netlify coined it in 2015. (Wikipedia)

They needed a word. Modern web workflows had no short name to argue about in conversation, so they made one.

Each letter maps to a layer:

• Markup is pre-built HTML, generated at build time and served from a CDN.
• APIs supply anything live, called over HTTP from the browser or the build.
• JavaScript runs in the browser and wires the two together.

The core claim was decoupling. The display layer stops being tied to the data and business logic behind it. (Netlify)

That is what made it more than a static site generator trend. A hand-written HTML page is static. It is not Jamstack, because there is no API layer feeding it.

How Do the Pieces Fit Together?

Follow one page through the whole chain.

An editor publishes an entry in a CMS. The CMS fires a webhook. Your host starts a build.

The build calls the content API and gets back structured data.

const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
  headers: { Authorization: `Bearer ${process.env.DRAFTBASE_KEY}` },
});
const { items } = await res.json();

The build loops over those entries and writes one HTML file each. The files upload to a CDN. A visitor in Sydney gets the file from a Sydney edge node.

Anything that must be live stays out of that file. A search box, a comment count, a cart total: all fetched by JavaScript after load, or rendered on demand.

That last part is the piece people skip. Static architecture does not ban dynamic content. It moves dynamic content to its own layer, so one live widget cannot slow the whole page down.

What Happened to Jamstack?

Here is the part most explainers still get wrong. They describe Jamstack as a live movement. It is not one anymore.

Netlify dropped Jamstack from its homepage in October 2023. It now calls itself a composable web platform. (The New Stack) The Jamstack Community Discord closed. The annual State of Jamstack survey, which had run since 2020, ended.

Read that carefully before you conclude the architecture failed. It did the opposite.

Pre-rendering, API-first content, edge delivery, and decoupled front ends are now just how sites get built. They ship as defaults in Next.js, Astro, Nuxt, and SvelteKit. Nobody calls it Jamstack because nobody needs a word for the normal thing.

Netlify's own framing matches that. Composable became the broader term, aimed at architects thinking past the web layer. (The New Stack)

So the honest summary is a strange one. The term lost. The architecture won so completely it stopped needing a name.

This matters practically. Say you are judging tools by whether they claim "Jamstack." You are filtering on words from 2019. Judge the traits instead. Does it pre-render? Does it serve from an edge? Does content arrive over an API?

Where Does Dynamic Content Fit Now?

The original Jamstack answer was client-side JavaScript. Fetch it in the browser after the page loads.

That still works for small things. A view counter or a live price badge is fine to fetch on the client.

It ages badly at scale. Client fetches hurt loading metrics, and search engines see an empty slot where the content should be. Only 62% of mobile origins record a good LCP. (Web Almanac 2025)

Modern frameworks fixed this by adding a third option. A route can render on demand, on the server, while the rest of the site stays pre-built.

So the current shape is three tiers, not two:

Tier	Runs at	Good for
Pre-rendered	Build time	Posts, docs, marketing pages
On-demand render	Request time	Search results, per-user pages
Client fetch	After load	Counters, badges, live widgets

Put each piece of content in the cheapest tier that meets its freshness need. That single rule replaces most of the old Jamstack advice.

What Does This Mean for Your CMS?

Static architecture adds one hard rule. The CMS must be callable from a build step.

That sounds obvious. It rules out more tools than you would expect. A CMS that only ships a browser SDK, or that renders its own pages, cannot feed a build.

Three things to check before committing:

1. Is there a plain HTTP API with a server-side key?
2. Does it send webhooks on publish, so builds trigger themselves?
3. Is the content format portable, or a vendor-specific tree?

Draftbase answers those with a cached REST and GraphQL delivery API, webhooks on every entry event, and rich text stored as plain MDX strings. There is no vendor tree to convert if the front end changes later.

The headless CMS evaluation framework covers the rest of that checklist.

Is Static Site Architecture Right for Your Project?

Three signals say yes.

Your pages look the same for every visitor. Your content changes on a schedule, not by the second. Your traffic is spiky, or you want it to be cheap when it grows.

Three signals say no.

Most pages are personalized. Content must be exact at read time, like stock or prices. Nobody on the team wants to own a build pipeline.

Page count matters too, but less than people think. A few thousand pages build fine. Past that, look at incremental builds before giving up on the model.

Run the arithmetic once. Multiply pages by build time per page, then compare to how often someone publishes. That number decides more than any framework benchmark will.

Conclusion

Static site architecture is a timing decision. Build pages early, serve them from an edge, and pull live data through APIs. Jamstack was the name for that pattern, and the name is what expired, not the pattern.

Judge tools on behaviour, not on the label. Pre-rendering, an API-first content layer, and edge delivery are the traits that count.

For the content layer, Draftbase serves MDX over a cached API with publish webhooks built in. Hobby is free and Startup runs $49/mo. See the pricing page, or start with what a framework actually is.