Angular 9 Server Side Rendering Types & Demo
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.
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.
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.
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
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.
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
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.
Rendered by Server.
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?