Static Sites Are Back: Why We Export Next.js Instead of Server-Rendering

In 2022, we were all-in on server-side rendering. Every Next.js project used getServerSideProps or the App Router with server components. We deployed to Vercel or spun up Node servers on Railway. We dealt with cold starts, server-side caching layers, edge function limitations, and TTFB variability. We told ourselves this was the modern way.

Then we started tracking actual performance metrics across our projects and realized something awkward: our static exports were consistently faster than our server-rendered pages. Not by a little. By a lot. Median TTFB for our SSR projects was 380ms. Median TTFB for static exports behind a CDN was 18ms. That is not a typo.

So we did what any pragmatic team would do. We stopped defaulting to SSR and started defaulting to static export. Eighteen months later, roughly eighty percent of our Next.js projects ship as static exports, and we have not regretted it once.

Let us be clear about what we mean. Next.js has a built-in static export mode (output: 'export' in next.config.js) that generates plain HTML, CSS, and JavaScript files. No Node server required. You drop these files on any CDN -- Cloudflare Pages, Netlify, S3 plus CloudFront, even a cheap shared host -- and they just work. Every page is pre-rendered at build time. Client-side JavaScript hydrates the page and handles dynamic behavior.

The immediate objection is always: "But what about dynamic data?" Fair question. Here is how we handle it.

For data that changes infrequently (blog posts, marketing pages, product catalogs, documentation), we pre-render at build time and trigger rebuilds when content changes. Most headless CMS platforms support webhook-triggered builds. Our average rebuild time for a 200-page site is forty-five seconds on Cloudflare Pages.

For data that changes frequently (user dashboards, real-time feeds, search results), we fetch client-side using SWR or TanStack Query. The initial page load shows a shell or skeleton state, then data populates within 100-200ms. For most applications, this is indistinguishable from SSR to the end user.

For data that requires authentication, we use the same client-side fetching pattern. Server-rendered auth pages were never a great pattern anyway -- they require careful cookie management, introduce security surface area on the server, and make caching nearly impossible. Client-side auth with token-based APIs is simpler and more secure.

The projects where we still use SSR are specific and rare: SEO-critical pages that display user-generated content (think marketplace listings that need to be crawled), applications that require server-side API key protection on every page load (not just auth-gated sections), and sites where the first contentful paint absolutely must include dynamic data (financial dashboards where showing stale data is worse than showing nothing).

The cost savings are significant. A typical server-rendered Next.js project on Vercel costs our clients between fifty and three hundred dollars per month depending on traffic. The same project as a static export on Cloudflare Pages costs zero to five dollars per month. Over a year, that is six hundred to thirty-five hundred dollars saved on hosting alone. For SMB clients, that matters.

But hosting cost is the small win. The big win is operational simplicity. A static site has no server to crash, no Node process to monitor, no cold starts to optimize around, no server-side memory leaks to debug, no SSR-specific bugs where hydration mismatches cause layout shifts. Our static projects have essentially zero operational overhead after deployment. We set them up, they run, we move on.

The developer experience also improved. When you remove the server rendering layer, you remove an entire category of bugs. No more "this works in development but breaks in production because the server environment differs." No more wrestling with which code runs on the server versus the client. No more useEffect cleanup dances to handle SSR hydration. The mental model simplifies: everything runs in the browser, period.

Build times are the one genuine trade-off. A statically exported site must pre-render every page at build time. For a site with ten thousand pages, that can take several minutes. We have found this acceptable for every project we have worked on, but we acknowledge that sites with hundreds of thousands of pages need a different approach (incremental static regeneration or on-demand ISR, both of which require a server).

Our current stack for static projects looks like this: Next.js with static export for the framework, Cloudflare Pages for hosting, a headless CMS (usually Sanity or Payload) for content, client-side data fetching with TanStack Query for dynamic data, and Cloudflare Workers for any edge logic we need (redirects, A/B testing, geo-based content).

One pattern we particularly like: using Cloudflare Workers as a thin API proxy in front of the client. The static site makes requests to a Workers endpoint, which handles API key injection, rate limiting, and response caching. This gives us server-side security for API keys without requiring a full server-rendered application.

The industry trend supports this direction. Cloudflare, Netlify, and AWS are all investing heavily in edge infrastructure that favors static-first architectures. Vercel itself added better static export support in recent Next.js versions. The React team's server components push is interesting technically, but for the majority of web applications -- marketing sites, SaaS dashboards, content platforms, e-commerce storefronts -- static export with client-side hydration delivers better real-world performance at a fraction of the complexity.

Our advice: before reaching for SSR, ask yourself what specifically requires server rendering. If the answer is "SEO," check whether your content is truly dynamic or just infrequently updated. If the answer is "performance," measure actual TTFB versus a CDN-served static page. If the answer is "that is just how Next.js works," you are leaving money and simplicity on the table. The humble static site never really went away. It just got a fresh coat of React paint.