This guide helps you choose the right rendering strategy for different parts of your Angular application.
What are rendering strategies?
Rendering strategies determine when and where your Angular application's HTML content is generated. Each strategy offers different trade-offs between initial page load performance, interactivity, SEO capabilities, and server resource usage.
Angular supports three primary rendering strategies:
- Client-Side Rendering (CSR) - Content is rendered entirely in the browser
- Static Site Generation (SSG/Prerendering) - Content is pre-rendered at build time
- Server-Side Rendering (SSR) - Content is rendered on the server for the initial request for a route
Client-Side Rendering (CSR)
CSR is Angular's default. Content renders entirely in the browser after JavaScript loads.
When to use CSR
✅ It can be a good fit for:
- Interactive applications (dashboards, admin panels)
- Real-time applications
- Internal tools where SEO doesn't matter
- Single-page applications with complex client-side state
❌ When possible, consider avoiding it for:
- Public-facing content that needs SEO
- Pages where initial load performance is critical
CSR trade-offs
Aspect | Impact |
---|---|
SEO | Poor - content not visible to crawlers until JS executes |
Initial load | Slower - must download and execute JavaScript first |
Interactivity | Immediate once loaded |
Server needs | Minimal outside of some configuration |
Complexity | Simplest because it works with minimum configuration |
Static Site Generation (SSG/Prerendering)
SSG pre-renders pages at build time into static HTML files. The server sends pre-built HTML for the initial page load. After hydration, your app runs entirely in the browser like a traditional SPA - subsequent navigation, route changes, and API calls all happen client-side without server rendering.
When to use SSG
✅ It can be a good fit for:
- Marketing pages and landing pages
- Blog posts and documentation
- Product catalogs with stable content
- Content that doesn't change per-user
❌ When possible, consider avoiding it for:
- User-specific content
- Frequently changing data
- Real-time information
SSG trade-offs
Aspect | Impact |
---|---|
SEO | Excellent - full HTML available immediately |
Initial load | Fastest - pre-generated HTML |
Interactivity | After hydration completes |
Server needs | None for serving (CDN-friendly) |
Build time | Longer - generates all pages upfront |
Content updates | Requires rebuild and redeploy |
📖 Implementation: See Customizing build-time prerendering in the SSR guide.
Server-Side Rendering (SSR)
SSR generates HTML on the server for the initial request for a route, providing dynamic content with good SEO. The server renders HTML and sends it to the client.
Once the client renders the page, Angular hydates the app and it then runs entirely in the browser like a traditional SPA - subsequent navigation, route changes, and API calls all happen client-side without additional server rendering.
When to use SSR
✅ It can be a good fit for:
- E-commerce product pages (dynamic pricing/inventory)
- News sites and social media feeds
- Personalized content that changes frequently
❌ When possible, consider avoiding it for:
- Static content (use SSG instead)
- When server costs are a concern
SSR trade-offs
Aspect | Impact |
---|---|
SEO | Excellent - full HTML for crawlers |
Initial load | Fast - immediate content visibility |
Interactivity | Delayed until hydration |
Server needs | Requires server |
Personalization | Full access to user context |
Server costs | Higher - renders on the initial request for a route |
📖 Implementation: See Server routing and Authoring server-compatible components in the SSR guide.
Choosing the Right Strategy
Decision matrix
If you need... | Use this strategy | Why |
---|---|---|
SEO + Static content | SSG | Pre-rendered HTML, fastest load |
SEO + Dynamic content | SSR | Fresh content on the initial request for a route |
No SEO + Interactivity | CSR | Simplest, no server needed |
Mixed requirements | Hybrid | Different strategies per route |
Making SSR/SSG Interactive with Hydration
When using SSR or SSG, Angular "hydrates" the server-rendered HTML to make it interactive.
Available strategies:
- Full hydration - Entire app becomes interactive at once (default)
- Incremental hydration - Parts become interactive as needed (better performance)
- Event replay - Captures clicks before hydration completes
📖 Learn more:
- Hydration guide - Complete hydration setup
- Incremental hydration - Advanced hydration with
@defer
blocks