Prerender first, hydrate second

The fastest server request is the one that never happens. For content-heavy marketing sites and large parts of enterprise portals, most routes do not need a per-request render. They need a correct HTML document at the edge and a small amount of JavaScript to take over.

Angular’s hybrid rendering gives us three levers: server render per request, prerender at build time, and client render. The interesting decision is which route gets which one.

Default to prerender

If a page is the same for every visitor, prerender it. Product pages, service pages, documentation, case studies, and most marketing content fall into this bucket. Build-time rendering produces real HTML for crawlers and a first paint limited by the CDN. No Node process sits in the request path.

On Firebase Hosting that HTML is served from the edge with immutable asset caching. The server tier disappears from the hot path entirely. For a site like this one, every route is prerendered and the runtime cost of a page view is effectively zero.

Hydration should earn its place

Prerendered HTML still needs interactivity. The goal is to load less JavaScript. Split by route, keep shared UI small, and avoid importing a component library for four icons. Angular’s incremental hydration lets the page become interactive in pieces, but the biggest win is still not shipping the code at all.

We set a budget per route: initial JavaScript, font bytes, and largest contentful paint. Releases that exceed the budget fail the pipeline. A budget nobody enforces is a wish.

When to render per request

Authenticated dashboards, personalised pricing, and anything that depends on a session should not be prerendered. Those routes can render on the server or the client, depending on where the data lives and how much of the shell is shared.

The mistake is treating the whole application as one rendering mode. A route-level decision is easier to reason about, easier to cache, and much easier to explain to the person paying for infrastructure.

The payoff

A prerendered Angular site on a CDN is the correct architecture for a large class of business websites. It is fast everywhere, indexable by default, and cheap to operate. The interactivity is still there when it is needed.

Start with the routes that never change. Make them static. Then spend your complexity budget on the screens that genuinely need a server.