Next.js can produce a site in two broad ways. It can render pages ahead of time into plain HTML files, called a static export, or it can run a server that renders pages when they are requested. Both are good. Picking the wrong one costs either money or features, so we decide early.
The question that decides it
Ask this: does any page need to look different depending on who is asking, or on data that changes between deploys?
If every visitor sees the same page, and that page only changes when you publish, a static export is almost always the right choice. Marketing sites, documentation, portfolios and most blogs fall into this group.
What a static export gives you
- Speed. Files are served from a CDN close to the visitor, with no server work per request.
- Low cost. Static hosting is free or close to it, and a traffic spike does not change the bill.
- Fewer things to break. There is no server to patch, scale or restart.
Turning it on is one line in the config.
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
output: "export",
images: { unoptimized: true }, // the default image optimizer needs a server
};
export default nextConfig;Pages with dynamic routes, such as a blog post at /blog/[slug], must list every path at build time.
export const dynamicParams = false; // unknown slugs return 404
export function generateStaticParams() {
return getPosts().map((post) => ({ slug: post.slug }));
}What you give up
A static export has no server at runtime, so features that need one are unavailable.
| Needs a server | Static alternative |
|---|---|
| Per-user pages, logins, sessions | Client-side fetch to a separate API |
| Content that changes without a rebuild | Rebuild on change with a deploy hook |
| Default image optimization | Resize images at build time or use an image CDN |
| Redirects and headers set in code | The host's own redirect and header rules |
| Forms that write to a database | A form service or a small separate API |
When to use a server
Choose server rendering when pages depend on the request. Typical cases are a dashboard behind a login, a shop with live stock and prices, or search results that cannot be generated ahead of time.
A mixed approach is also common. Keep the public marketing site and blog static, and run the application on a separate server-rendered deployment under an app. subdomain. Each part then uses the cheapest model that fits.
A short checklist
- Is the content the same for every visitor? Lean static.
- Does it change more than a few times a day? Consider server rendering or frequent rebuilds.
- Does any page need a login or a database write? Plan a server or a separate API.
- Can the team rebuild and redeploy in minutes? If so, static is easy to live with.
Most sites we build begin as static exports. If a real need for a server appears later, the move is small, because the pages are already ordinary React components.