Full static export prioritizes simplicity and zero-server hosting but sacrifices dynamic updates and server-side features, while SSG with ISR maintains a server runtime to enable background content updates and preserve Next.js server capabilities
The fundamental trade-off between full static export (output: 'export') and standard SSG with ISR is whether you need a server runtime. Static export generates pure HTML/CSS/JS files at build time that can be hosted anywhere (even on Apache or S3), but you lose the ability to update content without rebuilding and sacrifice all server-side features . SSG with ISR keeps Next.js running on a Node.js server, enabling background page regeneration, on-demand updates via webhooks, and full access to Next.js features like middleware and API routes, at the cost of requiring a compatible hosting platform and more complex infrastructure .
Hosting requirements: Static export works on any static hosting (Apache, Nginx, S3, Cloudflare Pages) with no Node.js needed; ISR requires a Node.js server or platform like Vercel/Netlify that supports background functions
Content updates: Static export requires a full rebuild and redeploy for any content change; ISR updates pages in the background either on a timer or instantly via on-demand revalidation from CMS webhooks
Build time scaling: Static export builds the entire site at once, making it impractical for sites with hundreds of thousands of pages; ISR can build only critical paths at deploy time and generate the rest on-demand
Server features: Static export disables middleware, API routes, server actions, and image optimization (unless using external loader); ISR preserves all Next.js server capabilities
Dynamic routes: Static export requires
generateStaticParamswith all possible paths known at build time; ISR can usedynamicParams: trueorfallbackoptions to generate pages on first visit
Static export is ideal for truly static sites where content changes infrequently and a rebuild workflow is acceptable . This includes personal portfolios, marketing landing pages, documentation sites, and blogs where you can trigger rebuilds via CMS webhooks. The major advantage is hosting flexibility—you can deploy to cost-effective static hosting like S3+CloudFront, Apache, or Cloudflare Pages, often at near-zero cost even for high traffic . Static export also works well for offline-first PWAs where you want to precache all routes for offline access . However, you must accept that any dynamic functionality must be implemented client-side with separate API calls .
Content updates matter: With ISR, you can set
revalidate: 60for time-based updates or use on-demand revalidation via webhooks to publish CMS changes instantly without rebuilding the entire siteLarge scale sites: For sites with thousands or millions of pages, building everything at once becomes impractical. ISR lets you build only popular pages at deploy time and generate the rest on first visit
Need server features: If you need middleware for authentication/geolocation, API routes for backend logic, server actions for forms, or built-in image optimization, ISR keeps the Node.js runtime that enables these
Hybrid content: When some parts of pages are static but others need freshness, ISR combined with client-side data fetching gives the best balance
SEO-critical dynamic pages: ISR provides the SEO benefits of SSG with the ability to update content without waiting for rebuilds
ISR's background regeneration comes with inherent staleness windows. With revalidate: 60, users may see content up to 60 seconds old, and the first visitor after the window receives the stale page while regeneration happens in the background . This is acceptable for most content but not for real-time data like stock tickers or live scores. On-demand ISR solves this by triggering immediate regeneration via webhooks when content actually changes, but this requires more complex setup with your CMS or data source . The LRU cache limitation in self-hosted ISR can also cause pages to become permanently stale if evicted from memory before revalidation—a complex pitfall that doesn't exist with static export .
Static export dramatically simplifies hosting—you can deploy to any web server, object storage, or CDN, often at minimal cost even for high traffic . Many teams run large static sites on free tiers of Cloudflare Pages or Vercel's static hosting. ISR requires a platform that supports Next.js server features: Vercel (handles it seamlessly), Netlify, or self-hosted Node.js on a VPS/dedicated server . Self-hosted ISR adds operational complexity—you must manage the Node.js process, handle caching, and ensure background regeneration works reliably. However, ISR can reduce build costs for large sites since you're not rebuilding everything constantly .
Choose Static Export when: You can accept rebuild-on-publish workflow, content is truly static or changes infrequently, you want maximum hosting flexibility (Apache/S3/anywhere), you don't need middleware/API routes, and you're building a site under ~10,000 pages
Choose ISR when: Content updates need to appear without full rebuilds, you have a large site where building everything is impractical, you need server features (middleware, API routes), you want built-in image optimization, or you need SEO-friendly pages that can still update dynamically
Consider hybrid approach: Use static export for marketing pages and ISR for dynamic sections within the same app, or use client-side data fetching on top of static export for real-time needs
Check hosting constraints: If your organization mandates static-only hosting (e.g., AWS S3-only policy), static export is your only option regardless of feature needs