DEV Community

Yunhan
Yunhan

Posted on

Why I Chose Next.js Static Export Over SSR for a Content-Heavy Site

#javascript #nextjs #webdev #performance

When building BabyNamePick, I had a choice: server-side rendering (SSR) or static export. I went with output: "export" in Next.js, and here's why that was the right call.

The Use Case

BabyNamePick is a baby name discovery tool with:

  • 2,000+ name entries across 46 cultural origins
  • 125+ blog posts
  • 26 letter index pages
  • 50+ category pages
  • An AI name generator (client-side API call)

Total: ~3,400 pages. All content is deterministic — the same data produces the same pages every time.

Why Static Won

1. Hosting Cost: $0

Static files on Vercel's free tier. No server compute, no cold starts, no scaling concerns. For a side project that might take months to generate revenue, this matters.

2. Performance

Every page is pre-built HTML. Time to First Byte is essentially CDN latency — typically under 50ms. No server rendering, no database queries, no waiting.

Lighthouse scores (typical page):
- Performance: 95-100
- Accessibility: 95-100
- Best Practices: 100
- SEO: 100
Enter fullscreen mode Exit fullscreen mode

3. Reliability

Static files don't crash. There's no server to go down, no database connection to drop, no memory leak to debug at 3 AM. The site has had 100% uptime since launch.

4. Build-Time Data Processing

All the heavy lifting happens at build time:

// This runs once during build, not on every request
export async function generateStaticParams() {
  const names = await getNames();
  return names.map(name => ({
    slug: name.name.toLowerCase().replace(/\s+/g, '-')
  }));
}
Enter fullscreen mode Exit fullscreen mode

The Tradeoffs

Build Time

3,400 pages take a few minutes to build. Adding more names means longer builds. At some point (maybe 10,000+ pages), this could become painful.

No Real-Time Data

The AI generator works client-side (API call), but everything else is frozen at build time. Adding a new name requires a rebuild and deploy. For our use case, that's fine — we batch name additions.

No User-Generated Content

Comments, reviews, user submissions — anything dynamic needs a separate solution. We don't have these features yet, but when we do, they'll need an API layer.

The output: "export" Gotcha

One thing that tripped me up: output: "export" in Next.js disables some features:

  • No API routes (use external APIs instead)
  • No middleware
  • No ISR (Incremental Static Regeneration)
  • No server components that fetch at request time

For a content site, none of these are dealbreakers. But if you need any of them, static export isn't for you.

// next.config.ts — this one line changes everything
const nextConfig = {
  output: "export",
  // ... other config
};
Enter fullscreen mode Exit fullscreen mode

When to Choose Static Export

✅ Content doesn't change per-request
✅ You want zero hosting costs
✅ Performance is critical (SEO, user experience)
✅ You value simplicity and reliability

❌ You need real-time personalization
❌ Content changes every few minutes
❌ You need server-side authentication
❌ You have 100,000+ pages (build times)

Results

After a month live:

  • Zero downtime
  • Sub-50ms TTFB globally
  • $0 hosting cost
  • Google indexing 80%+ of pages
  • Growing organic traffic from cultural name searches

For a content-heavy site with deterministic data, static export is hard to beat.

BabyNamePick is a free AI baby name generator. 2,000+ names, 46 cultures, no signup required.

Top comments (0)