Server-side rendering (SSR) is a technique for rendering a normal client-side app on the server and sending a fully rendered page as a response to the client. This results in improving user experience as content is shown faster and it gives enough time for the whole frontend app to load.

However, this is not the most important thing that you get with SSR. The main use is related to providing web crawlers crawlable content so you could improve your search engine optimisation (SEO). In regular client-side rendering (CSR) apps using Angular, text in the HTML is inserted by JavaScript. For most crawlers, this does not provide any information because they usually parse regular HTML (page source) and content is not present there. However, Google’s crawler is capable of parsing JavaScript . Even if you don’t care about the other crawlers, this doesn’t remove the need for SSR. Sharing content on social media is a very important thing nowadays and preview pages are just not working without it.

In this blog post we are going to focus on explaining the main difference between two types of SSR: dynamic and static. After theoretical information, a step by step guide will explain the differences.

Dynamic SSR

This concept requires using a live Node.js server that will generate and serve SSR content. A regular Angular CSR app is typically served as static js bundles by a web server or CDN. If you want dynamic SSR for several pages, it needs to forward the request to the Node.js server for the SSR pages. Every time the Node.js server receives a request it executes the Angular application on the Node.js server and returns the resulting HTML to the browser.

This affects the performance (compared with static pre-rendering) because on every request the Node.js needs to render the app. This can be improved with caching the requests. However, implementing a caching solution with SSR requires some effort ( step-by-step guide ).

When should you use it?

• Your application is very dynamic.
• You have live data that you need to populate immediately.
• Your application content is rendered based on external sources eg. a CMS where anything could change at any time.

Static Pre-Rendering

As the name says, this approach uses a pre-built version of the app in order to provide the benefits of SSR. You (or your CI system) generate the pre-rendered site with a simple angular CLI command. With this approach the Angular app can be deployed on any server which serves static files.

Here we are not waiting for Node.js to process the request so it will provide better performance. This approach is suitable for content heavy sites where the pre-rendering command can easily be triggered on every change. Remember that whenever changes are needed, you have to run the build script again and publish content of the dist/ folder.

When should you use it?

• Your application or the routes you are trying to pre-prender are rather static (e.g. home.html, about.html, contact.html, etc).
• Your application doesn’t update that often and when it does you can trigger the pre-render command.

Demo

In this demo the key differences between the two approaches will be presented. In order to start, clone the repo from github and follow along. Once you’ve done that, start the project with ./cli/startproject.sh . This script starts two different setups. One for the dynamic SSR at http://localhost:8090 and the other for static pre-rendering at http://localhost:8080 .

Navigate to http://localhost:8090/public and note how the text quickly changes from: Rendered by Server to Rendered by Browser .

Now open a new tab and navigate to http://localhost:8080/prerender (be careful to specify port 8080). Recognise that the same text switch occurs. Finally, browse to http://localhost:8090/browser where just the text Rendered by Browser is shown. That means this route is not server-side rendered.

In order to continue with the tutorial you will need to disable JavaScript of your prefered browser. On Chrome you can do that by opening the developer console, then opening the run command ( explanation ) and typing “disable javascript”. You can enable it again with the same procedure and typing “enable javascript”. In Mozilla Firefox you can do it by going into the developers console and then to “Settings”. This process should be similar for all the other browsers too. Important note: do this for every tab that you have opened in this tutorial.

Once that is done, check http://localhost:8090/browser . It should be blank, because this page does not use SSR and we have just disabled JavaScript. Now go back to the tabs http://localhost:8090/public and http://localhost:8080/prerender . There you will still see the content and the message saying Rendered by Server .

In order to demonstrate the difference between dynamic SSR and static pre-rendering you have to do multiple page refreshes (F5) for both of them. Be sure that JavaScript is disabled for both. Now check the current time for both of them. You will see that http://localhost:8080/prerender always has the same time. That is because this content has been generated when the app was built. On the opposite, http://localhost:8090/public generates new versions by every request so the timestamp changes every time.

Conclusion

When choosing SSR you should opt for one of the two existing approaches: dynamic SSR or static pre-rendering. Depending on whether your app content is more static or dynamic you should decide for one of these two. For most of the sites that have static pages like “about us”, “contact”, or landing pages pre-rendering would be enough. If you are interested in a step-by-step guide on how to implement dynamic SSR check out our blogpost .

Do you want more assistance or input on how to choose and implement Server Side Rendering on your own website or app?

Get in touch