Server-side rendering: SSR or SSG, what’s the difference?

I’ve covered server-side rendering in the past, but recently realized that people get confused about SSR and SSG.

What’s the difference? SSR stands for Server-Side Rendering, and it does what it says: when requested, an Angular route is rendered on the server before being sent to the client as HTML syntax.

Then, the browser loads Angular’s JavaScript code, and the process of hydration starts: Angular takes over the “static” DOM built from our server and hooks its component code to it. In other words, front-end JavaScript takes over from that point on.

SSG stands for Static Site Generation, and the process is very much the same as SSR, with one significant difference: SSG is performed at build time, not at runtime. This is important for several reasons:

1. The pre-rendered SSG pages can be generated weeks, if not months, before being displayed in a browser, which means they can display stale data. They don’t get updated after that last ng build, though Angular will take over and hydrate them on load, just like with SSR.
2. SSG doesn’t require a Node.js server, but SSR does. The build output of SSG can be used as-is and deployed to any web server, like a regular client-side Angular app.

Now, how to choose between the two options? Well, the good news is that it doesn’t have to be the same choice for all routes. In an SSR app, a server-side router config is generated, and that file can be tweaked to do SSR, SSG, or even just client-side rendering based on the route:

The above example makes perfect sense: An about page doesn’t change between builds. It can be pre-rendered with SSG.

A profile page depends on user data, so this doesn’t make sense to pre-render at build time. SSR or client-side rendering are the two best options.

Last but not least, what if we want to pre-render routes that use parameters? We can do so by adding a list of param values to pre-render routes with the getPrerenderParams function:

The above example would have the Angular compiler pre-render the routes for /post/1/foo/3 and /post/2/bar/4 at build time.