Next.js CSR vs SSR vs SSG vs ISR and now PPR!

Technological concepts covered (Next.js rendering & data caching)

The video explains core Next.js rendering strategies and how they relate to where code runs (server vs browser) and when HTML is generated (build time vs request time).

Terms covered:

• CSR (Client-Side Rendering)
• SSR (Server-Side Rendering)
• SSG (Static Site Generation)
• ISR (Incremental Static Regeneration)
• PPR (Partial Pre-rendering)

---

App structure concepts (prerequisite)

• React Client Components run in the browser and can use browser events and React client hooks (e.g., interactivity like click handlers).
• React Server Components run on the server only; their rendering logic runs server-side and their output is sent to the client.

Next.js also includes:

• Server Actions: for data mutations (create/update patterns similar to POST/PUT/DELETE)
• Route Handlers: API endpoints (e.g., for webhooks)

---

CSR (Client-Side Rendering)

• The browser renders everything; React component code executes in the user’s browser.
• Example: a blog page where markup (including interactive elements like an upvote button with state) is computed client-side.
• Behavior described: component function bodies run in the browser to produce HTML markup.

---

SSR (Server-Side Rendering)

• Rendering happens on the server when a request arrives.
• Server components are rendered on the server and can fetch data directly in the component body (example: using Prisma on the server without useEffect).
• Interactivity example: the upvote button must be a Client Component ("use client") because click events and React hooks can’t run in Server Components.

Key idea:

• Next.js uses Server Components by default, and you add “islands of interactivity” using client components.

---

SSG (Static Site Generation)

• The whole page is pre-rendered at build time.
• Example: the /posts page is rendered once during next build and served as ready-made HTML.
• Efficiency goal: fast response for many users without recomputing on every request.
• The video mentions Next.js tooling/indicators that show whether a route is static vs dynamic during build output.

Why some pages become dynamic instead of static

If rendering depends on runtime-only inputs, Next.js can’t fully pre-render:

• Route params via dynamic IDs (e.g., /posts/[id]) because the build can’t know all possible IDs
• Search params
• Cookies / headers (depends on the specific user request)

Authentication is highlighted as a common reason:

• checking cookies/tokens at request time can force dynamic rendering.

Terminology note

• The narrator prefers thinking in terms of static vs dynamic pages, not mixing it up with “server-side rendered” labels.

---

“Making dynamic routes static” with generateStaticParams

Next.js can statically pre-render dynamic routes if you can enumerate the possible params.

• Example: use generateStaticParams to return a list of post IDs.
• Effect: Next.js generates static HTML for each known ID (shown as “generating static pages” during build).

Interaction + SSG compatibility clarification

Even when a page is SSG, a Client Component inside the page still:

• gets computed during static generation (server side, once),
• then runs in the browser afterward for interactivity.

So:

• client components do not prevent static HTML generation; they affect runtime behavior after hydration.

---

ISR (Incremental Static Regeneration)

Goal:

• keep pages mostly static, but allow updates without a full rebuild.

Example flow:

1. Build generates a static /posts page (e.g., 7 posts).
2. When new data arrives (e.g., creating post #8), the existing static HTML becomes stale.
3. Next.js can be signaled to revalidate and regenerate the affected page.

How updates are triggered

• Uses revalidatePath / revalidateTag from Next cache.
• Triggered via a Server Action (form submission handled server-side).

“Cool behavior” described

• After revalidation, the regenerated content updates the UI in the same request cycle.
• Future requests serve the newly cached result.
• Emphasis: “incremental” regeneration of only the changed parts, avoiding full next build.

---

PPR (Partial Pre-rendering) — newer/experimental

Presented as an optimization beyond ISR/SSG to avoid “opting out” of static generation for the whole page when only part depends on runtime info.

Problem addressed

• Runtime-dependent features (cookies/search params/headers) can force the entire page to become dynamic.
• If heavy computation is on the page, rerunning it on every request is inefficient.

Solution

• PPR lets you mark most of the page as static while isolating only a small “dynamic island.”
• Implemented with a Suspense boundary and experimental Next.js canary feature flags (as described in the video).

Example scenario:

• A “recently viewed posts” widget depends on cookies, so it must be dynamic.
• With PPR, the rest of /posts can remain static while only that widget is dynamic.

Outcome:

• During build, Next.js generates the static shell; only the runtime-dependent section renders on demand.

---

Sponsor segment (ImageKit) — related to product/media workflows

Although not directly part of rendering terms, the sponsor covers:

• Uploading images/videos and managing assets via a dashboard and API
• Background removal in the dashboard
• Automatic optimization and delivery:
  • PNG served as WebP via CDN
  • quality controls (example: default quality 80)
  • security via signed URLs
• Transformations via URL:
  • resizing for device-specific dimensions (mobile vs desktop)
  • cropping (including face/object-aware cropping)
  • overlays and watermarking
  • AI features (background removal, generative fill, effects)
• Video-specific options:
  • codec selection, quality control
  • thumbnails, trimming
  • adaptive bit rate streaming mentions

The video points to ImageKit docs/guides for optimization.

---

Main speakers/sources (end of video)

• Primary speaker: the video’s narrator/instructor (no specific name provided in the subtitles)
• Sponsor/source: ImageKit (referenced as today’s sponsor)