Server-side rendering (SSR) executes an Angular application in a server-side JavaScript runtime and sends the browser HTML before the client JavaScript finishes downloading. This reduces the empty-screen delay on slow connections. Hydration then reuses the server-generated elements as the browser application starts. section 8.2 section 27.4
Choose and prepare SSR with these practical considerations:
- Use SSR when early visible content matters over slow or unreliable networks. section 8.2
- Budget for substantial server resources and provide a server-side JavaScript runtime; some production platforms may not support this requirement. section 27.4
- Prepare application features selectively because not every Angular feature works during server rendering. section 27.4
- Use anchor elements for navigation that must work in HTML-only output, and disable button-driven features until browser JavaScript is ready. section 27.4.4
- Handle server and browser differences explicitly: for example, replace location-based URLs with a server-safe URL when the web service runs on the same machine. section 8.2.3
Testing an HTML-only application
Run the SSR development command, disable JavaScript in the browser, and request the application. The returned page should display server-generated content; buttons that depend on event handlers remain inactive, while supported anchor navigation works. Re-enable JavaScript to observe hydration and the transition to the browser application. section 27.4.3 section 27.4.4
Table 27.4. The SSR commands
|
Command
|
Description
|
|
dev:ssr
|
This command builds and runs the application in development mode, with a watcher and automatic rebuilds and reloads.
|
|
build:ssr
|
This command builds the application for deployment.
|
|
serve:ssr
|
This command executes the production SSR server.
|
Use the SSR command table to distinguish development, deployment-build, and production-server workflows. section 27.4.3
