As modern web applications demand high performance, excellent SEO, and real-time interactivity, Next.js emerges as a full-stack React framework that empowers developers to choose the right rendering strategy for each page. Two of its core rendering modes—Static Site Generation (SSG) and Server-Side Rendering (SSR)—offer distinct advantages depending on the application's requirements.
In this advanced guide, we’ll dissect SSG and SSR in Next.js with technical explanations, use cases, code examples, performance insights, and a decision framework.
What is Static Site Generation (SSG)?
SSG pre-renders pages at build time, generating static HTML, JSON payloads, and assets that can be deployed to a CDN for ultra-fast global delivery.
How it Works:
- The
getStaticProps()
function is executed during the build process. - For dynamic routes,
getStaticPaths()
is also called to determine which paths to generate. - Output is stored as
.html
and.json
files in.next/
and deployed to static hosting.
Example:
// pages/blog/[slug].tsx
export async function getStaticPaths() {
const data = await fetchAll();
return {
paths: data.map(slug => ({ params: { slug } })),
fallback: 'blocking'
};
}
export async function getStaticProps({ params }) {
const post = await fetchPostBySlug(params.slug);
return {
props: { post },
revalidate: 60
};
}
Use Cases:
- Marketing pages
- Documentation
- Product listings (when content updates infrequently)
- Blog posts
Benefits:
- 🏎️ Blazing Fast Load Times via CDN
- 🔒 Reduced Server Load (no backend rendering per request)
- ✅ Reliable SEO since HTML is pre-rendered
- 💸 Low Operational Cost using platforms like Vercel or Netlify
Limitations:
- 🐢 Slow Builds for Large Sites
- ⚠️ Content Can Be Stale without frequent rebuilds or ISR
- ❌ Difficult to Personalize (e.g., per-user content or auth logic)
What is Server-Side Rendering (SSR)?
SSR pre-renders HTML on each request. Every time a user visits a page, Next.js executes the page’s getServerSideProps()
on the server.
How it Works:
- The HTML is dynamically generated at runtime.
- Data fetching, auth checks, and conditional logic are done per request.
- Useful for personalized, real-time, or data-sensitive content.
Example:
// pages/dashboard.tsx
export async function getServerSideProps(context) {
const session = await getSession(context.req);
if (!session) {
return {
redirect: { destination: '/login', permanent: false }
};
}
const dashboardData = await fetchDashboardData(session.user.id);
return {
props: {
user: session.user,
dashboardData
}
};
}
Use Cases:
- User dashboards
- Admin panels
- Search results
- Authenticated pages
- Real-time financial data or inventory
Benefits:
- 🔁 Always Up-to-Date content
- 🔐 Supports Auth & Personalization
- ✅ SEO-Friendly with server-rendered HTML
- 🧠 Rich Contextual Logic possible per request
Limitations:
- 🐢 Slower Time-to-First-Byte (TTFB) compared to SSG
- 💰 More Server Resources and higher cloud costs
- 📉 Poorer Performance Under Load without caching
- 🧩 Higher Operational Complexity (handling failures, retries, etc.)
Hybrid Rendering with Next.js
Next.js allows per-page rendering strategies, enabling hybrid architectures that combine SSG and SSR.
ISR: Incremental Static Regeneration
You can update statically generated pages after deployment using ISR:
export async function getStaticProps() {
const data = await fetchData();
return {
props: { data },
revalidate: 300 // Regenerates page every 5 minutes
};
}
Use Case: Updating product prices, blog comments, event schedules without full rebuilds.
** Middleware + Edge + SSR**
You can combine SSR with Next.js Middleware and Edge Functions for lower-latency personalization at the CDN level.
Performance Comparison
Metric | SSG | SSR |
---|---|---|
TTFB | ~10-50ms (from CDN) | 300ms–2s (depends on backend) |
SEO Support | ✅ Excellent | ✅ Excellent |
Personalization | ❌ Limited (via JS) | ✅ Native support |
Content Freshness | ❌ Stale unless ISR | ✅ Always fresh |
Complexity | ✅ Simple | ❌ More complex |
Scalability | ✅ Global CDN | ❌ Needs backend scaling |
Decision Framework
Question | If YES, Use |
---|---|
Does your content update in real-time or per-user? | SSR |
Can you precompute pages ahead of time? | SSG |
Do you need both speed and freshness? | ISR |
Are you building a marketing or blog site? | SSG |
Does your app rely on authentication or session? | SSR |
Is your site large (10k+ pages)? | Mix of SSG + ISR + SSR |
Conclusion
Next.js doesn't force you to pick just one rendering method—instead, it enables composability. Use SSG for static, high-performance pages. Use SSR where dynamic, personalized content matters. Use ISR to scale the benefits of both.
Modern Next.js apps often mix these strategies intelligently across routes, and even at the component level using React Server Components, Edge Functions, and streaming responses.
The real power of Next.js lies not in choosing SSG or SSR—but in knowing when and where to use them together
Top comments (0)