Demystifying Rendering Modes - SPA/CSR, SSR, SSG, OMG 😱

The web development has been around for some time. More precisely, almost 33 years since Sir Timothy Berners-Lee implemented the first successful communication between an HTTP client and a server via the Internet in the autumn of 1989 😄. The first-ever website was nothing more than a static page that outlined how to create Web pages and explained more about hypertext. A few years later, in '93, the dynamic websites arose with the appearance of CGI (Common Gateway Interface). This was a way to let a website run scripts (usually Perl scripts back then) on the web server and display the output.

From that point on, web technologies started booming, and the ways of building websites changed tremendously. While this article will not compare different tools or technologies, its purpose is to focus on the different methods we can build websites, the examples used being in regards to Nuxt.js.

Now, for a FE (font-end) newbie, these acronyms in the title might be a bit tricky to grasp at first. Or at least that’s what I felt when I first confronted them - so I took my time to fundamentally understand what makes one different from another, yet with every article I read, I felt like I couldn't wrap my head around these two: CSR and SPA. That's because sometimes SPA was mentioned instead of CSR, and sometimes they were mentioned as two completely separate things. Well, let's establish which is what so that you won't get as confused as I was. 😄

CSR stands for Client Side Rendering and SPA for Single Page Application. CSR is the approach in which the HTML file rendering is done in the user's browser, while Single Page Application is the type of web app that incorporates this approach as its behavior. So CSR is the model under which SPAs operate.

Instead of having a different HTML page per route, a client-side rendered website creates each route dynamically directly in the browser - which is a relatively new approach to rendering websites. It didn't really become popular until JavaScript libraries started incorporating it into their style of development (that's when React/Vue/Angular frameworks started booming).

Now that I made this clear, I hope you'll understand why both CSR and SPA are used throughout this article in different contexts.

Ok, let’s take a real-life example: you are given the task of creating a web app from scratch.
I’ve created a new Nuxt.js app with the create-nuxt-app command, and it started prompting some configuration options. Let’s stop at the one asking about the Rendering mode for a second, a.k.a. the different strategies to display an interface in a browser.

Rendering mode refers to the fact that both the browser(client) and the server can interpret JavaScript code to render Vue components into HTML elements - so what it’s asking is:

“Where do you want your JS to render the HTML? In the user’s browser (Single Page App) or on a web server (Universal)?”

To come up with an answer for this question, I'll make it a bit easier by rephrasing it so that it answers itself depending on the requirements needed for the app.
Aaaand drumrolls, please! 🥁🥁🥁

How important is SEO for this web app?

A. Not important => CSR is the way to go.

If you need strong SEO features, then client-side rendering is not your best option.

