Server-side rendering (SSR) generates an Angular application’s initial HTML on a server and sends that rendered document to the browser. It contrasts with client-side rendering (CSR), where the browser receives a largely empty root element, downloads Angular and application scripts, then renders the page itself. section 9.1.1 section 9.1.2
SSR is most useful for public-facing pages such as landing pages, marketing sites, and blogs. Serving ready HTML avoids delaying visible rendering until JavaScript downloads and executes, improving initial-load metrics such as Largest Contentful Paint and time to interactive; it also addresses SEO concerns for crawler-facing pages. The trade-off is contextual: an internal enterprise application may not need the same initial-load optimization. section 9.1 section 9.1.2
Modern Angular integrates SSR support that formerly required the separate Angular Universal package. Start a new SSR project with Angular 17 or later using `ng new hrms-promo --ssr`. The generated setup includes `@angular/ssr`, Express by default, server build configuration, `server.ts`, and a separate `main.server.ts` bootstrap path alongside the usual browser entry point. section 9.1 section 9.2 section 9.2.1
An Angular SSR application separates responsibilities while preserving normal client behavior:
- `main.ts` bootstraps the browser application; `main.server.ts` exports a bootstrap function for server rendering. section 9.2.1
- Server configuration adds `provideServerRendering()`, while shared application configuration can include `provideClientHydration()` for client reconciliation with server-rendered DOM. section 9.2.1 section 9.6
- The generated Express server serves static browser assets and routes remaining requests through Angular’s server rendering engine. section 9.2.1
- `ng serve` still runs the project locally; inspecting page source verifies SSR when `app-root` already contains rendered component HTML. section 9.2.2
A promotional HRMS page
A promotional site can render a title binding and button markup into the initial HTML, then retain normal Angular interactivity after delivery: clicking a button can update the title in the browser. This makes SSR suitable for an initially content-heavy page without giving up interactive components. section 9.2.2
Listing 9.6 SSR Angular app served in the browser
<!DOCTYPE html>
<html lang="en">
<head>
<script type="module" src="/@vite/client"></script>
<meta charset="utf-8">
<title>HrmsPromo</title>
<base href="/">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" type="image/x-icon" href="favicon.ico">
<link rel="stylesheet" href="styles.css">
</head>
<body><!--nghm-->
<app-root _nghost-ng-c2553731897=""
ng-version="17.0.0-rc.1" ngh="0"
ng-server-context="ssr">
<div _ngcontent-ng-c2553731897="">This is the hrms-promo app!</div><router-outlet
_ngcontent-ng-c2553731897=""></router-outlet><!--container-->
</app-root>
<script src="polyfills.js" type="module"></script>
<script src="main.js" type="module"></script>
<script id="ng-state" type="application/json">{"__nghData__":[{"c":{"2":[]}}]}</script>
</body>
</html>
The rendered response shows `app-root` populated with component HTML and server-rendering markers before browser scripts run. section 9.2.2
SSR and prerendering can be combined. Prerendered routes are generated at build time and served from the browser output, while routes with dynamic parameters can be rendered per request. Full SSR deployment therefore needs hosting capable of running Node.js, typically starting generated `server.js` and supplying a listening port. section 9.4.4 section 9.6
