What is Jamstack?

What is Jamstack?

Jamstack is a web architecture where the frontend is decoupled from backend services and served as pre-built static assets from a CDN. The name originally stood for JavaScript, APIs, and Markup — coined by Netlify CEO Mathias Biilmann around 2015, though the acronym was officially dropped in favor of "Jamstack" as a proper noun in 2020. The core idea: instead of generating HTML on every request via a traditional server, you pre-render pages at build time and hydrate dynamic behavior client-side through APIs and serverless functions.

Sites built this way routinely score 90+ on Lighthouse performance audits. No server round-trip for the initial HTML. We've shipped this on 50+ projects. It's our default architecture for marketing sites, docs, and content-heavy platforms where page speed and SEO directly drive revenue.

How it works

Jamstack separates concerns into three layers:

1. Build step — A static site generator (Next.js, Astro, Hugo, etc.) pulls content from a headless CMS or data source and outputs HTML, CSS, and JS files at build time.
2. CDN delivery — Those pre-built files are deployed to a global CDN (Vercel Edge Network, Cloudflare Pages, Netlify Edge). No origin server processes requests — the CDN serves cached assets directly.
3. Dynamic layer — Anything that can't be pre-rendered (auth, form submissions, personalized content) is handled client-side via APIs or serverless functions. These run at the edge or on-demand.

Here's a simplified next.config.js for a Jamstack Next.js site using static export:

// next.config.js
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true, // required for static export
  },
};
module.exports = nextConfig;

With Astro (our preferred framework for content sites as of 2026), the default output mode is already static:

// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  output: 'static', // default — full Jamstack
});

The architecture's evolved. Pure static-only Jamstack had a rebuild problem. A 10,000-page site could take 20 minutes to build after a single content change. Incremental Static Regeneration (ISR), introduced in Next.js 9.5 (July 2020), solved this by regenerating individual pages on-demand. Astro 4.x added similar on-demand rendering capabilities.

When to use it

Jamstack is the right call when:

• SEO matters — Pre-rendered HTML is immediately crawlable. No client-side rendering delays.
• Traffic is bursty — CDN-served static files handle traffic spikes without scaling servers.
• Content changes are editorial, not real-time — Blog posts, docs, landing pages, product marketing.
• Security is a concern — No exposed server or database reduces the attack surface dramatically.

Don't use Jamstack when:

• Your app is highly interactive and personalized per user — Dashboards, social feeds, real-time collaboration. SSR or a full SPA makes more sense here.
• Content updates need to appear within seconds — ISR helps, but if you need sub-second content freshness, you're fighting the architecture.
• You have 100k+ pages and no ISR strategy — Full rebuilds at that scale are painful.

Jamstack vs alternatives

The honest take: Jamstack isn't always simpler. The build pipeline, headless CMS integration, and preview workflow add complexity that a monolithic CMS doesn't have. But for sites where performance and SEO are non-negotiable, the trade-off is worth it every time.

Real-world example

We rebuilt a B2B SaaS company's marketing site from WordPress to Astro 4 + Sanity CMS, deployed on Vercel. The WordPress site had a Time to First Byte (TTFB) averaging 1.8 seconds on their shared host. After migrating to Jamstack, TTFB dropped to under 50ms globally. Every page was pre-rendered and edge-cached. Lighthouse performance scores went from the low 60s to consistent 98-100.

Organic traffic increased 34% over 90 days. Partly SEO improvements, partly because Core Web Vitals (LCP, CLS, INP) all moved into "good" thresholds. Build times for their ~400-page site averaged 45 seconds.