Server-side rendering moves work from your users' devices to your servers, and that work happens on every request unless something stops it. A server-rendered page that takes 300 ms to produce is fine at ten requests a second and a problem at a thousand. The fix is rarely a faster renderer. It's making sure most requests never reach the renderer at all, and that the ones that do are served from somewhere close to the user with the data they need nearby.

This is lesson 9.7 of the Angular Tutorial, and the last lesson of Module 9. Lesson 9.6 removed repeated data fetches between server and browser; this lesson looks at the infrastructure around the renderer. You'll learn how to cache rendered pages and assets with Cache-Control, how to keep personalised content out of shared caches, how to run Angular on edge runtimes with AngularAppEngine, the trade-offs of Node and serverless hosting, and a set of tactics for a lower time to first byte.

Where a response can come from #

Every request served by an upper layer is one your renderer doesn't handle. A good SSR deployment pushes as much traffic as possible to the top three rows and reserves the bottom row for content that is genuinely request-specific or changing.

Cache-Control in one table #

Cache-Control is the response header that tells browsers and CDNs what they may store and for how long. The directives you'll use most:

A useful pattern for server-rendered public pages is a short browser lifetime and a longer CDN lifetime: public, max-age=0, s-maxage=300, stale-while-revalidate=60. Browsers always check back, the CDN answers for five minutes, and after that users still get a fast stale response while the CDN refreshes it.

Setting cache headers #

Static assets #

The application builder gives JavaScript and CSS files content hashes in their names, so a changed file always has a new URL. Those files can be cached for a year. The CLI's generated server.ts already serves the browser folder with a long maxAge:

app.use(express.static(browserDistFolder, { maxAge: '1y', index: false, redirect: false }));

If a CDN or static host serves your assets instead, configure the same rule there: Cache-Control: public, max-age=31536000, immutable for hashed files. HTML, including the client-side index.html, should not get that rule, because its URL never changes between deploys.

Rendered and prerendered pages #

For per-route defaults, the headers field on server routes is the simplest place:

// app.routes.server.ts
import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  {
    path: 'docs/**',
    renderMode: RenderMode.Prerender,
    headers: { 'Cache-Control': 'public, max-age=0, s-maxage=86400' },
  },
  {
    path: 'products/:id',
    renderMode: RenderMode.Server,
    headers: { 'Cache-Control': 'public, max-age=0, s-maxage=300, stale-while-revalidate=60' },
  },
  {
    path: 'account/**',
    renderMode: RenderMode.Client,
  },
  {
    path: '**',
    renderMode: RenderMode.Server,
    headers: { 'Cache-Control': 'public, max-age=0, s-maxage=60' },
  },
];

When the decision depends on the request rather than the route, for example "never cache publicly if the user is signed in", handle it in server.ts, where you can inspect the request and adjust the web Response before writing it:

app.use((req, res, next) => {
  angularApp
    .handle(req)
    .then((response) => {
      if (!response) return next();
      if (req.headers.cookie?.includes('session=')) {
        response.headers.set('Cache-Control', 'private, no-store');
      }
      writeResponseToNodeResponse(response, res);
    })
    .catch(next);
});

Keeping personal data out of shared caches #

A CDN-cached page is served to everyone who requests that URL. If the server rendered the signed-in user's greeting into it, every visitor sees that user's name, and the transfer state (lesson 9.6) may contain their data too. The safest architecture separates the two:

For the user-specific bits, render a neutral placeholder on the server and load the real data in the browser, for example in a regular @defer block, which renders its @placeholder on the server and fetches its content only in the browser. Vary: Cookie looks like a shortcut, but it effectively gives every user their own cache entry, so the CDN hit rate collapses.

Running on the edge with AngularAppEngine #

The Node-specific AngularNodeAppEngine from lesson 9.2 has a runtime-neutral sibling, AngularAppEngine, that works with standard web Request and Response objects. That's the shape edge and serverless platforms expect:

// server.ts for a fetch-style runtime
import { AngularAppEngine, createRequestHandler } from '@angular/ssr';

const angularApp = new AngularAppEngine();   // once per isolate, not per request

export const reqHandler = createRequestHandler(async (request: Request) => {
  const response = await angularApp.handle(request);
  return response ?? new Response('Not found', { status: 404 });
});

handle() serves prerendered pages, renders server routes and returns client-rendered pages based on your server routes, just as on Node. Hosting providers wrap reqHandler in their own entry point; check your provider's Angular adapter for the exact wiring.

The last row decides most edge deployments. Rendering at the edge saves network distance between the user and the renderer, but if the page makes three sequential API calls back to a database in one region, each call pays that distance instead. Edge rendering wins when the page's data is cached at the edge too, or when it needs little data. Otherwise, a Node server in the same region as your API, with a CDN in front, is often faster.

The allowed-hosts check from lesson 9.2 applies to both engines: pass allowedHosts to the constructor or configure security.allowedHosts in angular.json with your production domains.

Node hosting and cold starts #

On Node, you have two shapes:

• Long-running server (container, VM, platform service): node dist/my-app/server/server.mjs. Startup cost is paid once. Scale with more instances behind a load balancer.
• Serverless functions: the platform imports reqHandler and invokes it per request. Idle instances are shut down, so the first request after a quiet period pays a cold start: loading the runtime, the server bundle and the route manifest before rendering begins.

To keep cold starts short:

Tactics for a lower TTFB #

Time to first byte for a server-rendered page is roughly network time plus render time, and render time is mostly waiting for data. In order of impact:

1. Don't render what you can cache. Prerender static routes; put s-maxage on public SSR routes.
2. Remove data waterfalls. Resolvers or components that call API B only after API A returns double the wait. Fetch independent data in parallel, or have one endpoint return what the page needs.
3. Don't wait for non-critical data on the server. Content inside a regular @defer block isn't rendered on the server, so its data isn't fetched there. Use that for below-the-fold, user-specific or slow sections. (Blocks with hydrate triggers, from lesson 9.5, are rendered on the server, so their data counts toward TTFB.)
4. Put the renderer near the data, or the data near the renderer, as discussed above.
5. Compress responses. Enable Brotli or gzip at the CDN or with compression middleware; server-rendered HTML with inlined transfer state compresses well.
6. Keep the CDN from changing the HTML. Minification or comment stripping breaks hydration (NG0507, lesson 9.3). Compression is safe; rewriting is not.

Measure TTFB from real users, not just from your machine, using the field-data approach from lesson 8.6, and check your CDN's cache hit ratio for HTML. A low hit ratio usually means a private header, a Set-Cookie on every response or a Vary header is preventing caching.

Gotchas #

What's next #

That completes Module 9. You can now choose a render mode per route, bootstrap and debug the server application, hydrate cleanly, keep early interactions, hydrate incrementally, avoid double data fetches and deploy with caching that keeps the renderer's load under control. Module 10 turns to debugging real-world problems, starting with lesson 10.1: a catalogue of the NG0xxx runtime errors you're most likely to meet, what each one means and how to fix it.

Try it yourself #

Run curl -I against three pages of your production site: a static page, a public dynamic page and a signed-in page. Write down the Cache-Control, Vary and Set-Cookie headers for each and compare them with the tables above. Fix the one that's most wrong, then check your CDN's cache hit ratio for HTML a day later.