8 July 2026Otogrow2 min read#web#engineering

Static-First Sites, Explained

Why every public page on this site is pre-rendered, and when dynamic rendering earns its cost.

On this page

This site is the reference build for how we make marketing sites. Every public page on it is pre-rendered at build time. This post explains what that buys, what it costs, and where we deliberately break the rule.

What static-first means

A static page is HTML built once, ahead of time, and served as-is. There is no server work between the request and the response — no database query, no template render, no cold start. The page that exists is the page you get.

Dynamic rendering builds the page per request. It is the right tool when the content changes per viewer or per minute. It is the wrong default for a page that reads the same for everyone.

The numbers that matter

Speed is not taste. A page that loads in half a second converts better than the same page in three, and the gap is measured, repeatedly, across industries. Here is what the static-first decision looks like against the usual alternative:

MeasureStatic-firstServer-rendered per request
Time to first byteMilliseconds, from cacheHundreds of ms, plus compute
Traffic spike behaviourNothing changesServer bill and latency climb
Runtime dependenciesNoneDatabase, runtime, memory
Attack surfaceFilesA live application

What the config looks like

There is no trick to it. The interesting decisions are about what you leave out:

const nextConfig = {
  output: "standalone",
  images: { unoptimized: true },
  poweredByHeader: false,
}

Images ship as-is rather than waiting on a runtime transcoding server. On a small production box, that single decision removes the most common cause of a site falling over under load.

Where dynamic still pays

Static-first is a default, not a religion. Some things genuinely need the server:

  • Search, carts, and accounts — content that differs per viewer.
  • Admin screens — noindex, behind auth, never cached anyway.
  • Content that updates between builds, served with time-based or on-demand revalidation.

The discipline is scoping the dynamic parts to the component that needs them, never the whole page.

The test we hold client work to

View source. Run Lighthouse. Check the payload. A static-first site has nothing to hide behind — the performance you measure is the performance everyone gets, on every visit, at any traffic level.

Liked reading? Get a free consult.

Thirty minutes on your actual problem, no deck, no obligation.