{"id":2357,"date":"2025-10-01T15:00:37","date_gmt":"2025-10-01T22:00:37","guid":{"rendered":"https:\/\/www.angulartraining.com\/daily-newsletter\/?p=2357"},"modified":"2025-10-01T15:00:38","modified_gmt":"2025-10-01T22:00:38","slug":"server-side-rendering-ssr-or-ssg-whats-the-difference","status":"publish","type":"post","link":"https:\/\/www.angulartraining.com\/daily-newsletter\/server-side-rendering-ssr-or-ssg-whats-the-difference\/","title":{"rendered":"Server-side rendering: SSR or SSG, what’s the difference?"},"content":{"rendered":"\n

I’ve covered server-side rendering<\/a> in the past, but recently realized that people get confused about SSR and SSG.<\/p>\n\n\n\n

What’s the difference? SSR stands for S<\/strong>erver-S<\/strong>ide\u00a0R<\/strong>endering, and it does what it says: when requested, an Angular route is<\/span> rendered on the server before being sent to the client as HTML syntax. <\/p>\n\n\n\n

Then, the browser loads Angular’s JavaScript code, and the process of hydration<\/strong> 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.<\/p>\n\n\n\n

SSG stands for S<\/strong>tatic\u00a0S<\/strong>ite\u00a0G<\/strong>eneration, and the process is very much the same as SSR, with one significant difference: SSG is performed at build time<\/span>, not at runtime. This is important for several reasons:<\/p>\n\n\n\n

    \n
  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<\/strong>, though Angular will take over and hydrate them on load, just like with SSR.<\/li>\n\n\n\n
  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.<\/li>\n<\/ol>\n\n\n\n

    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:<\/p>\n\n\n

    \n
    \"\"<\/figure>\n<\/div>\n\n\n

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

    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.<\/p>\n\n\n\n

    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<\/strong> function:<\/p>\n\n\n

    \n
    \"\"<\/figure>\n<\/div>\n\n\n

    The above example would have the Angular compiler pre-render the routes for \/post\/1\/foo\/3<\/strong><\/em> and \/post\/2\/bar\/4<\/em><\/strong> at build time. <\/p>\n","protected":false},"excerpt":{"rendered":"

    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\u00a0Rendering, 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,39],"tags":[],"class_list":["post-2357","post","type-post","status-publish","format-standard","hentry","category-angular","category-server-side-rendering"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t