Skip to content
← All articles

Why Static Export Beats SSR for a Personal Blog

1 min read
next.jsarchitecturehosting

Every Next.js tutorial reaches for server-side rendering by default. For a blog that is almost always the wrong call.

What SSR actually buys you

SSR earns its cost when the page differs per request — a logged-in dashboard, a search result, a price that moves. A blog post is the same bytes for everyone. Rendering it on demand means paying for compute to produce an identical answer over and over.

The static export path

// next.config.js
module.exports = {
  output: 'export',
  images: { unoptimized: true },
}

That single flag turns next build into a folder of HTML. No Node process in production, no cold starts, no server bill. A CDN serves it from an edge node near the reader.

The trade you are making

Content changes require a rebuild. That is a real constraint, not a footnote:

  • Publishing is a deploy, not a database write.
  • Anything genuinely dynamic needs a client-side fallback.
  • Build time grows with page count.

For a site that publishes weekly, a two-minute rebuild is nothing. For a news desk shipping every four minutes, it is fatal. Know which one you are.

The escape hatch

Keep a client-rendered preview route so freshly published content is reachable before the next build lands. Readers coming from a share link get the post immediately; the prerendered version replaces it on the following deploy.