Zero Prerendered Articles: Why Prerendering Everything Is a Build Risk, Not an Optimization

"Prerender everything you can" is the tutorial advice anyone who writes SSR with Angular has heard at least once. It is good advice at 50 pages. On this portfolio, with over 1200 blog articles and weekly growth, prerendering every single article page was never the choice: it was deliberately excluded, and the code declares it in a comment, not in hindsight after an incident.

Method disclaimer: this is not a theoretical recommendation about rendering strategy. It is a direct reading of frontend/src/app/app.routes.server.ts, the file that configures this exact site's SSR strategy, verifiable by anyone with access to the repository.

The datum: 50 prerender vs 134 server-on-demand

The exact count of route configurations in app.routes.server.ts:

• 50 configurations with RenderMode.Prerender (homepage, category pages, static pages).
• 134 configurations with RenderMode.Server (blog articles, dynamic parameter routes).
• 1 configuration with RenderMode.Client.

The comment at the top of the file is explicit: "Blog articles: Server-rendered on demand (too many for build-time prerender)". It is not a post-hoc excuse for a performance problem: it is an architectural decision written upfront, as design rationale, not as a justification after the fact.

Why "prerender everything" stops being safe advice

Build-time prerender has a huge advantage: every static page becomes a ready HTML file, served by Nginx without ever touching the Node process in production. Near-zero time-to-first-byte, no runtime load, minimal attack surface.

The problem shows up once the number of pages to prerender crosses a certain order of magnitude. Every prerendered page has to be built during the build process: more pages, slower builds, more memory required, higher odds that a single article with an SSR rendering bug (a component that throws on malformed data) fails the entire build process, blocking the deploy of ALL content, not just the one article with the bug.

With over 1200 blog articles, prerendering all of them means a single broken article can prevent the entire site from deploying. With server-on-demand rendering, that same broken article throws an error only when (and only if) someone visits it, isolated from the rest of the site, which keeps working.

The real trade-off: TTFB versus build stability

There is no universally correct answer between prerender and server-on-demand: it is a trade-off to be measured, not assumed as dogma. The two sides:

• Prerender: near-zero TTFB, no runtime load on the Node process, but the build grows linearly with the number of pages and a single rendering error can block the deploy of the entire site.
• Server-on-demand: stable, fast build regardless of page count, failure isolation (a broken article does not block the others), but higher per-request TTFB and real runtime load on the Node process in production.

The threshold at which it is worth switching from one to the other is not obvious and depends on how fast content grows, how reliable the content-generation pipeline is, and how much the team can tolerate a deploy blocked by a single broken file. On this portfolio, with content generated in batches (sometimes hundreds of articles per phase) and an agentic system writing runtime HTML, the risk of a single malformed file blocking the ENTIRE deploy was considered unacceptable: hence the decision to exclude articles from prerender from the very start.

The apparent contradiction with "1080 prerendered routes"

This project's internal documentation often cites "around 1080 prerendered routes" as a site statistic. That does not contradict this article: that number describes the total static, per-language, and per-category routes that fall under the 50 RenderMode.Prerender configurations (each of which can expand into dozens of concrete URLs across the 7 AOT-compiled languages), not the 1200+ blog articles, which remain deliberately outside that count and are served on-demand. The distinction between "how many route configurations" and "how many concrete URLs each configuration generates" is where most surface-level discussions of prerender go off track.

When prerendering everything really is the right choice

On a site with a stable, known-in-advance page count (a portfolio with 15 pages, a corporate showcase site, a technical documentation site with a hundred versioned pages), prerendering everything remains the correct choice with no asterisks: the build cost is fixed and predictable, and the near-zero TTFB advantage has no real downsides. The problem is not prerender itself: it is applying it as dogma to a content model that grows without a known upper bound.