Blog The quiet return of server-side rendering
The quiet return of server-side rendering
TL;DR The industry over-corrected into heavy client-side apps that shipped megabytes of JavaScript to render text. Server-side rendering came back because it is faster to first paint, better for SEO, and lighter for the user. The modern version blends server-rendered HTML with just enough client interactivity.
For a decade the default answer to "how should we build this website?" was a single-page app: ship JavaScript to the browser and let it render everything. Lately the answer has quietly changed back to rendering on the server. It is worth understanding why, because the pendulum swinging tells you something real.
What went wrong with client-only apps
The single-page app model moved rendering into the browser. That made sense for genuine applications, but it got applied to everything, including sites that mostly display text.
The costs added up. Pages shipped large JavaScript bundles just to render content that could have been plain HTML. First paint got slower, especially on cheaper phones. Search engines had to work harder to see the content. For a blog or a marketing site, the browser was doing a lot of work to display words that never change.
Why the server came back
Rendering HTML on the server fixes the expensive parts.
- Faster first paint. The browser receives finished HTML and shows it immediately, instead of downloading and running JavaScript first.
- Better for SEO and AI crawlers. The content is in the initial response, easy to read and quote.
- Lighter for the user. Less JavaScript to download, parse, and run, which matters most on slow devices.
The modern blend
The return is not a full reversal to the old server-rendered era. The current approach renders HTML on the server, then layers client-side interactivity only where a page actually needs it. Newer frameworks make that split cleaner, letting most of a page be server-rendered while the interactive islands hydrate on their own.
What it means for you
Default to server-rendering the content, and reach for heavy client-side work only where the experience is genuinely app-like. For most sites, that means faster pages, better search visibility, and less JavaScript to maintain. The lesson of the swing is not that one model won, but that you should match the approach to what the page actually is.
FAQ
Why did single-page apps fall out of favour?
They pushed rendering to the browser, which meant shipping large JavaScript bundles just to display content. That hurt load time, first paint, SEO, and users on slower devices. For content-led sites, the cost outweighed the benefit.
Is server-side rendering just going back to the old way?
Not quite. The modern approach renders HTML on the server for speed and SEO, then adds client-side interactivity only where it is needed, rather than making the whole page a client app. It is a blend, not a full reversal.
When is a client-heavy app still the right call?
For genuinely app-like experiences behind a login, dashboards, editors, tools, where SEO does not matter and rich interactivity does. The mistake was using that model for content sites that mostly display text.