Server-Side Rendering (SSR), the Pros & Cons

Server-side Rendering (SSR) is one of several ways to render content on a website. Here’s a short SSR pros & cons overview, highlighting the most important topics.

Good to know before you continue:

• SSR: Server-Side Rendering
• CSR: Client-Side Rendering
• SSG: Static Site Generation

How SSR works

1. Upon visiting a web page, the web server sends a response to the user’s browser.
2. The user’s browser renders the page, which is now viewable. Meanwhile the browser downloads JavaScript.
3. The browser executes JavaScript (could be React, for example).
4. Now the user can interact with the site.

How CSR works

1. Upon visiting a web page, the web server sends a response to the user’s browser.
2. The user’s browser downloads JavaScript
3. The browser executes JavaScript
4. Now the user can interact with the site.

I’ll use the acronyms above for each rendering method in the following.

The Pros of SSR

• Quick initial access: with SSR your website’s pages are immediately available to interact with for your users, even on slow Internet connections. On a CSR app, users can’t interact with your website until the JS bundle containing the entire site is 100% loaded, which can take a while on big websites. With a decent server, SSR can give you a great First Contentful Paint score, which improves the user experience (UX) and probably your SEO page ranking as well.
• Great for SEO: the search engines don’t need to run your JavaScript to read and index your content. CSR gets indexed as well, but not as fast as SSR. If your business depends on traffic, you have to use SSR.

The Cons of SSR

• Slower page transitions: browsing from page to page is often much slower with SSR than on CSR — at least if your pages contain heavy/complex data. With SSR you’re basically rendering your app twice, once on the server, and once on the client.
• Vulnerability: SSR sites are harder to keep secure because they have a bigger surface to attack than CSR sites. This is however not an issue if you or your developers know what they’re doing.
• Complex caching: configuring your cache is usually more complex on SSR sites than CSR sites.
• Server cost: SSR often needs a bigger and more powerful server to provide high-performance than CSR.
• Higher latency: SSR sites tend to get a high latency if you get lots of traffic at the same time, which delays/slows down the browsing experience for everyone. CSR doesn’t suffer from this nearly as much. Latency is also known as ping rate which is usually measured in ms (milliseconds).

Damn, there are a lot of cons compared to pros of using SSR, huh? Yes, but fear not and read on, there’s a solution!

Universal Rendering

Fortunately, there’s a method called universal rendering, where you can get the best of both worlds, the quick and seamless app-like page transitions of client-side rendering + the SEO and blazing fast first-paint of server-side rendering.

In modern times (2020+) the ideal solution for most use cases is to combine CSR and SSR, along with some type of SSG, as this gives you maximum speed, strong security, great SEO, lower server costs, and the best user experience possible.

Luckily, today we have Next.js and GatsbyJS (React frameworks) which both provide this awesome universal rendering feature (CSR + SSR + SSG) out-of-the-box — although they handle it in different ways.

Note: there are other frameworks that provide universal rendering, Next.js and Gatsby are just the two I got experience with.