What is SSR?

SSR stands for Server-Side Rendering.

This is originally how web pages were built. The server generates the complete HTML page and sends it to your browser. Your browser displays the page, and if you click a link, the server builds a whole new page and sends it back.

Then with Web 2.0, sites like Google Maps showed you could build interactive pages that didn’t need to refresh. You could drag the map around and it would seamlessly load new parts without rebuilding the whole page. I remember the first time I saw this, it was like magic!

This led to the rise of Single Page Applications (SPAs), where almost everything happens in the browser with JavaScript. Frameworks like Angular, React, and Vue made building SPAs easier, and for a while everyone was building client-side rendered apps.

But SPAs introduced their own problems. They were more complex to build. You needed to coordinate between server APIs and client code. And they weren’t great for SEO. Search engines work better when your content is in the HTML right away, not loaded later by JavaScript.

So now there’s a shift back. Modern frameworks like Next.js and Remix bring back server rendering, but with some client-side enhancements mixed in. This is often called “SSR” even though it’s a bit more nuanced than the original server-rendered sites.

You’ll hear developers say things like “We’re using SSR” or “Should we go with SSR or client-side rendering?” when discussing how to build a web application.

See also What does server-rendered mean?