When working on a web application it is important to take into account if we want our content to be positioned effectively in the different existing search engines. It goes without saying how important SEO can be in a web application. The indexing of our content will be a point to take into account when deciding how and with what technology we will make our content to be rendered.

In this post, we are going to focus on the server-side rendering (SSR), since we commonly work with reactive frameworks and much of the content is usually dynamic, which makes server-side rendering a good option.

What is web rendering?

Rendering is the process of transforming the HTML code (which forms the HTML code) into a DOM), CSS (the styles) and JS (the logic) into a visual representation of it that users can interact with. How and when to do this transformation will depend on the rendering technology we are using.

What types of rendering are there?

It should be noted that until the emergence of JS frameworks or libraries such as jQuery rendering was always done on the server. Because of this most of the bots indexing or spiders do not index the content of sites with CSR, because they do not execute JS and cannot see the final result of the content.

Currently there are several types of rendering, although the most common are Server Side Rendering (Server-Side Rendering (SSR)), Client Side Rendering (Client-Side Rendering (CSR)) and Static Rendering (Static Rendering or (SR)).

Let's see a short explanation of how SCR and SR renderings work. Later on we will see the SSR in a more extensive way.

Client-Side Rendering (CSR)

When rendered on the client side, the client browser downloads the HTML code of the page. In this first load could come the information or just an empty HTML. Then, the browser downloads and executes scripts JavaScript that are responsible for creating and dynamically rendering the content on the client side. This is the rendering common in SPAs (Single Page Applications).

Static Rendering

Static HTML is generated during the build or compilation phase of the web site and then stored on the web server. The HTML is served directly to the user's browser without additional processing on the server or client side.

Before the emergence of languages server side (as PHP, Python, Ruby) this was the usual way of serving the content.

Server-Side Rendering (SSR)

As the name explains the first rendering, in this case, takes place on the server side.

Let's see how it works.

1. A user accesses the URL of our web application and the browser in use sends a request to our web server.
2. The server receives the request and processes it. It generates dynamic HTML code depending on the possible business rules that affect the web, for example by querying a database and processing that information.
3. The generated HTML is sent as a response to the client (browser) and displayed (rendered).
4. (Optional) Hydration (interactive functionalities and events), if required, would be done on the client side.

What are the advantages of SRH?

• Allows dynamic content indexing (SEO).
• Allows the website to load immediately visible content in the browser, improving the user experience.
• Improves accessibility by enhancing the experience in browsers with limited JavaScript support.
• Improves performance on low-resource devices because some of the content is processed on the server.

SSR in reagent frameworks

To describe it briefly, a framework reactive is one that is updated when there is a change without having to reload the entire page we are visiting.

Its benefits are many and are more than accepted, but the frameworks reagents, e.g. Vue y React (which is really a library) by themselves do not allow indexing dynamic content. By not indexing this content, search engines will not take it into account and it goes without saying how important SEO can be for certain websites.

We can implement the SSR using libraries or by using a framework to provide us with this functionality. Two examples of frameworks recommended would be for these cases:

Nuxt.js - Based on VUE

Next.js - Based on React

When to use SSR?

If we are working on a project with any of the aforementioned technologies (VUE/React), which is quite common since the virtues they provide us are more than known and are widely adopted by the community, it will be essential to render on the server side whenever we want our dynamic content to be positioned.

If SEO is not a requirement and initial load is not a problem, there is no need to shoehorn in SSR. As we said before, we must apply the right technology at all times.

Conclusion

We have to be aware that not always the needs of our websites can be defined in a binary way. We may find ourselves with a mixed environment in which some content is taken into account for SEO and there is other content that we do not need to position. For example, a marketplace where we want our products to be taken into account for SEO but where the user's shopping cart is left out of that scope. In this case we could have a single project with content that renders on the server and another that does not, or even have 2 different projectors, one focused on SEO and the other on the needs of users.

In short, how to render our application is an important decision that will depend on the characteristics and needs of each project. When one of these needs is SEO positioning, rendering on the server will be a very important option to take into account and almost indispensable if we work with a reactive technology.