## Understanding Rendering Strategies [Next.js](/courses/nextjs) rendering sounds complicated because you'll hear terms like: ```text SSG SSR ISR Dynamic Rendering Static Rendering Streaming Partial Prerendering ``` and after five minutes you're like: > "Bro, I just wanted to show a page." 😭 The good news? They all answer one basic question: > **When should this UI be generated?** Should [Next.js](/courses/nextjs) prepare it ahead of time? Should it generate it when the user visits? Should it cache it and occasionally refresh it? Or should part of the page be static while another part is generated live? That's what rendering strategies are really about. --- > **Definition: Rendering** > > Rendering is the process of turning your [React](/courses/reactjs) components and data into UI that can eventually be displayed by the browser. For example: ```jsx export default function Page() { return (

Hello Next.js

) } ``` Next.js needs to turn that [React](/courses/reactjs) component into something the browser can display. The important question is: ```text WHEN should Next.js do that work? ``` That's where rendering strategies come in. --- # The Traditional Mental Model Historically, Next.js rendering was commonly explained using three major strategies: ```text SSG SSR ISR ``` You should absolutely understand these terms because: - They're still widely used - You'll see them in interviews - Thousands of existing Next.js projects use them - They explain the fundamental trade-off between speed and freshness But modern Next.js has evolved beyond the idea that: ```text One page = exactly one rendering strategy ``` Modern [App Router](/courses/nextjs) applications can mix: ```text Static UI + Cached UI + Request-time UI ``` inside the **same route**. We'll first understand the classic concepts. Then we'll look at how modern Next.js combines them. --- # 1. Static Rendering / Static Site Generation (SSG) Static rendering means Next.js can prepare the page **before the user requests it**. Traditionally, this happens during: ```bash npm run build ``` Conceptually: ```text Build application ↓ Generate page ↓ Store generated result ↓ User visits ↓ Serve prepared result ``` No need to regenerate the entire page for every visitor. That's why static content can be extremely fast. --- ## Simple Static Page Example: ```jsx export default function AboutPage() { return ( <>

About Us

We build awesome software.

) } ``` There is: ```text No user-specific data No live database request No request-time information ``` So Next.js can prepare this content ahead of time. --- ## Static Rendering Flow Think: ```text npm run build ↓ Next.js renders /about ↓ Static output created ↓ Deploy ↓ User requests /about ↓ Prepared content returned ``` The server doesn't need to rebuild: ```text About Us ``` for user number: ```text 1 ``` then again for: ```text 2 ``` then again for: ```text 500,000 ``` The page is already prepared. Work smarter, not harder. 😎 --- # Why Static Rendering Is Fast Imagine 100,000 users request: ```text /about ``` With request-time rendering, your server may need to do work repeatedly. With static rendering: ```text Build once ↓ Reuse many times ``` Static output can also be distributed through caching infrastructure and CDNs depending on where you deploy. This can improve: - Response time - Scalability - Server load - Hosting costs - Reliability --- ## Best Uses for Static Rendering Static rendering is great for content that is the same for everyone. Examples: - Landing pages - About pages - Documentation - Portfolios - Terms and conditions - Marketing pages - Course lessons - Blog content that rarely changes Think: ```text Same content for everyone? ↓ Can prepare ahead of time? ↓ Static rendering is a strong candidate ``` --- # 2. Dynamic Rendering / Server-Side Rendering Now imagine you're building: ```text /dashboard ``` User A should see: ```text Welcome, Asif Revenue: $2,400 ``` User B should see: ```text Welcome, Sara Revenue: $8,900 ``` You obviously cannot generate one universal dashboard at build time. The result depends on the incoming request. That's where **request-time rendering** comes in. Traditionally, this is commonly called: **Server-Side Rendering (SSR).** --- ## How SSR Works Conceptually: ```text User requests page ↓ Next.js server runs ↓ Fetch fresh/request-specific data ↓ Render UI ↓ Return result ``` The important part is: ```text Rendering happens when the request arrives ``` instead of ahead of time. --- ## Traditional Dynamic Rendering Example In the previous App Router caching model, you may see: ```jsx export const dynamic = "force-dynamic" export default async function DashboardPage() { const response = await fetch( "https://api.example.com/live-data", { cache: "no-store" } ) const data = await response.json() return (

Live Price: {data.price}

) } ``` This communicates: > "Don't treat this as reusable static content. I need fresh request-time data." You'll still see this pattern in many existing Next.js projects. --- # What Kind of Data Needs Request-Time Rendering? Examples include: ```text User session Shopping cart Private dashboard Personal recommendations Request headers Cookies URL search parameters Real-time data ``` For example: ```jsx import { cookies } from "next/headers" export default async function Dashboard() { const cookieStore = await cookies() const session = cookieStore.get("session") return (

Session: {session?.value}

) } ``` The user's cookie doesn't exist when your application is being built. It only exists when that specific user sends a request. So some work needs to happen at request time. --- # Static vs Dynamic Rendering Basic mental model: ```text STATIC Build/preparation time ↓ Generate content ↓ Reuse result ``` versus: ```text DYNAMIC User requests page ↓ Generate request-specific content ↓ Return result ``` --- # Is Dynamic Rendering Always Slower? Not necessarily in a way users will notice. But dynamic rendering usually involves more request-time work. For example: ```text User Request ↓ Authentication ↓ Database ↓ Rendering ↓ Response ``` Static content may already be ready to serve. That's why the general rule is: > **Don't make something dynamic unless it actually needs to be dynamic.** But modern Next.js gives us an even better option: > **Don't make the whole page dynamic just because one tiny section needs dynamic data.** We'll get to that shortly. 🔥 --- # 3. Incremental Static Regeneration (ISR) Now imagine a product page: ```text /products/macbook-pro ``` The product description doesn't change every second. But the page might change: ```text Price Availability Description Images ``` occasionally. Pure static generation could become stale. Pure SSR might be unnecessary. Enter: **Incremental Static Regeneration — ISR.** --- ## What is ISR? ISR lets you reuse cached/static content and refresh it over time without requiring a complete application rebuild. Think: ```text Static speed + Periodic freshness ``` or basically: > "I want this page fast, but please don't keep showing the 2024 price until 2037." 😭 --- # Traditional ISR Example In many existing App Router applications you'll see: ```jsx export const revalidate = 60 export default async function BlogPost({ params }) { const { slug } = await params const post = await getPostBySlug(slug) return (

{post.title}

{post.body}

) } ``` Here: ```js revalidate = 60 ``` means the cached/static result can be refreshed over time. This is the **previous caching model** you'll still encounter in many codebases. --- # Modern Next.js Caching and ISR Modern Next.js with **Cache Components** uses a more explicit model. Enable it inside: ```js // next.config.mjs const nextConfig = { cacheComponents: true, } export default nextConfig ``` Then cached data can use: ```js "use cache" ``` and: ```js cacheLife() ``` Example: ```jsx import { cacheLife } from "next/cache" async function getPosts() { "use cache" cacheLife("hours") return db.post.findMany() } export default async function BlogPage() { const posts = await getPosts() return (

