Server-side Rendering

Drawing pages in the browser was the default for a long time. The server sends a nearly empty document plus scripts, and the browser runs those scripts, fetches data and fills the page in. Moving between screens without a full page load, so the site feels like an app rather than a document, is what that approach buys.

The price gets paid on the first screen. The user watches a blank page while the scripts download, execute and request data. On a work laptop with a fast connection that's 0.4 seconds and nobody notices; on a phone a few years old with a slow connection the same screen sits empty for over three seconds, which is long enough for someone to leave. Search crawlers reading that empty document was a related problem — the search result with a title and no content underneath it comes from here, and nobody inside the company ever sees it.

Server-side rendering (SSR) reverses the order. When the request arrives, the server assembles a document with the data already in it, so the browser can show text the moment it arrives. The scripts come afterwards and add the behavior, which is a different problem from showing the content.

The server draws the page per request and the browser layers behavior on top. Four steps.

1. The browser requests an address. The server pulls the data that screen needs from the database, puts it into the document, and sends back markup with all the text and structure already in place. Nothing more is required to read it.
2. The browser draws what it received. At this point the user can read the content. This is why largest contentful paint (LCP), the time until the largest piece of content is drawn, comes down.
3. Scripts arrive and attach behavior. Adding clicks and inputs to a server-drawn page is called hydration, and it costs about as much script as the client-side approach did.
4. Navigation after that is handled in the browser. Rendering only the first screen on the server and running the rest client-side is the practical default, since the cost of server rendering repeats on every request.

A gap opens between steps two and three: the text is visible and the buttons don't work yet. Press one in that window and nothing happens at all, which is the most common support ticket a team gets after adopting SSR. The user has no way to tell that the page is not finished. The window gets narrowed by shrinking the script or by making the parts people touch first interactive before the rest of the page. Some teams choose to render buttons disabled until behavior attaches, so a press produces a response.

The cost follows the benefit here. Every request makes the server read the database and build a document, which raises both server bills and response time. Pages that aren't different per person reduce that by storing one result and reusing it — the heavier the traffic on a page, the more that storage cuts off the bill.

Pages people arrive at from search come first: the marketing pages, blog posts, the pricing page. Where search engine optimization (SEO) is being done on a page, having the content inside the document is the safer position to take, even when the alternative usually works.

Second is anywhere first-screen speed attaches directly to a result. Half the people who clicked an ad leave during three seconds of blank page, having paid attention to nothing. At $0.60 a click, someone who leaves before seeing anything is that money gone with nothing to show for it, which is why ad landing pages tend to get this treatment first.

Third is screens whose contents differ per person. A logged-in user's document list can't be built in advance, because what to show is only decided at request time. Generating pages at build time cannot cover that at all; drawing per request can, which is the case this method exists for.

The bad fit is equally clear. An internal admin tool used only behind a login has nothing to do with search, and its nature is one screen whose values keep changing as people work, which is simpler to draw in the browser. Adding SSR there buys server cost and structural complexity and nothing a user would notice.

"Let's server-render this page. Half its traffic is search."

Search traffic is the basis for the decision rather than a preference about architecture.

"Press anything before hydration and nothing happens."

Visible and interactive are two different moments, and users don't know that.

"Server costs went up 40 percent after the switch."

Reporting where the price of that speed ended up landing.

Pagedeck moved its marketing pages and blog to SSR after Ravi brought the search traffic numbers. The first screen was taking 2.8 seconds to fill for people arriving from search, and a third of them were leaving before it did.

Theo moved only those two areas and left everything behind the login as it was, on the grounds that nobody arrives there from a search engine. First-screen time came down to 0.9 seconds and the drop-off fell noticeably over the following month. Server costs rose, and since those pages don't differ per person, storing and reusing the result removed most of the increase. The same trick wasn't available for the logged-in screens.

The most common mistake is reading SSR as always faster. The first text does appear sooner, so it feels that way. But what improves is time to visible, and time to interactive can get worse: the same volume of script still has to come down and attach itself on top of the server-drawn page. Judge on one metric and the conclusion diverges from what users actually experience on the page.

Treating it as the answer to a search problem is the other one. Cases of crawlers reading empty documents are well known, which makes the expectation natural. But the major crawlers now execute scripts and read the page once it has filled in. If rankings aren't moving because the content is thin or several pages overlap on one subject, changing the rendering method changes nothing at all. Where this approach reliably helps is crawlers that skip execution, and places like link previews in chat apps where no scripts run at all.