Static Sites & Deployment

Jamstack

Definition

Jamstack names a way of splitting a website up. The markup is produced at build time rather than assembled per request by a server, so what gets published is plain HTML, CSS, JavaScript and images that any host can serve. Whatever genuinely has to be live — a search box, a comment thread, a checkout, a login — is handled in the browser by JavaScript talking to APIs, whether third-party services or small functions of your own. The term was coined around 2015 by the founders of Netlify and became shorthand for the generation of tooling that followed: static site generators, headless content APIs, functions running at the edge. Its use as a label has cooled since, partly because the boundaries blurred once frameworks began rendering on the server again. The underlying instruction — pre-build what you can, fetch the rest — has aged better than the word.

Why It Matters

Serving a file is cheaper and steadier than running a program. A pre-built page can be held on a CDN and returned in tens of milliseconds, where a page assembled by a database-backed CMS on each request typically costs hundreds and falls over under load. The security position changes as well: there is no application server on the public internet to exploit and no database sitting behind it, so a whole category of attack has no surface to aim at. The cost is real though. Anything genuinely per-user must be solved in the browser or by an API, and rebuilding a 20,000-page site to change one footer link can take longer than editing a template on a dynamic site.

How It Works

At build time a generator turns content — Markdown files, entries pulled from a headless CMS, rows from a spreadsheet — into one HTML file per page, with assets bundled and hashed. Those files go to static hosting and are distributed to edge locations, where they are served with long cache lifetimes. The visitor's browser receives finished markup on the first request, which is why the first paint is quick. JavaScript on the page then calls APIs for the parts that could not be pre-built: stock levels from a commerce endpoint, a form post to a form-handling service, results from a hosted search index. Content changes trigger a rebuild, either on a schedule or by webhook from wherever the content lives.

Real-World Example

A cycling club keeps a 400-page archive of past rides. Each ride is a Markdown file; a generator turns the lot into HTML, and the built folder — around 18 MB including photographs — is uploaded as a zip to 99helpers and served at 'northvale-rides.99helpers.site'. Nothing on the site runs on a server. The two live pieces are the sign-up form, which posts to a third-party form service, and the member count in the footer, fetched from a small JSON endpoint when the page loads.

Common Mistakes

  • Treating Jamstack as a rule that forbids servers — the point is to pre-build what can be pre-built, not to ban APIs or functions
  • Pre-rendering pages that depend on per-user data — every visitor is then served the first visitor's version until the page is rebuilt
  • Choosing it for a catalogue of half a million pages that changes hourly — the rebuild becomes longer than the interval between changes

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →