Next.js · Advanced interview

Server Components render on the server to a serialized description of the UI (the RSC payload) — not HTML strings but a tree referencing client components by id. Next streams that payload; the client uses it for the initial HTML and to reconcile, then hydrates only the client components, downloading just their JS. This is why server components ship no JS and can touch server resources: their code never reaches the browser.

Props passed from a server component to a client component must be serializable — plain objects, arrays, strings, numbers, and Server Action function references — but not arbitrary functions, class instances, or things like Dates-as-behaviour. You also can't import a server-only module into a client component. The boundary is a serialization boundary, so you design props to be plain data and keep non-serializable logic on the correct side.

A mismatch happens when the server-rendered HTML differs from the client's first render — common causes are using Date.now()/Math.random(), reading window or localStorage during render, locale/timezone differences, or invalid HTML nesting. Fixes: move browser-only logic into useEffect, gate it behind a mounted flag, use suppressHydrationWarning sparingly for inherently dynamic values, and keep render pure and deterministic. The render must produce the same output on both sides.

There are roughly four: the Request Memoization cache (dedupes identical fetches within one render), the Data Cache (persists fetch results across requests/deploys, controlled by revalidate/no-store), the Full Route Cache (caches the rendered RSC payload/HTML of static routes at build), and the client-side Router Cache (caches visited route segments in the browser for fast back/forward). Knowing which layer a piece of data lives in tells you why it's stale and how to refresh it.

Data Cache: cache: 'no-store' or revalidate, and on-demand revalidateTag/revalidatePath. Full Route Cache: making the route dynamic (cookies/headers/no-store or dynamic = 'force-dynamic') or revalidating. Request Memoization is automatic and per-render. Router Cache: router.refresh(), revalidatePath, or it expires by time. Stale-data bugs usually come from not realizing several of these stack, so you target the specific layer.

Partial Prerendering serves a static prerendered shell instantly and streams in the dynamic parts (wrapped in Suspense) within the same route, instead of forcing the whole page to be either static or dynamic. You get the speed of static for the common shell and the freshness of dynamic for personalized bits, in one response. It blurs the old static-vs-dynamic boundary at the component level.

Keep components as Server Components by default and push 'use client' as far down the tree as possible so only truly interactive leaves ship JS. Lazy-load heavy client components with next/dynamic, avoid pulling large libraries into client components, and watch for accidentally making a whole subtree client by marking a high-level component. Analyze with the bundle analyzer and move data-fetching/formatting to the server.

Sequential awaits create waterfalls; instead kick off independent fetches in parallel (start the promises, then await together with Promise.all), hoist shared data, and use Suspense so independent sections stream concurrently rather than blocking each other. Request memoization helps dedupe, but the main lever is not awaiting one request before starting an unrelated one. Preloading patterns can warm data a component will need.

For LCP: use next/image with priority on the hero, optimize fonts with next/font to avoid layout shift and blocking, and prefer static/streamed server rendering so content paints fast. For CLS: reserve space for images/ads and avoid injecting content above existing content. For INP: minimize client JS and heavy hydration. Measure with real-user data and Lighthouse, then target the worst metric.

Treat a Server Action like a public HTTP endpoint: anyone can invoke it, so authenticate and authorize inside the action, validate and sanitize all input (e.g. with Zod), and never trust hidden form fields. Next adds CSRF protections (same-origin checks) for actions, but you still enforce per-user permissions and rate limits yourself. The mistake is assuming an action is safe because it's only called from your UI.

Edge gives low latency globally and fast cold starts, great for auth checks, redirects, personalization, and lightweight APIs. But it has a limited runtime (no native Node APIs, smaller size/time limits), database drivers may not work or need HTTP/edge-compatible clients, and debugging differs. You weigh global latency benefits against API/dependency constraints, often keeping data-heavy work on the Node runtime.

Work through the caching layers: is the fetch in the Data Cache (missing no-store/revalidate)? Is the route in the Full Route Cache because it's static when it should be dynamic? Is the browser's Router Cache showing an old segment (needs router.refresh or revalidatePath after a mutation)? Reproduce with the layer in mind, check whether mutations call revalidateTag/Path, and confirm the fetch's cache options. Most 'stale' bugs are a layer you forgot to invalidate.