The Quiet Return of Server-Side Rendering

For about a decade, the default way to build a serious website was to ship a mostly empty page and let JavaScript draw the rest in the browser. The page arrived, then blinked, then filled in. We all got used to the little spinner. That approach has a name: the single-page app, or SPA, where one bundle of JavaScript runs the whole site and swaps content in and out without a full reload.

It made sense at the time. It also quietly went too far. And over the last few years the industry has walked a good part of it back, toward rendering pages on the server again. This is a short, honest account of how we got here and what actually changed.

How we ended up shipping empty pages

Rewind to the early web. The server did the work. You asked for a page, a machine somewhere assembled the finished HTML, and your browser drew it. Simple, fast to first paint, easy for search engines to read. The downside was that every click meant a full reload, and rich, app-like interfaces were painful to build that way.

So the pendulum swung. Frameworks arrived that let you build the whole interface in the browser. The server's only job became handing over a blank shell and a big pile of JavaScript. Inside that world, building complex, stateful screens got genuinely nicer. Gmail-style apps, dashboards, design tools: the SPA was a real gift for those.

The mistake was treating every website like one of those apps.

A marketing site, a blog, a store, a restaurant page: none of these are Gmail. They are mostly content that needs to show up fast and be found on Google. When you build them as SPAs, you inherit all the costs of the app model and almost none of the benefits. First, the slow first load, because the browser has to download and run a lot of code before anything useful appears. Second, the search problem, since a crawler that sees an empty shell may index an empty shell. Third, the bundle: the total weight of JavaScript kept growing, and every kilobyte is time your visitor spends staring at nothing on a mid-range phone.

We felt all three. So did everyone honest about it.

What server rendering actually fixes

Server-side rendering, or SSR, means the page is assembled into finished HTML on the server before it reaches the browser. The visitor gets something real to look at almost immediately, and the JavaScript catches up in the background to make it interactive. You keep the app-like feel where you need it and get the fast, readable page everywhere else.

The newer idea on top of that is the server component: a piece of the page that runs only on the server and sends zero JavaScript to the browser at all. Your product description, your article body, your footer, none of it needs to ship code to be read. Only the genuinely interactive parts, the cart button, the search box, the image carousel, pay the JavaScript tax. The rest is just fast HTML.

Put plainly, the win is this:

• The first meaningful paint happens sooner, because the server did the assembly.
• Search engines and link previews see a real page, not a placeholder.
• You ship far less JavaScript, so slower phones and slower networks stop being punished.

This is why hybrid rendering, some of the page on the server, some in the browser, has quietly become the sensible default. It isn't a fashion swing. It's the industry admitting that most of the web is documents with a few interactive bits, not applications with a few static bits. If you want the practical version of why we pick the tools we do, we wrote about why we reach for Next.js, which was built around exactly this hybrid model.

There is a nice side effect too. When a page arrives fast and complete, it simply feels better, in a way people notice without being able to name. We got into that in what makes software feel fast, and rendering strategy is a big, underrated part of it.

Where a client-heavy app still wins

None of this means the SPA was a mistake to be ashamed of. It means we misapplied a good tool.

If you are building something people sit inside for an hour at a time, a spreadsheet, a drawing canvas, a video editor, a live dashboard, a trading screen, the client-heavy approach still wins. Those interfaces update constantly, hold a lot of state, and don't much care about Google indexing them. The cost of loading a big bundle once is paid back over a long session. That's the right trade. Rendering everything on the server for an app like that would fight the grain of the work.

The honest rule is boring: match the rendering to the thing.

Content that must be found and load fast leans server-side. Deeply interactive tools that people live in lean client-side. Most real projects are a mix, which is exactly why hybrid rendering won. A store's product pages want to be server-rendered and instantly indexable, while its live inventory filter can be a small island of client code. You don't have to choose one religion for the whole site.

It's worth remembering that plain old static pages never really left either, and for a lot of sites they're still the best answer. We made that case in static sites are back. The broad shape of the last few years is a return to sanity: do the least work in the browser that the job honestly requires, and no more.

The pendulum has settled closer to the middle now, and that's a healthier place for it to sit. Fast pages that machines can read, with real interactivity layered on only where it earns its place. If you're weighing how to build something and want a straight answer about which rendering approach fits, see our stacks and the trade-offs we actually make.