Angular Prerendering vs SSR: When to Use Each Rendering Strategy

Angular supports both prerendering (build-time HTML generation) and server-side rendering (request-time HTML generation). They solve the same problem — delivering fully rendered HTML to crawlers and users — but with different trade-offs in build time, scalability, content freshness, and infrastructure complexity. Most production Angular applications benefit from using both strategically.

What prerendering does

Prerendering generates static HTML files at build time. When you run ng build with prerendering enabled, Angular renders each configured route and saves the resulting HTML as a file. At request time, the server delivers this pre-built HTML directly — no Node.js runtime, no rendering on the fly.

// angular.json (simplified)
{
  "architect": {
    "build": {
      "options": {
        "prerender": {
          "routesFile": "routes.txt"
        }
      }
    }
  }
}

The routes.txt file lists every route that should be prerendered:

/
/articles/angular-signals-guide
/articles/angular-ssr-seo-playbook
/about

Prerendering strengths

• Fastest possible TTFB — HTML is served from disk or CDN without server computation
• No runtime server required — deploy to S3, CloudFront, Netlify, or any static hosting
• Predictable output — the same build produces the same HTML every time
• CDN-friendly — static files cache perfectly at the edge
• Lower infrastructure cost — no Node.js servers to manage or scale

Prerendering limitations

• Build time scales with route count — 1,000 routes means 1,000 renders at build time
• Content staleness — changes require a new build and deploy cycle
• No dynamic per-request content — user-specific or real-time data cannot be prerendered
• Route list maintenance — you must know all routes at build time

What SSR does

Server-side rendering generates HTML on each request. When a user or crawler hits a route, an Angular server application renders the page in Node.js and returns the HTML response. The client then hydrates the server-rendered markup to add interactivity.

// server.ts (Angular SSR entry point)
import { CommonEngine } from '@angular/ssr/node';
import express from 'express';

const app = express();
const engine = new CommonEngine();

app.get('*', async (req, res) => {
  const html = await engine.render({
    bootstrap,
    documentFilePath: indexHtml,
    url: req.url
  });
  res.send(html);
});

SSR strengths

• Always fresh content — each request renders the current state
• Handles dynamic routes — user profiles, search results, and paginated lists work naturally
• No route list needed — any route the Angular router handles can be server-rendered
• Per-request personalization — headers, cookies, and query parameters can influence the response

SSR limitations

• Requires a Node.js server — you need infrastructure that runs server-side JavaScript
• Higher TTFB — rendering takes time per request (typically 50–200ms for Angular)
• Server costs scale with traffic — more requests means more compute
• Cold start risk — serverless SSR deployments may have latency spikes
• Caching complexity — you need cache strategies (CDN, reverse proxy) to avoid rendering the same page repeatedly

How Angular handles both

Since Angular 17+, the Angular CLI supports both prerendering and SSR in the same build. The angular.json configuration lets you specify which routes to prerender while the SSR server handles everything else as a fallback.

{
  "architect": {
    "build": {
      "options": {
        "prerender": {
          "routesFile": "routes.txt"
        },
        "server": "src/main.server.ts",
        "ssr": {
          "entry": "server.ts"
        }
      }
    }
  }
}

With this setup:

1. Routes listed in routes.txt are prerendered at build time as static HTML
2. All other routes fall through to the SSR server for runtime rendering
3. Hydration activates on the client for both prerendered and SSR pages

Prerendering vs SSR — comparison

The hybrid strategy: prerender what you can, SSR the rest

The best Angular production setups combine both approaches:

Prerender

• Home page and main landing pages
• Article detail routes (known at build time from CMS or content files)
• Category and tag listing pages
• Static pages (about, privacy, terms)

SSR

• Search results and filtered views
• User-specific pages (dashboards, profiles)
• Paginated routes beyond what is practical to prerender
• Fallback for any route not in the prerender list

Automate the route list

Generate the prerender route list from your content source to prevent drift:

import { writeFileSync } from 'fs';
import articles from './content/manifest.json';

const routes = ['/', '/about', '/articles'];

for (const article of articles.filter(a => !a.draft)) {
  routes.push(`/articles/${article.slug}`);
}

writeFileSync('routes.txt', routes.join('\n'));

This script runs before ng build, ensuring every published article is prerendered without manual maintenance.

When to use each approach

Choose prerendering only when

• Your site is entirely static content (blog, docs, marketing pages)
• You want zero server infrastructure
• Build times are acceptable for your route count
• Content changes are infrequent (daily or less)

Choose SSR only when

• Most content is dynamic or personalized
• Routes cannot be known at build time
• You already have Node.js server infrastructure
• Content changes in real time and must reflect immediately

Choose hybrid (recommended for most Angular apps) when

• You have a mix of static content and dynamic features
• You want fast TTFB for core content pages with SSR as fallback
• Your team can manage both static hosting and a Node.js server
• SEO is important for content pages but some routes are user-specific

FAQ

Does prerendering produce better SEO than SSR?

Both deliver fully rendered HTML to crawlers, so SEO outcomes are equivalent when implemented correctly. Prerendering has a slight edge in TTFB, which can improve Core Web Vitals scores, but the difference is small for well-cached SSR pages.

Can I prerender thousands of routes in Angular?

Yes, but build times will increase. For sites with thousands of routes, consider prerendering only high-traffic pages and using SSR for the long tail. Angular’s build system parallelizes prerendering, but each route still requires a render cycle.

Do I need hydration for prerendered pages?

Yes. Prerendered pages are static HTML. Hydration attaches Angular’s event listeners and reactive bindings so the page becomes interactive. Without hydration, buttons, forms, and navigation will not work after the initial render.

Should I prerender routes with query parameters?

Generally no. Query parameter variations (filters, pagination, search) create a combinatorial explosion of routes. Use SSR for routes that depend on query parameters and prerender only the base route.

How do I invalidate prerendered pages when content changes?

Rebuild and redeploy. For sites with frequent content changes, automate this with a CI/CD pipeline triggered by content updates. If rebuilding the entire site is too slow, consider incremental static regeneration patterns or switching high-churn pages to SSR.

Conclusion and next steps

Prerendering and SSR are complementary tools, not competing choices. Prerender your stable, high-value content pages for maximum performance and minimal infrastructure. Use SSR for dynamic routes, personalized content, and fallback coverage. The hybrid approach gives you the best of both worlds without over-engineering either side.

Start by auditing your routes: identify which ones are static and predictable (prerender candidates) and which depend on request-time data (SSR candidates). For a complete production setup including metadata, structured data, and sitemap generation, read the companion article Angular SSR SEO Playbook. For sitemap generation that stays in sync with your prerendered routes, see Angular SSR Sitemap Generation.