Jamstack

Jamstack is a web architecture built on three things — JavaScript (for interactivity), APIs (for dynamic data and services), and Markup (pre-built static HTML, usually generated at build time) — that decouples the front-end from a traditional backend server. Instead of generating each page on request from a server-and-database (the WordPress/monolith model), Jamstack pre-builds pages and serves them as static files from a CDN edge, calling APIs for anything dynamic. The term was coined by Mathias Biilmann, CEO of Netlify, in 2015, to name the pattern developers were already adopting.

How it works and why it wins: pages are pre-rendered at build time (by static site generators — Next.js, Astro, Hugo, Gatsby, Eleventy) into static HTML, deployed to a CDN, and served from the edge close to the user — so there's no server-rendering-per-request, no database query in the request path, and the page arrives fast. Dynamic needs (forms, search, commerce, auth, personalization) are handled by JavaScript calling APIs and serverless functions, not by a monolithic backend. The benefits that matter to marketers: speed (pre-built edge-served pages are fast by default — a CORE-WEB-VITALS advantage that helps both SEO and conversion), SEO-friendliness (the markup is in the HTML at build time, so it sidesteps the JAVASCRIPT-SEO render-gap that breaks client-rendered SPAs — content is crawlable on first fetch), security (no server-and-database in the request path means a smaller attack surface), and scalability (serving static files from a CDN scales trivially under traffic spikes). The honest trade-offs this entry must name: build times grow with site size (a million-page site rebuilding on every content change is a real constraint — incremental and on-demand builds, and the INCREMENTAL-STATIC-REGENERATION pattern, exist to address it), truly real-time or highly personalized content fights the pre-built model (you're calling APIs client-side, which can reintroduce the render-gap for that content), and the architecture adds build-pipeline and developer complexity a simple brochure site may not need. The strategic read: Jamstack is an excellent default for content-and-marketing sites where speed and SEO matter and content changes at a manageable cadence (blogs, docs, marketing sites, many e-commerce storefronts), and a worse fit for highly dynamic, real-time, or deeply personalized applications — and the modern frameworks blur the line by mixing static, server, and edge rendering per route (so 'Jamstack' has evolved from strict static into a hybrid spectrum).

Jamstack matters most for marketing sites, blogs, documentation, and content-driven commerce where page speed, SEO, security, and scale are priorities and content updates at a manageable pace — exactly the sites where the pre-built, edge-served, crawlable-by-default model pays off in Core Web Vitals and JavaScript-SEO safety at once. It matters less for highly dynamic, real-time, or deeply personalized applications where the pre-built model fights the use case. The discipline is matching the architecture to the content's dynamism (static-and-edge for content that's stable enough to pre-build, server-and-API rendering for what genuinely must be real-time), using incremental builds to manage scale, and treating the modern hybrid frameworks' per-route rendering choices as the real decision rather than a dogmatic all-static stance.

Mathias Biilmann coined 'Jamstack' in 2015 to name the decoupled, static-first architecture Netlify was built around - front-ends talking to APIs with static delivery at the edge - reviving static sites in modern form; the definition has since evolved from strict static into a hybrid spectrum as frameworks mix static, server, and edge rendering per route.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where jamstack is a core concern: