What is SSR, or Server-Side Rendering?

When we talk about fashion, we tend to say that it repeats itself and that outdated clothes suddenly become "trendy" again, well we're seeing exactly the same thing with certain technologies, especially in the web world!

And that's exactly what we're experiencing with SSR!

With the arrival of the first version of AngularJS in 2010, SPAs (Single-Page Applications) monopolized all the attention to the point of becoming the standard for starting any new project.

But for a few years now, the trend has been reversing and SSR is once again in the spotlight, but what exactly does it consist of?

That's what we're going to look at today!

The Principle

Before talking about how "Server-Side Rendering" works, we first need to explain how "Single-Page Applications" work in order to properly understand what differentiates these two paradigms.

In the case of a "classic" SPA, here's what happens in terms of communication between the client and the server:

• The client sends an HTTP[GET] / request to the server
• The server returns an almost empty index.html page containing only the links to the application's JS and CSS resources
• The browser fetches the indicated resources
• The browser loads the application into memory and launches it
• The application loads the view requested by the user
• Once the view is loaded, the application requests the data to be injected into the page from the server by sending one or more HTTP requests
• The server makes calls to the database, prepares and sends the data
• If the returned data contains multimedia content, the browser will have to load it
• Only at the end can the user view the requested page containing all the loaded information

But in the case of a site running with SSR, communications are different:

• The client sends an HTTP[GET] / request to the server
• The server takes charge of building the view
• The server makes calls to the database, prepares and injects the data into the view
• Then it returns a single HTML file already containing all the content, along with links to any external resources
• The browser loads any resources (js, css, images, videos, etc.)
• The page is fully available to the user

As you will have understood, in the first method, it's the client browser that takes charge of making all the data requests, multiplying HTTP requests, and it's the client application that decides where to inject all the data.

With SSR, the browser's only purpose is to load a page and a few external resources, and it's up to the server to do all the rest of the work.

The Advantages of SSR

• Better SEO performance, since all textual content is available after the first load, and although Google and Bing are capable of crawling SPAs, they never wait for asynchronous content to load
• Faster content loading times, especially on slow internet connections, since the user doesn't need to wait for all the application code to load before being able to access the content
• The number of http requests is reduced
• It is now possible to develop SSR apps with the same libraries as for the front end (React, Vue, or Angular) by adding an SSR framework on top.

The Disadvantages

• There are visible loading times between each page
• The server load can be greater since the work previously done on the client machine is now done on the server
• The front-end deployment environment is more complex since it no longer requires just static web hosting, but a NodeJS environment, for example.

Conclusion

SSR provides solutions to the problems posed by SPAs, particularly regarding the site's natural referencing (SEO), but there is no better solution between the two, you need to choose between SSR or an SPA based on the needs and constraints of the project.

Don't let yourself be influenced by the current trend, make informed and well-considered decisions!