{post.title}

) } ``` Now Next.js knows: ```text This data can be cached ``` and: ```text This cache has a defined lifetime ``` --- # Why the New Caching Model Matters Previously you often thought about caching mainly through: ```js fetch() ``` options. Now Next.js can cache: - Database queries - API requests - Expensive computations - Components - Entire pages because: ```js "use cache" ``` applies to the [function](/javascript/functions-in-javascript) or component. For example: ```jsx import { cacheLife } from "next/cache" async function ProductList() { "use cache" cacheLife("hours") const products = await db.product.findMany() return (

{product.name}

) } ``` No: ```js fetch() ``` required. The database result itself can participate in the caching model. --- # 4. Partial Prerendering — The Modern Big Update Now we reach one of the biggest modern Next.js rendering improvements. Historically, developers often thought: ```text Is this page STATIC? ``` or: ```text Is this page DYNAMIC? ``` Modern Next.js says: > "Why not both?" 😎 With **Cache Components enabled**, Next.js supports a rendering model called: **Partial Prerendering (PPR).** --- > **Definition: Partial Prerendering** > > Partial Prerendering allows a route to have a prerendered static shell while dynamic parts of the page render and stream at request time. This means one page can contain: ```text Static content + Cached content + Live request-time content ``` at the same time. That is a huge architectural shift. --- # Example: E-Commerce Product Page Imagine: ```text /product/macbook-pro ``` It contains: ```text Header Product Name Product Description Reviews Your Cart Personal Recommendation ``` Not everything needs the same rendering strategy. You could have: ```text Header ↓ STATIC Product Description ↓ CACHED Reviews ↓ CACHED + REVALIDATED Your Cart ↓ REQUEST-TIME Personal Recommendation ↓ REQUEST-TIME ``` Same page. Different rendering behavior. --- # PPR Mental Model Imagine the page as: ```text ┌──────────────────────────────┐ │ Header │ ← Static ├──────────────────────────────┤ │ Product Information │ ← Cached ├──────────────────────────────┤ │ Reviews │ ← Cached ├──────────────────────────────┤ │ Your Cart │ ← Dynamic ├──────────────────────────────┤ │ Recommendations │ ← Dynamic └──────────────────────────────┘ ``` Next.js can prepare the reusable parts ahead of time. Then stream in the request-specific pieces when the user visits. So instead of: ```text One dynamic component ↓ ENTIRE PAGE MUST WAIT ``` you can get: ```text Static shell appears immediately ↓ Dynamic pieces stream in ``` Much nicer. --- # Streaming Dynamic Content with Suspense Suppose your dashboard contains: ```text Dashboard title Navigation User greeting ``` The title and navigation are reusable. The greeting depends on the user's cookie. You can isolate the dynamic part. ```jsx import { Suspense } from "react" import { cookies } from "next/headers" async function UserGreeting() { const cookieStore = await cookies() const name = cookieStore.get("name")?.value return (

Welcome, {name ?? "User"}

) } export default function DashboardPage() { return ( <>

Dashboard

Loading user...

} > ) } ``` Now Next.js can include: ```text Dashboard Navigation Loading user... ``` inside the prerendered shell. Then the personalized greeting can stream in at request time. --- # Important Modern Change: Dynamic APIs Don't Need to Make Everything Dynamic Older App Router teaching often said: > "If you use `cookies()`, `headers()`, or `searchParams`, the entire route becomes dynamically rendered." That was a useful mental model for the previous rendering system. But with **Cache Components**, Next.js can isolate runtime-dependent work behind: ```jsx ``` while keeping the [rest](/courses/expressjs) of the route prerendered. For example: ```text Page │ ├── Header STATIC │ ├── Product CACHED │ ├── Reviews CACHED │ └── User Cart ↓ cookies() ↓ REQUEST-TIME ``` This is much more powerful than: ```text cookies() ↓ Whole page dynamic ``` --- > **Interview Highlight** > > **Q: Does using `cookies()` automatically make an entire route dynamically rendered in modern Next.js with Cache Components?** > > No. Runtime-dependent content can be isolated inside a Suspense boundary and rendered at request time while static and cached parts of the route remain prerendered. That's a very modern Next.js interview answer. 😎 --- # 5. On-Demand Revalidation Time-based revalidation is useful. But sometimes you know **exactly when data changed**. Imagine you're using a CMS. An editor updates: ```text /blog/learn-nextjs ``` Should they wait: ```text 60 seconds? 1 hour? 24 hours? ``` No. If the application knows content changed, it can invalidate the cache immediately. That's **on-demand revalidation**. --- # Using `revalidatePath()` Example: ```js "use server" import { revalidatePath } from "next/cache" export async function updatePost(data) { await db.post.update({ // update post }) revalidatePath("/blog") } ``` Now Next.js knows cached content associated with: ```text /blog ``` needs refreshing. --- # Using Revalidation from a Route Handler You can also trigger path revalidation from an HTTP endpoint. ```js import { revalidatePath } from "next/cache" export async function POST(request) { const { path } = await request.json() revalidatePath(path) return Response.json({ revalidated: true }) } ``` Important detail: When `revalidatePath()` is called from a Route Handler, the path is marked for revalidation and the refresh happens when that path is next visited. So think: ```text CMS updates article ↓ Webhook hits Route Handler ↓ revalidatePath() ↓ Cache marked stale ↓ Next relevant visit gets refreshed content ``` Not: ```text revalidatePath() ↓ Launch 50 servers immediately ↓ Rebuild entire internet ``` Thankfully. 😄 --- # Tag-Based Revalidation Sometimes one piece of data appears on several pages. For example: ```text Blog posts ``` might appear on: ```text / /blog /dashboard /latest ``` Revalidating every URL individually would be annoying. You can tag cached data instead. Example: ```js import { cacheLife, cacheTag } from "next/cache" export async function getPosts() { "use cache" cacheLife("hours") cacheTag("posts") return db.post.findMany() } ``` Now that cached data has a label: ```text posts ``` Later you can invalidate content associated with that tag. This gives you much more targeted cache management. --- # Path Revalidation vs Tag Revalidation Think: ```text revalidatePath("/blog") ``` means: > "This route needs refreshing." While tag-based revalidation means: > "This DATA changed wherever it appears." That's an important distinction. --- # 6. `generateStaticParams()` — Prebuilding Dynamic Routes Static routes are easy. Next.js already knows: ```text /about /pricing /contact ``` But what about dynamic routes? Suppose you have: ```text /blog/[slug] ``` with these posts: ```text /blog/nextjs-routing /blog/react-hooks /blog/javascript-promises ``` How can Next.js know which dynamic URLs should be prerendered? That's what: ```js generateStaticParams() ``` does. --- > **Definition: `generateStaticParams()`** > > An [async](/javascript/promises-asynchronous-javascript) [function](/javascript/functions-in-javascript) used with dynamic route segments to tell Next.js which parameter values should be statically generated during the build. --- # Basic Example Structure: ```text src/app/ └── blog/ └── [slug]/ └── page.jsx ``` Then: ```jsx export async function generateStaticParams() { const posts = await db.post.findMany() return posts.map(post => ({ slug: post.slug })) } ``` Suppose your database returns: ```js [ { slug: "nextjs-routing" }, { slug: "react-hooks" }, { slug: "javascript-promises" } ] ``` Then Next.js knows it can prerender: ```text /blog/nextjs-routing /blog/react-hooks /blog/javascript-promises ``` --- # Rendering the Dynamic Page In modern Next.js: ```js params ``` is [asynchronous](/javascript/promises-asynchronous-javascript). So your page should use: ```jsx export default async function BlogPost({ params }) { const { slug } = await params const post = await db.post.findUnique({ where: { slug } }) return (

{post.title}

{post.body}

) } ``` Notice: ```js await params ``` That's the modern pattern. --- # `generateStaticParams()` Flow Conceptually: ```text Build starts ↓ generateStaticParams() ↓ Get known slugs ↓ [ "nextjs-routing", "react-hooks", "promises" ] ↓ Next.js prerenders those routes ``` Now your known content can be prepared ahead of user requests. --- # When Should You Use `generateStaticParams()`? It's useful when you know dynamic URLs ahead of time. Examples: ```text /blog/[slug] /products/[id] /courses/[course] /docs/[section] ``` Especially when: - You have popular known pages - Content changes infrequently - You want fast first loads - You have a manageable number of dynamic routes --- # Do You Need to Generate Every Possible Route? No. Imagine an e-commerce platform with: ```text 5,000,000 products ``` Generating five million product pages during every deployment would be... let's call it: > "A bold strategy." 💀 You might choose to prerender only popular routes and allow other content to resolve later depending on your rendering/caching architecture. That's one of the reasons modern Next.js rendering is much more flexible than: ```text STATIC or DYNAMIC ``` as a binary choice. --- # 7. Static Shell + Dynamic Content This is the modern mental model you should really remember. Imagine a user dashboard: ```text /dashboard ``` It contains: ```text Logo Navigation Dashboard structure News User profile Notifications Live analytics ``` Instead of choosing: ```text Entire dashboard = SSR ``` you can think component-by-component. For example: ```text Logo Navigation Dashboard structure ↓ STATIC ``` ```text News ↓ CACHED ``` ```text User profile Notifications Live analytics ↓ REQUEST-TIME ``` Then Next.js can build a useful static shell while streaming the dynamic content. --- # Why This Matters for Performance Imagine the live analytics API takes: ```text 2 seconds ``` Without streaming: ```text Analytics slow ↓ Entire page waits 2 seconds ``` With a static shell + Suspense: ```text Dashboard shell ↓ Shows immediately Analytics ↓ Loading fallback 2 seconds later ↓ Analytics streams in ``` The user starts interacting with useful UI earlier. That's a much better experience. --- # 8. Streaming Streaming means Next.js doesn't have to wait until every single component has finished rendering before sending useful UI. For example: ```jsx import { Suspense } from "react" export default function Page() { return ( <>

Dashboard

Loading analytics...

} > ) } ``` If: ```text Dashboard title ``` is ready immediately but: ```text Analytics ``` takes two seconds, the user doesn't need to wait for both. The page can arrive in pieces. --- # Streaming Mental Model Without streaming: ```text Header ready Posts ready Analytics waiting... Recommendations waiting... ↓ Everything finally ready ↓ Send page ``` With streaming: ```text Header ready ↓ Send Posts ready ↓ Send Analytics loading ↓ Fallback Analytics ready ↓ Stream it in ``` Much more responsive. --- # Modern Rendering Is Component-Level This is probably the biggest takeaway from modern Next.js. Old mental model: ```text What rendering strategy does this PAGE use? ``` Modern mental model: ```text Which parts of this page can be prepared? Which parts can be cached? Which parts need the current request? ``` That's much more powerful. --- # Classic Rendering Strategies vs Modern Architecture Think of the classic terms as fundamental concepts: ```text SSG ↓ Prepare reusable content ahead of requests ``` ```text SSR ↓ Generate request-time content ``` ```text ISR ↓ Cache reusable content and refresh it over time ``` Modern Next.js can combine all three ideas inside one route. For example: ```text Product Page │ ├── Navbar │ ↓ │ STATIC │ ├── Product Information │ ↓ │ CACHED │ ├── Reviews │ ↓ │ REVALIDATED │ ├── Cart │ ↓ │ REQUEST-TIME │ └── Recommendations ↓ STREAMED ``` That's a much better mental model for current App Router development. --- # SSG vs ISR vs SSR Here's the traditional comparison: | Strategy | When Work Happens | Freshness | Typical Performance | |---|---|---|---| | **SSG / Static** | Ahead of requests | Changes only when regenerated | 🔥 Very Fast | | **ISR / Cached + Revalidated** | Cached, then refreshed over time | Eventually fresh | 🔥 Very Fast | | **SSR / Request-Time** | When user requests content | Fresh/request-specific | Depends on server/data work | But modern Next.js adds another important idea: | Strategy | What Happens | |---|---| | **Partial Prerendering** | Static/cached shell is prepared while runtime content streams separately | --- # Old vs Modern Decision Tree The traditional decision tree looked like: ```text Does content change? │ ├── No │ └── Static Rendering │ └── Yes │ ├── Occasionally │ └── ISR │ └── Every request └── SSR ``` That's still useful. But modern Next.js lets us be more precise. --- # Modern Decision Tree ```text Can this content be prepared ahead of time? │ ├── Yes │ └── Static/prerendered │ └── No ↓ Can different users safely share the result? │ ├── Yes │ └── Cache it │ └── Revalidate when needed │ └── No ↓ Does it depend on cookies, headers, search params, session, or live data? │ └── Yes └── Render at request time └── Put it behind Suspense when appropriate ``` Then ask: ```text Does only PART of the page need request-time data? ``` If yes: ```text Keep the reusable shell static/cached + Stream the dynamic section ``` That's the modern Next.js approach. --- # Example: Blog A blog article might use: ```text Navbar ↓ Static Article ↓ Cached Comments ↓ Revalidated Logged-in user controls ↓ Request-time ``` You don't need to throw away static rendering just because: ```text "Edit Article" ``` should only appear for one logged-in user. --- # Example: E-Commerce Product page: ```text Product title Images Description ↓ Cached ``` Reviews: ```text Revalidated periodically ``` Inventory: ```text Fresh/request-time ``` Cart: ```text User-specific/request-time ``` Recommendations: ```text Personalized + streamed ``` One page. Multiple rendering behaviors. 🔥 --- # Example: SaaS Dashboard Dashboard shell: ```text Sidebar Navigation Page structure ↓ Static ``` General announcements: ```text Cached ``` User profile: ```text Request-time ``` Account balance: ```text Request-time ``` Analytics: ```text Request-time + streamed ``` Again: ```text You don't need to make everything dynamic just because one component is dynamic. ``` --- # Important Interview Questions > **Q: What is SSG in Next.js?** > > Static rendering generates reusable page output ahead of incoming user requests, commonly during the production build, allowing the result to be served efficiently without rendering the whole page for every request. --- > **Q: What is SSR in Next.js?** > > Server-Side Rendering refers to generating content on the server at request time, which is useful when the result depends on fresh or user-specific information. --- > **Q: What is ISR?** > > Incremental Static Regeneration allows cached or statically generated content to be refreshed without rebuilding and redeploying the entire application. --- > **Q: What is Partial Prerendering?** > > Partial Prerendering allows Next.js to create a static shell while dynamic parts of the route render and stream at request time. --- > **Q: What is `generateStaticParams()`?** > > It tells Next.js which parameter values for a dynamic route should be statically generated during the build. --- > **Q: Does a personalized component mean the entire page must use SSR?** > > Not necessarily. With modern Cache Components and Partial Prerendering, request-specific UI can be isolated and streamed while reusable parts of the route remain static or cached. --- # Previous App Router Syntax You'll Still See Existing Next.js projects may use: ```js export const dynamic = "force-dynamic" ``` for dynamic rendering. You may also see: ```js export const revalidate = 60 ``` for ISR-style revalidation. And: ```js fetch(url, { cache: "no-store" }) ``` for fresh data. Or: ```js fetch(url, { next: { revalidate: 60 } }) ``` for cached data with revalidation. These patterns are important because real production applications don't magically rewrite themselves every time Next.js releases a new caching model. 😄 You'll encounter them. Understand them. But for new Next.js applications using **Cache Components**, also learn: ```text "use cache" cacheLife() cacheTag() Suspense revalidatePath() revalidateTag() ``` because this is where modern Next.js rendering and caching are heading. --- # Quick Rendering Reference | Need | Good Starting Point | |---|---| | Same content for everyone | Static/prerendered | | Content reusable for a period | `"use cache"` | | Periodically refreshed content | Cache + `cacheLife()` | | Refresh immediately after mutation | `revalidatePath()` / tag revalidation | | User-specific content | Request-time rendering | | Cookies or headers | Request-time component | | Slow dynamic component | `` + streaming | | Known dynamic routes | `generateStaticParams()` | | Static + dynamic content together | Partial Prerendering | --- # The Mental Model Don't memorize: ```text SSG = X SSR = Y ISR = Z ``` and stop there. Instead ask: ```text When can this content be generated? ``` Then: ```text Can everyone share it? ``` Then: ```text How long can it stay cached? ``` Then: ```text Does it depend on this specific request? ``` And finally: ```text Does the WHOLE page depend on that request, or just one component? ``` That final question is extremely important in modern Next.js. --- # Summary Next.js gives you control over **when different parts of your UI are generated**. The classic strategies are: - **Static Rendering / SSG** — generate reusable content ahead of user requests - **SSR / Dynamic Rendering** — generate request-specific content when the user visits - **ISR** — cache reusable content while allowing it to refresh over time But modern Next.js goes further. With **Cache Components** and **Partial Prerendering**, one route can contain: ```text Static Content + Cached Content + Revalidated Content + Request-Time Content + Streamed Content ``` You can use: ```js "use cache" ``` to cache reusable work, ```js cacheLife() ``` to control its lifetime, ```js revalidatePath() ``` or cache tags to refresh stale content, ```js generateStaticParams() ``` to prerender known dynamic routes, and: ```jsx ``` to isolate and stream request-time UI. The biggest mindset shift is this: ```text OLD QUESTION "Is this PAGE static or dynamic?" ``` becomes: ```text MODERN QUESTION "Which PARTS of this page should be static, cached, or dynamic?" ``` Once you start thinking at the component level, Next.js rendering becomes way less intimidating. And that's how we'll keep learning on **asif.to** — not by making you memorize another alphabet soup of SSG, SSR, ISR, PPR and whatever three-letter acronym arrives next 😭, but by understanding the actual problem: **when should this piece of UI be generated, and how fresh does it really need to be?** Once you can answer that, choosing the right Next.js rendering strategy becomes much easier. 🚀