iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Angular supports client-side rendering (CSR), build-time prerendering (SSG), and request-time server-side rendering (SSR); hybrid rendering lets you choose among them route by route. Use prerendering for stable content available at build time, SSR when the initial page must reflect fresh or user-specific data, and CSR when browser-side interactivity matters more than immediately available, search-friendly HTML.
What are Angular rendering strategies?
A rendering strategy determines where and when Angular produces a route’s initial HTML. With CSR, the browser builds the page after loading the application’s JavaScript. With prerendering, Angular generates HTML during the build. With SSR, a server generates HTML when a request arrives. Hybrid rendering combines these modes so different routes can use different strategies.
Angular’s official documentation says that applications are client-side rendered by default. The Angular rendering guide is a rolling document rather than a release-pinned reference, so check its setup details against the Angular version used by your project: Angular hybrid rendering.
Recommended Free Tools
How do CSR, prerendering, and SSR compare?
| Strategy | When and where HTML is rendered | Good fit | Main trade-offs |
|---|---|---|---|
| CSR | In the browser, after application JavaScript loads | Interactive internal tools, dashboards, real-time applications, and routes with little search-indexing need | Browser-oriented development and no request-time server rendering; initial content waits for JavaScript to load and run, and crawlers may need to execute it |
| SSG / prerendering | At build time, producing static HTML | Marketing pages, documentation, stable catalogs, and content shared across users | Fast static responses and CDN-friendly deployment; content must be available at build time, updates require a rebuild, and generating many routes can increase build time or deployment size |
| SSR | On a server for each initial request | Frequently changing or personalized pages, such as dynamic product pages or feeds | Provides populated initial HTML; requires server-compatible code and request-time rendering capacity, adding hosting work and potentially cost |
| Hybrid | Chosen per route: browser, build time, or request time | Applications whose routes differ in freshness, personalization, or indexing needs | Requires route-level decisions and deployment infrastructure compatible with the selected modes |
When should you use CSR?
Choose CSR when the route’s value is primarily its browser-side behavior and neither search indexing nor immediately visible page content is a central requirement. An authenticated dashboard or live operational tool can be a reasonable fit if users are already opening the application and the interface depends heavily on browser interaction.
#1 Best Overall
The main compromise is the initial experience: users do not see the rendered application content until its JavaScript has loaded and executed. Search crawlers may also need to run that JavaScript to discover content. Consider whether the route’s important information should be visible before the client application starts.
When should you use SSG or prerendering?
Use prerendering when the HTML can be generated during deployment and can be shared by visitors without reflecting request-specific information. It suits stable public pages such as documentation, marketing content, and catalogs whose content changes on a controlled publishing schedule.
Because the output is generated at build time, publishing changes requires another build and deployment. A large set of generated routes can also make builds longer or deployments larger. If only some parameterized paths are generated, a path that was not selected is not automatically a static page; Angular’s route configuration lets you choose a fallback behavior for those paths.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Parameterised routes and fallback behavior
Angular documents getPrerenderParams for selecting parameter values to generate. For paths not prerendered, the documented fallback choices include server rendering, client rendering, or no Angular fallback. Choose based on whether those remaining paths must work dynamically, can be handled in the browser, or should not be served by Angular. See the hybrid-rendering guide for the configuration details.
Rank #3
When should you use SSR?
Choose SSR when the initial HTML must reflect data that is fresh at request time or specific to the visitor. Examples include frequently changing feeds and dynamic product pages. The server can return populated HTML on the initial request rather than waiting for the browser to construct the page.
SSR also changes the application’s operating requirements: route code and dependencies must work in a server environment, and the deployment needs capacity to render requests. Assess that ongoing server work alongside the user and indexing benefits; static hosting alone cannot perform request-time rendering.
How do you choose a strategy for each route?
Decide route by route rather than assigning one rendering mode to the entire application by habit. Work through these questions in order:
- Does the content vary by user? If it does, build-time output may be unsuitable unless the personalized portion is handled separately. Consider SSR or browser-side loading, depending on what must appear in the initial HTML.
- Must the initial page use request-time data? If freshness at the moment of the request matters, SSR is the direct fit. If the content can remain stable until the next build, consider prerendering.
- Must crawlers or users see content before JavaScript runs? If so, prefer an HTML-producing server or build-time mode for that route. CSR makes initial content wait for JavaScript execution.
- Is the required data available during a build? If not, that route cannot be fully generated from that data at build time; evaluate SSR or CSR instead.
- Do the route’s code or dependencies assume browser APIs? Server-rendered routes need server-compatible code. Browser-only initialization may need to wait until the browser is rendering.
- What deployment and build costs are acceptable? Compare static output volume and rebuild needs with the ongoing capacity and complexity required for request-time rendering.
A practical hybrid arrangement might prerender public documentation and stable landing pages, use SSR for frequently changing public routes, and keep a highly interactive internal tool client-rendered. These are examples of matching route requirements, not rules that every application should follow.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How does Angular hybrid rendering work?
Angular’s hybrid-rendering configuration assigns a rendering mode to each server route. The documented mode names are RenderMode.Client, RenderMode.Prerender, and RenderMode.Server; a wildcard route can serve as a catch-all. The Angular CLI can add SSR support to a new application with ng new --ssr or add it to an existing application with ng add @angular/ssr. Angular also documents static output configuration for deployments that serve generated files without an application server. Consult the hybrid-rendering guide for syntax and version-specific setup.
What do hydration and incremental hydration do?
SSR and prerendering supply initial HTML, but that HTML still needs to connect to the Angular application in the browser to become interactive. Hydration reuses the server-rendered DOM and restores application state or data where possible instead of simply replacing the rendered page. Server and browser output should remain consistent for a route; differences can produce hydration mismatches. Browser-only initialization should be deferred to browser render hooks where appropriate, and third-party scripts that alter the DOM before hydration can also cause mismatches. See Angular’s hydration guide.
Incremental hydration builds on SSR, hydration, deferrable views, and event replay. It allows a deferred section’s main template to be rendered on the server while the browser postpones hydrating that section until its configured trigger occurs. Eligible events that happen before hydration can be queued and replayed. Angular’s current guide describes provideClientHydration() as enabling incremental hydration by default and documents an opt-out API; confirm those defaults and APIs for the Angular release in your project. Details are in the incremental hydration guide.
Quick Recap
What should you verify before deploying?
- Each route’s rendering mode matches its freshness, personalization, and indexing requirements.
- Prerender parameters cover the paths you expect to exist as generated pages, and the fallback behavior for other paths is intentional.
- SSR code and dependencies are compatible with a server environment.
- Server-rendered and browser-rendered markup is consistent enough to hydrate without mismatches.
- Build output, static hosting, or request-time server capacity fits the chosen deployment model.
- Version-sensitive setup, hydration defaults, and APIs match the Angular release in use; the cited Angular guides do not pin their instructions to a fixed release.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
