Static Site Generation (SSG) builds pages at deploy time for the fastest possible delivery. Server-Side Rendering (SSR) builds pages on each request for fresh, personalized content. Incremental Static Regeneration (ISR) blends both by pre-building pages and refreshing them in the background. Use SSG for marketing sites and blogs, SSR for dashboards and auth-gated pages, and ISR for large catalogs that change often.
Comparison Table at a Glance
Each rendering strategy makes a different set of tradeoffs. The table below summarizes the practical differences across the criteria that matter most when picking one for a production project.
| Criteria | SSG | SSR | ISR |
|---|---|---|---|
| First-byte speed | Fastest (pre-built HTML on CDN) | Slowest (renders per request) | Fast (cached HTML, periodic refresh) |
| Content freshness | Stale until rebuild | Always fresh | Fresh within revalidation window |
| Build complexity | Low to moderate | Moderate | Moderate to high |
| Infrastructure cost | Cheapest (static hosting) | Highest (runtime server) | Moderate (mix of CDN and compute) |
| Scaling profile | Linear with CDN | Linear with concurrency | Linear with CDN |
| Personalization | None at render time | Full per-user output | Limited (segments via cookies) |
| SEO crawlability | Excellent | Excellent | Excellent |
| Best for | Marketing, docs, blogs | Dashboards, account pages | Catalogs, news, large content sites |
What Is Static Site Generation (SSG)?
Static Site Generation produces complete HTML files during the build step. The framework crawls every route, runs your data fetching code once, and writes finished HTML, CSS, and JavaScript to disk. Those files get uploaded to a Content Delivery Network and served directly to users. No server runs your code at request time.
The result is the fastest possible response. A request hits the nearest edge node, the CDN returns cached HTML in tens of milliseconds, and the browser begins painting immediately. SSG works beautifully when content does not need to be personalized and changes at a predictable cadence. Documentation sites, marketing pages, blog archives, and changelog pages are textbook fits. The tradeoff: every content change requires a rebuild and redeploy.
What Is Server-Side Rendering (SSR)?
Server-Side Rendering generates HTML on demand. When a request arrives, a Node.js process executes your page component, runs the data fetching, renders the React tree to a string, and sends the resulting HTML to the browser. The browser then hydrates the page with JavaScript so interactivity works.
The advantage is freshness and personalization. Every response can include user-specific data, fresh database queries, or content that changed two seconds ago. A logged-in dashboard or a checkout page that needs the current cart both benefit from running on the server at request time. The cost is latency and infrastructure. Cold starts on serverless functions can add 200 to 800 milliseconds to the first request, and SSR makes Time to First Byte the bottleneck.
What Is Incremental Static Regeneration (ISR)?
Incremental Static Regeneration is a hybrid model that Vercel popularized through Next.js. Pages are built statically (like SSG) but the framework lets you set a revalidation window. When a request arrives for a stale page, the CDN serves the cached version immediately, then quietly rebuilds the page in the background. The next request gets the fresh copy.
This solves the rebuild problem. You no longer need to rebuild 50,000 pages every time one product changes. ISR also supports on-demand revalidation through webhook triggers, so when your CMS publishes a change, it can immediately invalidate specific pages. This is how large e-commerce sites and news publishers keep millions of pages near-fresh without grinding builds to a halt.
Performance Comparison
The performance story breaks down into three measurements: Time to First Byte (TTFB), Largest Contentful Paint (LCP), and scalability under load.
TTFB. SSG wins decisively. A pre-built page served from a CDN edge node returns its first byte in 20 to 80 milliseconds. ISR matches this when the cached version is served. SSR typically lands at 200 to 1,200 milliseconds, with cold starts pushing the upper end higher.
LCP. Because the largest visual element usually lives in the initial HTML, TTFB heavily influences LCP. SSG and ISR pages routinely hit LCP under 1.5 seconds. SSR pages often land between 2.0 and 3.5 seconds unless the server is geographically close to users.
Scalability. Static files scale to any traffic level a CDN can handle. SSR requires running compute for every request, so a viral traffic spike means scaling functions fast enough to absorb concurrency. ISR sits in the middle: most requests hit the cache, only a small fraction trigger background rebuilds.
SEO Comparison
All three approaches produce server-rendered HTML that search engine crawlers can read directly. The Googlebot of 2026 handles JavaScript-rendered content well, but it always prefers HTML it can index on the first pass. SSG, SSR, and ISR all satisfy that requirement.
The differences show up in two places: freshness signals and crawl efficiency. SSR sends fresh content on every crawl, ISR matches that within its revalidation window, and SSG only updates when you rebuild. Crawl efficiency matters at scale: a CDN-served static page returns instantly to Googlebot. A slow SSR endpoint can throttle crawl budget because Googlebot reduces request rate when origin response times climb.
Dynamic Content Handling
This is where SSR earns its place. Personalization, authentication, and per-user state all require executing code with knowledge of the current request. A logged-in user needs their account name in the header. A cart needs the items the user added two seconds ago. An admin dashboard needs database queries that no anonymous crawler should ever trigger.
SSG and ISR can support dynamic behavior through client-side fetching after hydration. The static shell loads instantly, then JavaScript calls an API to populate user-specific elements. This works for non-critical personalization (recommendations, A/B variants) but introduces a content flash. The cleaner pattern in 2026 is a hybrid: SSG for the public shell, edge functions for personalized fragments, and SSR only for routes that genuinely need per-request HTML.
Cost and Infrastructure
SSG has the cheapest unit economics. Static files on a CDN cost pennies per million requests, and build minutes scale with site size, not traffic. A high-traffic blog often costs less to host than its domain name.
SSR shifts cost to runtime compute. A site doing 10 million SSR requests per month with 200-millisecond render times can easily run 500 to 1,500 dollars in compute alone. ISR sits between them: the first request to a stale page triggers a background regeneration, but the cached version serves to the user for free. For a catalog with long-tail traffic, ISR can serve 95 percent of requests from cache while keeping content within minutes of freshness. Pick the right hosting plan based on which mix your site needs.
When to Use SSG
Choose SSG when content does not change per user and rebuild times stay reasonable. The sweet spot is sites under 10,000 pages where updates can wait for the next deploy cycle.
- Marketing sites: Landing, product, pricing, and feature pages where every visitor sees the same content.
- Blogs and content sites: Editorial sites that tolerate a few minutes between publish and live.
- Documentation: Developer docs, knowledge bases, and reference manuals.
- Portfolios and brand sites: Sites where visual polish and instant load matter more than dynamic data.
When to Use SSR
Choose SSR when every response must be unique or fresh to the second. The cost is justified when personalization or live data is the product.
- Logged-in dashboards: Application interfaces showing user-specific data that cannot be cached.
- Authentication pages: Login, account, password reset, and other auth-gated flows.
- Real-time feeds: Notifications, activity timelines, and live trading data where staleness is unacceptable.
- Per-request personalization: Pages where the entire layout changes based on geography or account tier.
When to Use ISR
Choose ISR when you have many pages, changing content, and tolerance for some staleness. ISR shines at the scale where SSG rebuilds become painful and SSR compute costs become heavy.
- E-commerce catalogs: Product pages where price, stock, or imagery updates throughout the day across thousands of SKUs.
- News and media: Article pages that need to reflect editorial updates within minutes without rebuilding the entire site.
- User-generated content: Public profile pages, listings, or community pages where each entity has its own page.
- Localized variants: Sites with many country, language, or city pages that share structure but diverge in content.
Hybrid Strategies
Modern production sites rarely commit to one strategy across every route. A typical SaaS site might use SSG for the marketing pages, ISR for the blog and changelog, SSR for the logged-in dashboard, and a shared content source feeding the static and ISR routes.
The mental model: ship static by default, escalate to ISR when content frequency demands it, escalate to SSR only when per-request state is required. This sequence keeps performance high and infrastructure cost low while preserving full dynamic capability where the product actually needs it.
Common Mistakes With Each
SSG mistakes. Building a 30,000-page site with SSG and watching deploys take 45 minutes because every page rebuilds on every push (fix: ISR for the long tail). Another classic: putting personalized content behind a static shell, then surprising users with content that flashes in after hydration.
SSR mistakes. Running database queries inside the page component without caching, then watching TTFB balloon under traffic. Forgetting to set cache headers on SSR responses that could safely be cached for 60 seconds at the edge. Choosing SSR for marketing pages “just in case” and paying compute costs for content that never changes.
ISR mistakes. Setting revalidation windows too short and effectively turning ISR into SSR. Forgetting that the first user to hit a stale page sees the old version. Not setting up on-demand revalidation for events (like a published article) where the old version must disappear immediately.
Framework Examples
Next.js supports all three strategies. The App Router uses fetch caching and the revalidate option to control behavior per data fetch. The older Pages Router uses getStaticProps, getServerSideProps, and the revalidate field. Next.js is the most flexible of the major frameworks here.
Astro defaults to SSG and is the lightest option for content-heavy sites. SSR is opt-in through adapters for Node.js, Vercel, Netlify, and Cloudflare. Astro does not have native ISR but achieves similar results through cache headers and on-demand rendering with edge caching.
Nuxt (the Vue equivalent of Next.js) supports SSG, SSR, and ISR through route rules in the Nuxt config. The same project can ship some routes as static, others as server-rendered, and others as ISR with per-route revalidation. SvelteKit handles the split through adapters and per-route prerender, ssr, and csr export flags. Remix is SSR by default and leans on HTTP caching headers to achieve SSG-like performance, encouraging Cache-Control and CDN behavior to control freshness rather than separate APIs.
If you want a team to build this for you, the team at Framer Websites ships production sites using the rendering strategy that fits your traffic profile, not whichever one the framework defaults to.
Frequently Asked Questions
Is ISR always better than SSG?
No. ISR adds complexity and a small infrastructure overhead for background regeneration. For a site under 1,000 pages that rebuilds in under five minutes, plain SSG is simpler and the rebuild cost is negligible. ISR earns its complexity at scale, when full rebuilds become painful or when content needs to feel near-live without paying for SSR on every request.
Can I switch rendering strategies later without rewriting?
Mostly yes, especially in Next.js, Nuxt, and SvelteKit where the strategy is a per-route configuration. Switching from SSG to ISR is usually a one-line change. Switching from SSG to SSR is more involved because it requires the page to handle per-request context. Plan for SSG first and escalate as the content model demands.
Does SSR hurt SEO compared to SSG?
Not in terms of crawlability. Both produce HTML that search engines index on the first pass. The risk with SSR is performance: if your server is slow or far from the user, TTFB and LCP suffer, and Google does factor Core Web Vitals into ranking. SSR done well (cached at the edge, fast origin) competes with SSG.
How do I decide between SSG and ISR for a blog?
If you publish less than once a day and a full rebuild takes under three minutes, use SSG. If you publish multiple times a day or have more than 2,000 posts, ISR pays off. The breakpoint is roughly the moment full rebuilds become an operational concern.