Static-first: why content sites should prerender

A marketing site rendered in the browser is slower, harder to index, and easier to break than one prerendered to static HTML. For content, static-first is the safer default.

A content site has one job: load fast, be found, and stay up. A page rendered in the browser makes all three harder than they need to be. It arrives as an empty shell, then JavaScript fetches the content and draws it. Search and social crawlers see the shell first. A visitor on a slow device waits for the runtime before a single word appears. And the whole page depends on client code executing correctly, on every device, every time. For a marketing site, that is a great deal of machinery in exchange for very little.

Prerender at build, serve plain HTML

The alternative is to do the work once, ahead of time. At build, every route is rendered to a complete HTML document and served from a content delivery network. The browser receives a finished page, not a set of instructions for assembling one. Crawlers receive words, not an empty container. First paint becomes a function of the network, not of how fast a device can run your JavaScript.

Figure 1 · Static delivery

Content is rendered once at build time and served as finished HTML from the edge. The CMS and the build are inputs, not things the visitor waits on.

What you give up, and why it rarely matters

Static delivery trades away per-request rendering: the page is fixed until the next build. For content, that is not a real loss. A marketing page changes when someone publishes, not on every visit, and a rebuild on publish covers that. The genuine exceptions, live data and per-user personalization, are usually small parts of a page. They belong in isolated interactive islands, not as a reason to render the entire site in the browser.

What you gain

The gains are the things an organization actually cares about. Crawlable HTML, so the content can be indexed and cited. Fast first paint, because there is no runtime between the visitor and the words. Pages that cache at the edge, which cuts cost and absorbs traffic spikes. And far fewer ways to fail: a static document does not throw a runtime error on a device you never tested. Fewer moving parts is not a limitation here. It is the point.

The most reliable page is the one that is already rendered.

Static-first is the right default for anything whose content changes on a human cadence. Reach for browser rendering where the content is genuinely per-request, and keep it contained when you do. For everything else, ship the finished page.