What are the trade-offs between full static export (output: 'export') vs standard SSG with ISR?

Question

Accepted Answer

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 `generateStaticParams` with all possible paths known at build time; ISR can use `dynamicParams: true` or `fallback` options to generate pages on first visit // Full Static Export - next.config.js import type { NextConfig } from 'next'; const nextConfig: NextConfig = { output: 'export', // Generates 'out' directory with static files // Optional: change output directory // distDir: 'dist', // Images need unoptimized or external loader images: { unoptimized: true, // or use loader: 'custom' }, // These features are NOT available with static export: // - middleware.ts (ignored) // - API routes (app/api/*) // - server actions // - on-demand revalidation }; export default nextConfig; // SSG with ISR - next.config.js (no special output needed) import type { NextConfig } from 'next'; const nextConfig: NextConfig = { // Standard config - deploys to Node.js server // All Next.js features available images: { // Built-in optimization works domains: ['images.example.com'], }, }; export default nextConfig; // app/products/[id]/page.tsx - ISR page export const revalidate = 3600; // Revalidate every hour export const dynamicParams = true; // Generate non-pre-rendered paths on-demand export async function generateStaticParams() { // Only pre-render popular products at build time const products = await getPopularProducts(); return products.map(p => ({ id: p.id.toString() })); } **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 . // app/blog/[slug]/page.tsx - Static export with client-side dynamic data // All pages must be known at build time export async function generateStaticParams() { const posts = await fetch('https://api.example.com/posts').then(r => r.json()); return posts.map(post => ({ slug: post.slug })); } // This component runs at build time - content is fixed export default async function BlogPost({ params }: { params: { slug: string } }) { // This fetch happens at BUILD TIME, not request time const post = await fetch(`https://api.example.com/posts/${params.slug}`) .then(r => r.json()); return (

{post.title}

{post.content}

{/* Any real-time data must be client-side */}

); } // Client component for dynamic data 'use client'; function ClientSideComments({ postId }: { postId: string }) { const [comments, setComments] = useState([]); useEffect(() => { // This runs in browser after page loads fetch(`/api/comments?postId=${postId}`) .then(r => r.json()) .then(setComments); }, [postId]); return

{/* render comments */}

; } // Note: API routes don't work with static export! // You'd need a separate backend API hosted elsewhere **Content updates matter:** With

What are the trade-offs between full static export (output: 'export') vs standard SSG with ISR?

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

What are the trade-offs between full static export (output: 'export') vs standard SSG with ISR?

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

Scenario Questions

Follow-up Questions