As stated earlier, with the creation of popular frameworks such as Angular.js and Vue, having the route creation and manipulation being done in the browser was quite a mind-blowing alternative to the former way of URL handling, that being the classic page refresh happening with each user action (good ol' PHP days).

Imagine nowadays having to refresh your page every time when you post a comment or hit the like button! 😅

So by dynamically rewriting the current web page with new data from the web server, the Single Page Applications now have smoother transitions between pages and feel almost like a native app. Ok, now what about the SEO?

SEO is a downside in this case since some crawlers are not executing the client side Javascript part that is running in the browser, and they are basically crawling empty HTML pages since the content was not rendered yet. The image below showcases this behavior.

Also, the website might get penalized by Google if there is a lot of processing on the main thread (think about downloading, parsing, and running all the Js in order for the HTML to appear on the page).

Last but not least, the performance may cause a nasty UX impact since the entire rendering happens on the client-side, so it relies solely on the user’s device capabilities and computing power. Of course, some devices are powerful enough and can handle this kind of processing, but there are still a lot of devices like cheaper phones or simply… slow internet speed 🫣.

So now that the cons of CSR have been stated, let’s see what its strengths are:

1. Development speed
When working entirely on the client side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the window object.

2. Hosting costs
Running a server adds a cost of infrastructure as you would need to run on a platform that supports JavaScript (a “PaaS” such as Heroku or Azure). Instead, Single Page Applications can be hosted on any static server that can serve your app’s static HTML, CSS, and JavaScript files.

3. Performance
Unlike traditional HTML pages, which need to refresh or re-render an entire page, client-side rendering simulates different pages but loads them on a single page. This puts less pressure on memory and processing power, which gives you quicker results than server-side rendering.
 
B. SEO is very important => Universal mode is your choice.

A. SSR (Server Side Rendering)

Contrary to CSR, SSR returns a fully rendered HTML page to the browser because the Vue.js code has already been run in a server environment. When the browser requests the URL, the HTML document is immediately visible, despite not being interactive. Making a static page interactive in the browser is called hydration, and this is the step in which the browser loads the js code that runs on the server in the background once the HTML document has been downloaded. The browser interprets it again, and Vue.js takes control of the document and enables interactivity.

Therefore due to SSR, we now have rendered content for the SEO crawlers to index, and even more quirks, such as displaying the preview of the page that is being shared on social media platforms, all while still having dynamic interfaces and page transitions. On the other hand, there are some SSR caveats that need to be taken into account:

1. Hosting costs
SSR puts the burden of rendering your JavaScript content on your own servers, which will rack up your server maintenance costs.

2. Slower time-to-interactive
Your user will see the content sooner, but if they click on something, nothing will happen.

3. It’s incompatible with some UI libraries
If the UI library uses window or document objects, then you will need to fix that or use something else because the web server doesn’t have window or document objects. So, for example, when you use the window object to know the size of the user’s screen, then you should use some solutions which depend on the type of framework you use with SSR (Nuxt will throw hydration errors in the console).

B. SSG (Static Site Generation)

Static Site Generation is like Server Side Rendering, with the exception that you render the pages at build time instead of request time. This means all pages will be generated into HTML and JavaScript files, and all calls to APIs will be pre-fetched and cached so that no calls to your API need to be made on client-side navigation.

This fits best if you do not need a dynamic website - with no user-specific content, meaning every user sees the exact same thing: no login, no actions that allow sending input data to the server - everything is “read-only”.
Here’s an image of the nuxt-generate command bundling a Nuxt application for production and exporting your application to static HTML in the dist directory.

Pros:

• No server costs! You can easily go for Netlify to host your website in a redundant global Application Delivery Network that serves your web pages consistently and quickly.
• Just like server-side rendering, static-site generation is immediately available and doesn’t require any additional data fetches from the API.
• Great for SEO, just as SSR, since the HTML is built before being sent to the client.

Cons:

• Build time would increase depending on the size of the application.
• Data is only fetched once at build time, so retrieving data dynamically based on user input is not possible.
• You may run into the same UI compatibility issues as in server-side generation, as the window object wouldn’t be available at build time.

 
In conclusion, neither of these acronyms is a fix-all solution. You need to assess your website’s technical needs and challenges before implementing it.

To sum this article up, I’ve noted down the essential ideas behind each rendering option:

The SSR approach is good for building complex web applications that require user interaction, rely on a database, or where the content changes frequently, and the user needs to see real-time changes while also catering for SEO. The downside would be the server maintenance costs which need to be considered.

The SSG approach is good for building low-cost applications in which the content does not change too often — sites whose content does not have to change depending on the user and don’t have user-generated content. An example of such a site would be a small presentation site or a landing page.

The CSR approach would be the way to go for an app where you don’t need to care about SEO scores or Google indexing. Yet you need to serve a more complex UI/UX where users can navigate between pages without having to make a server roundtrip (definition of SPA). All this while having the possibility to host your application on any CDN or static files host like Amazon S3 or Netlify for free or very cheap.

If you're looking for a web & mobile development partner to transform your idea into a successful digital product, we're just an email away. Contact us at contact@wolfpack-digital.com. 🙌