In a Next.js App Router app, what does the `ssr: false` option on `next/dynamic` change about where a component renders, and why does the build reject that option inside a Server Component?

## What the option actually switches off `next/dynamic` normally does two things: it splits the component into its own chunk, and it still lets the component participate in server rendering, so its markup appears in the initial HTML and hydrates on the client. `ssr: false` removes the second half. ```tsx 'use client' import dynamic from 'next/dynamic' const MapWidget = dynamic(() => import('./MapWidget'), { ssr: false, loading: () => <div className="h-80" />, }) ``` During the server render, Next does not evaluate `MapWidget` at all. What lands in the HTML for that slot is the `loading` element, or an empty slot when you omit it. Once the page hydrates in the browser, the chunk is requested, the module is evaluated, and the component mounts and replaces the fallback. ## Why you would want that The standard reason is code that cannot survive a server environment. Server rendering runs in Node (or the Edge runtime), where there is no `window`, no `document`, no `localStorage`, and no DOM. A library that reads any of those at module scope throws the moment it is imported on the server, and one that reads them during render throws on the first render pass. Mapping libraries, charting libraries built on canvas, editors that measure DOM nodes, and anything wrapping a browser-only SDK are the usual suspects. A second reason is components whose server-rendered output would be wrong anyway — something that renders from a browser-only source of truth, so the server's version would only differ from the client's. Note that `ssr: false` is a blunt tool for the first problem. If only *part* of the component needs the DOM, the narrower fix is to keep the component server-renderable and do the browser work in an effect, which runs only in the browser by definition. ## Why the App Router rejects it in a Server Component In the App Router as of Next 15 and 16, `dynamic(..., { ssr: false })` in a file that is not marked `'use client'` fails the build, with an error directing you to move it into a Client Component. The reason is structural. A Server Component renders once, on the server, and its output is serialized into the payload the browser receives; it has no counterpart that re-renders in the browser. "Do not render this on the server, render it on the client instead" therefore has no client-side render pass to fall back to. The option only means something inside the client tree, where there genuinely are two render passes and you are choosing to skip one. The fix is mechanical: put the `dynamic()` call in a small `'use client'` module and render that module from the Server Component. ```tsx // map-widget.client.tsx 'use client' import dynamic from 'next/dynamic' export const MapWidget = dynamic(() => import('./MapWidget'), { ssr: false }) ``` ```tsx // page.tsx — a Server Component import { MapWidget } from './map-widget.client' export default function Page() { return <MapWidget /> } ``` ## What it costs Three costs are worth naming, because interviewers probe for whether you treat `ssr: false` as free: **Nothing in the initial HTML.** That region is blank until hydration finishes *and* the extra chunk arrives. If the component is above the fold, you have made the page look slower even though total bytes did not change. **Layout shift.** An empty slot that later fills with a 400 px widget pushes content down. This is why the `loading` fallback should reserve the real dimensions rather than being a bare spinner. **No content for crawlers or no-JS clients.** The markup simply is not there. Never hide primary content behind `ssr: false`. ## The common mix-up `ssr: false` and plain `dynamic()` solve different problems, and candidates routinely conflate them. Plain `dynamic()` is about *bundle timing* — the component still server-renders, you just fetch its JavaScript later. `ssr: false` is about *execution environment* — the component never touches the server. You can want the first without the second, and if your only goal is a smaller first-load bundle, adding `ssr: false` buys you nothing and costs you the server-rendered HTML.