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.

Standalone, SSR, and more!

In the new format of this weekly newsletter, I’m posting a few essential articles to revisit, updates to know about, and one question to ponder this week:

Three short articles to revisit:

  • Standalone components as they’re about to become the default in Angular 19. No more standalone: true will be needed, true will be the default value, and automatic migrations will add standalone: false to module-based components.
  • Look at the standalone components cheat sheet for an overview of all standalone-related features, including lazy-loading.
  • What you need to know about ngModules and why they don’t really matter anymore.

Two updates to know about:

  • Incremental hydration update from the Angular team on YouTube. This is only for server-side rendering, but I’d suggest you take a look anyway, as this video has some cool stuff.
  • The Angular Senior Certification Exam (aka level 3) is now live again! No more final interviews are needed, but two challenging coding exercises will test your Angular skills like never before.

One question to think about:

Have you considered SSR (server-side rendering) to boost performance? Even just using SSG can be a massive win performance-wise (the application is pre-rendered at build time)

Talks on Signals, SSR, and Angular 18

I’m giving several talks at free conferences and events this week, so I thought I would share those with you in case you’re interested. As always, all of these are free for you to enjoy.

Two of those events already have a recording available on YouTube:

Then I’m speaking about Signals at Frontend Nation on Wednesday (25-minute intro to Signals at 11 am US/Pacific) and Friday (2-hour workshop on Architecting Angular apps with Signals). You can register here.

Last but not least, I’m doing a webinar with ng-conf on that same topic next Tuesday. Registrations are open here as well:

This will close my marathon of talks for June! We’ll be back to our regular weekly newsletter next week.

Angular 17: Signals, Server-side rendering, and Standalone

We’re not done with Angular 17 updates! Here are a few more updates on Signals, Standalone, and Server-side rendering.

Signals

Signals have graduated from developer preview and are now officially part of the framework, except the effect function that is still being tweaked by the Angular team. A big step for Angular Signals.

Standalone

With Angular 17, a new Angular app is generated with standalone components by default. You can upgrade your Angular CLI to test that out, and if you don’t want to use standalone by default and your new apps, this feature can be turned off in angular.json with the following config:

   "projects": {
    "my-app": {
      "schematics": {
        "@schematics/angular:component": {
          "standalone": false
        }
     Code language: JavaScript (javascript)

Server-side rendering

With Angular 17, you can create an app that uses server-side rendering with a single command:

ng new --ssr

If you want to add server-side rendering to an existing app, you can run:

ng add @angular/ssr

It’s also possible to pre-render an Angular app using:

ng build --prerender

That way, you don’t need Node.js hosting and can use static, pre-rendered HTML files. I’ll explore this more in the newsletter before the end of the year.

On that same topic of server-side rendering, hydration graduated developer preview, which means an app rendered on the server side won’t rebuild its entire DOM in the browser. Instead, Angular will take over that DOM and re-hydrate it with up-to-date data as needed.