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, 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 use to build websites, the examples used being in regard to Nuxt.js.

Now, for a FE (front-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 what that is so that you won’t get as confused as I was. 😄

CSR stands for Client Side Rendering, and SPA for Single Page Application. Client Side Rendering 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. In SPAs, the initial HTML response from the server is often just a bare-bones html template, which is then dynamically populated with content by JavaScript. So, Client Side Rendering 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 JavaScript rendering. 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 have made this clear, I hope you’ll understand why both CSR and SPA are used throughout this article in different contexts.

What is a Single Page Application?

A Single Page Application (SPA) is a type of web application that loads and updates content dynamically without refreshing the entire page. During the initial page load, all necessary HTML, CSS, and JavaScript files are downloaded at once, which is crucial for the performance of SPAs. Imagine browsing a website where every click doesn’t result in a full-page reload. Instead, only the necessary content changes, making the experience much smoother and faster. This is the magic of SPAs. By ensuring that the browser obtains all essential HTML, JavaScript, and CSS codes in one go or updates the necessary content based on user actions, SPAs eliminate the need for full-page reloads. This results in a more responsive and engaging web experience, making users feel like they’re interacting with a native app rather than a traditional web page.

SPA Architecture

The architecture of a single-page application is designed to dynamically rewrite the current web page with new data from the web server. In contrast, a traditional page load requires the server to send a full page with every user interaction, resulting in more interruptions and slower load times. This approach is crucial for maintaining a seamless user journey, especially for websites in digital commerce. By reducing the lag time between successive pages, SPAs make the site behave more like a desktop application, providing a fluid and comfortable experience. Traditional websites require the entire page to be reloaded and rendered by the server every time a user navigates, which can lead to slower and less fluid user experiences. Traditional multi-page websites send a complete HTML file for each page, painting the entire picture for the user on the server. In contrast, a SPA sends a paint-by-numbers guide, including repeating elements like headers, footers, and navigation bars, and then fills in the right data and content to complete the template. This efficient use of resources ensures that users get a faster and more interactive experience.

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.

Minimizing the time taken for the initial load is crucial as it directly impacts user experience and SEO. Techniques such as selective prerendering, caching, and progressive loading can significantly enhance performance by ensuring users access content more quickly.

Aaaand drumrolls, please! 🥁🥁🥁

Client-Side Rendering (CSR)

Client-Side Rendering (CSR) is a rendering mode where the client’s web browser is responsible for rendering the web application’s content. In CSR, the server sends a minimal HTML file to the client, which then uses JavaScript to render the content. This approach is commonly used in Single Page Applications (SPAs) and provides a fast and seamless user experience. Imagine visiting a website where, instead of reloading the entire page with each click, only the necessary parts update dynamically. This not only makes the interaction smoother but also reduces the load on the server. However, CSR can pose challenges for SEO since search engine crawlers might struggle to index content that relies heavily on JavaScript.

Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is a rendering mode where the server is responsible for rendering the web application’s content. In SSR, the server generates the HTML content and sends it to the client, which then displays the content to the user. This approach is commonly used in traditional web pages and provides better search engine optimization (SEO) and faster initial page loads. When you visit a website using SSR, the server does the heavy lifting by generating the complete HTML before sending it to your browser. This means that the content is immediately visible, which is great for both user experience and search engines. However, SSR can increase server load and may result in slower time-to-interactive for users.

Static Site Generator (SSG)

Static Site Generation (SSG) is a rendering mode where the web application’s content is generated statically at build time. In SSG, the server generates the HTML content and stores it in a static HTML file, which is then served to the client. This approach is commonly used in blogs and documentation sites and provides fast page loads and improved SEO. Think of SSG as pre-cooking a meal and storing it in the fridge, ready to be served whenever needed. Since the content is pre-rendered, it loads quickly and is easily indexed by search engines. However, SSG is best suited for sites with content that doesn’t change frequently, as updates require a rebuild of the static files.

How important is SEO for this web app?

A. Not important => Client Side Rendering 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 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, single-page applications now have smoother transitions between pages and feel almost like native apps.

But what about Single Page Application 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. JavaScript files are crucial for fetching dynamic content and updating the HTML displayed to users, but they pose challenges for search engines that do not execute these files, leading to indexing issues.

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).

Web app performance may suffer, too, since rendering happens entirely on the client side, relying heavily on the user’s device power and network speed.

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 for search engines ⇒ Server Side Rendering (SSR) or Static Site Generation (SSG)

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 users 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 that 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, except 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 like 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 is done with the possibility of hosting your application on any CDN or static file 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. 🙌