Static Site

A static site is a bundle of HTML, CSS, and JavaScript files generated once at build time and served exactly as-is from a CDN. Nothing runs on a server when a visitor arrives. The page already exists, cached on an edge node near the user, so it loads fast and costs almost nothing to host. That is the entire pitch: precompute everything ahead of time, ship plain files, and skip the request-time server that most stacks lean on.

It is not a server-rendered site, where a machine assembles fresh HTML from a database on every single request. It is also not a single-page app that ships a blank shell and paints the content with JavaScript after the browser downloads and runs a bundle. With a static site the HTML is finished before the request ever lands. The confusion starts because modern frameworks blur all three, and Next.js will happily mix static, server-rendered, and client-rendered pages inside one project, sometimes on the same route.

Astro, which reached 1.0 in 2022 and shipped 5.0 in late 2024, is built around this model and sends zero JavaScript to the browser by default. Hugo, written in Go, compiles thousands of pages in under a second, roughly a millisecond per page. Eleventy earned a following for staying minimal, and Jekyll still powers the default GitHub Pages build. Static generation is an old idea, but the tooling finally got fast, flexible, and pleasant to live in.

On the hosting side, Netlify, Vercel, Cloudflare Pages, and GitHub Pages all serve these files straight from the edge, free for small projects. Pair the generator with a headless CMS like Sanity or Contentful and you get the standard production setup: an editor hits publish, a webhook triggers a rebuild, and the CDN serves the new version a couple of minutes later. Writers never open a code editor, and the running site stays nothing more than a folder of cacheable files.

Because the HTML arrives complete and the CDN sits milliseconds away, static sites tend to win on Core Web Vitals almost by accident. There is no server thinking time inflating your Time to First Byte, and no giant hydration bundle blocking the main thread, as long as you keep the JavaScript lean. This is why docs, blogs, and marketing sites default to static: the format hands you good scores before you optimize anything.

The catch is the rebuild. Change one price on one page and you rebuild and redeploy the whole site, because every page was frozen at build time. For a 50-page marketing site that is a 15-second CI job nobody notices. For a 40,000-page product catalog it becomes a 25-minute build that blocks every typo fix and every stock update, and that is exactly where pure static falls over.

Incremental Static Regeneration is the usual escape hatch. Next.js rebuilds individual pages on a timer or on demand, so you keep static speed without freezing content for hours at a stretch. The rule of thumb: reach for static when your content changes on the order of days, not seconds. Skip it outright when every visitor sees different data, like a dashboard, a cart, or a logged-in account page, where a real server earns its cost.

The category churns fast. Gatsby was the 2019 darling and faded hard by 2023 as its GraphQL-everything complexity outgrew its payoff. Astro took the crown by betting that most content sites need almost no client JavaScript at all. The newer move, Partial Prerendering, tries to end the static-versus-dynamic argument altogether by serving a static shell instantly and streaming the dynamic holes into it.

If you are choosing today, start by asking how often each page actually changes. Pages that update daily or weekly want static output. Pages that change per user or per second want a server. Most real sites are a mix, which is why the interesting question in 2026 is not static or dynamic, it is which parts of a single page belong in each camp.

A static site is a photograph, not a phone call: gorgeous and instant when the moment is fixed, useless the second you need it to answer back.