Client-side Rendering

On the early web, building a screen was entirely the server's job. Follow a link and the server assembled the finished HTML document for that page and sent the whole thing down; the browser unpacked it and showed it. For reading documents, nothing about that arrangement is lacking.

The trouble appeared once people started doing things inside the page. Post one comment and the entire page was rebuilt. One line in a list had changed, yet the header, the side menu, and the article you had already read all came down again. The screen blanked out and refilled, and your reading position jumped back to the top. Imagine that happening every time you drag a map a little and it becomes clear that some products simply cannot be built with the server drawing the screens.

Client-side rendering (CSR) moves the drawing from the server into the browser. Instead of a finished screen, the server sends the ingredients: JavaScript that knows how to assemble the screen, and the data to fill it with. The browser does the assembly. When one comment gets added, the page asks for that one comment and repaints only the list. Nothing else on the screen is touched, so there is no blanking and no scroll jump, and the whole exchange moves a few kilobytes instead of a full page.

The browser receives a document, downloads and runs the code, then requests data and draws the screen. Five things happen in order.

1. The server sends a nearly empty document. Its body holds one placeholder element and the address of a code file, nothing else. At this point the screen shows nothing.
2. The browser downloads that code file. It contains every rule for building every screen, which is why it runs from a few hundred kilobytes to several megabytes.
3. The browser executes the code. It manipulates the Document Object Model (DOM) — the structure through which a browser exposes a document to code — creating and attaching screen elements one by one.
4. The code requests data separately. Document lists, the signed-in person's details, anything that differs per user arrives at this step. Once those values fill the placeholders, the screen is finally complete.
5. Later navigation never asks the server for another document. Only data comes down, and only the changed region gets repainted. Swapping screens inside a single document like this is what a single page application (SPA) is.

Nothing is visible until steps 1 through 4 have all finished. On a slow connection that stretch runs past three seconds, and the screen holds a blank background or a spinner the whole time. The trade is exact: pay at the first entry, collect on every navigation after it. Whether that trade is worth taking depends entirely on how long a visit lasts. Forty views in one session amortizes the cost; one view and out does not.

The way to lower that payment is to split the code file. Code splitting hands over only the portion a screen needs when the user reaches it, rather than everything up front, so someone who never opens the settings screen never downloads it during the initial load.

It suits screens behind a login where people stay a while and interact constantly. Admin tools, dashboards, document editors, maps — places where someone arrives once, stays thirty minutes, and moves between views dozens of times. Spending two extra seconds at entry to save half a second on each of forty navigations is plainly the better experience. That these screens require a login, and therefore need no search visibility, fits the same way.

Three situations expose the limits.

1. Places where first-paint speed is the result. Someone arriving from an ad leaves in large numbers past the two-second mark. Product detail and marketing pages live here.
2. Places where search and sharing matter. Search engine crawlers do execute JavaScript, but the execution is queued behind the first pass and the outcome isn't identical every time. Link previews in messaging apps read only the document's initial content, so an empty document yields no title and no image, and a page that gets passed around in chat loses most of what makes people click it.
3. Places where device performance varies. The code runs on the user's machine, so no amount of server capacity makes a four-year-old budget phone faster.

Real products therefore don't standardize on one approach; they choose per screen. Public marketing pages get built ahead of time with static site generation (SSG), frequently changing lists get rebuilt selectively with incremental static regeneration (ISR), and the working screens behind the login stay client-side.

"This screen is only visible after login, so let's go client-side."

Search visibility is expendable here, so the slow first paint is acceptable.

"The bundle is 1.8 megabytes. First paint takes four seconds."

The code to download and run has grown too large and needs splitting.

"The link preview has no title — we're serving an empty document."

Because the browser draws the screen, anything that only reads the document sees nothing.

At Pagedeck the decision split at the document share link. The editor was client-side from the start; you can't make a round trip to the server every time someone edits a paragraph. But when public share links shipped, Ravi pasted one into a messaging app and got no title and no preview.

Theo found the cause quickly. The share link was serving the same empty document as the editor, and the messaging app read the document without running any code. The fix left the editor alone and switched only the share view to being drawn on the server.

The most common mistake is filing client-side rendering under "slow." Experiencing the delayed first paint makes that conclusion feel earned. What's slow, though, is one entry; every navigation after it skips the server and runs faster. Miss that distinction and you move an admin tool people sit in for thirty minutes over to server rendering to save 0.3 seconds once, making the dozens of daily view changes slower in exchange.

Believing search indexing is impossible is the other one. It was true for a while, which is why the belief persists. Major crawlers now run the code and read the rendered result. The execution is deferred past the first pass, though, and if the code is slow or fails partway the page gets recorded empty. It isn't impossible so much as unguaranteed, and for a page where visibility drives revenue there's no reason to carry that uncertainty.