What I see in audits

I’ve walked into teams where SSR ‘works’ but the dashboard jitters after first paint. Execs see a fast shell, then dead buttons for a second or two while hydration finishes. SSR without hydration metrics is lipstick on a pig. We’re going to measure it, budget it, and guard it.

• LCP improves after SSR, but hydration stalls on heavy dashboards

• Bundle creep from one-off charts/components bloats initial JS

• Cloud Functions cold starts spike TTFB during traffic bursts

2025 reality

As companies plan 2025 Angular roadmaps, you’ll be asked for SSR and Core Web Vitals improvements—without risking uptime. Firebase Hosting gives you global CDN, preview channels, and a simple path to Cloud Functions v2. Add Signals/SignalStore for predictable state and you’re in a strong position to ship quickly with proof.

• Q1 is hiring season; you need numbers, not vibes

• Firebase Hosting + Functions is a proven, low-ops path for Angular SSR

1) Scaffold SSR in Angular 20+

From your app workspace:

• Angular CLI integrates SSR and hydration out-of-the-box

• Works great in Nx monorepos

Commands

ng add @angular/ssr --project my-app

This adds server+browser builds, client hydration, and updates your angular.json. Validate with ng run my-app:serve-ssr.

2) Firebase Hosting with SSR rewrite

firebase.json:

• Static assets are cached aggressively; SSR goes through a function

firebase.json

{

"hosting": {

"public": "dist/my-app/browser",

"ignore": ["**/.*", "**/node_modules/**"],

"headers": [

  {

    "source": "**/*.@(js|css)",

    "headers": [{ "key": "Cache-Control", "value": "public,max-age=31536000,immutable" }]

  },

  {

    "source": "/index.html",

    "headers": [{ "key": "Cache-Control", "value": "no-cache" }]

  }

],

"rewrites": [ { "source": "**", "function": "ssr" } ]

}

}

3) Cloud Functions v2 SSR entry

functions/src/index.ts:

• Guardrails: region, memory, concurrency, minInstances, timeout

• Use Node 20 for compatibility and performance

functions/src/index.ts

import { onRequest } from "firebase-functions/v2/https";

import compression from "compression";

import express from "express";

import { join } from "node:path";

// Guardrails: tune per traffic shape

export const ssr = onRequest({

region: "us-central1",

memory: "512MiB",

concurrency: 50,

minInstances: 1,

maxInstances: 20,

timeoutSeconds: 30

}, async (req, res) => {

const app = express();

app.use(compression());

// Serve prebuilt browser assets if needed

const dist = join(process.cwd(), "dist/my-app/browser");

app.get('/assets/*', express.static(dist, { maxAge: '1y', etag: true }));

// Defer to Angular server bundle

const { renderPage } = await import("../ssr/main.server.mjs"); // output from ng build

const html = await renderPage(req.url);

res.setHeader('Cache-Control','public, s-maxage=60, stale-while-revalidate=300');

res.status(200).send(html);

});

4) Zero-downtime deploys with preview channels

.github/workflows/ci.yml (excerpt):

• Create ephemeral channels per PR, promote on approval

• Works great with Nx affected builds and GitHub Actions

GitHub Actions preview deploy

name: ci

on: [pull_request]

jobs:

build-and-preview:

runs-on: ubuntu-latest

steps:

  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4

    with: { node-version: 20 }

  - run: npm ci

  - run: npx nx run my-app:build:production

  - run: npx firebase-tools deploy --only hosting,functions --project ${{ secrets.FIREBASE_PROJECT }} --non-interactive

    env:

      FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

  - run: npx firebase-tools hosting:channel:deploy pr-${{ github.event.number }} --expires 7d --project ${{ secrets.FIREBASE_PROJECT }}

    env:

      FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

Why this matters

We’ll mark hydration start before bootstrap and end after the next render tick. Send a GA4 event so product can segment by route, device, and release channel.

• SSR without hydration timing hides UX gaps

• Report hydration_time alongside LCP/INP

main.ts (client)

import { bootstrapApplication } from '@angular/platform-browser';

import { afterNextRender } from '@angular/core';

import { AppComponent } from './app/app.component';

import { provideClientHydration } from '@angular/platform-browser';

performance.mark('hydration-start');

bootstrapApplication(AppComponent, {

providers: [provideClientHydration()]

}).then(() => {

afterNextRender(() => {

performance.mark('hydration-end');

performance.measure('hydration', 'hydration-start', 'hydration-end');

const [entry] = performance.getEntriesByName('hydration');

const ms = Math.round(entry.duration);

// GA4 event (or Firebase Analytics)

(window as any).gtag?.('event', 'hydration_time', {

  value: ms,

  event_category: 'performance',

  non_interaction: true

});

// Optional: Log to your endpoint for debugging

// fetch('/perf/hydration', { method:'POST', body: JSON.stringify({ ms, path: location.pathname }) });

});

});

Dashboard-specific notes

In my telecom analytics work, deferring chart libraries until after stable route hydration cut hydration_time by 25–40%. Signals+SignalStore also reduced wasted renders, which you’ll see in Angular DevTools flame charts.

• PrimeNG charts/tables: lazy-import heavy modules

• Signals/SignalStore: keep side effects out of constructors

angular.json budgets

• Start strict, loosen only with data

• Add component-style budget to catch CSS bloat

angular.json (excerpt)

"budgets": [

{ "type": "initial", "maximumWarning": "300kb", "maximumError": "350kb" },

{ "type": "anyComponentStyle", "maximumWarning": "6kb", "maximumError": "10kb" },

{ "type": "bundle", "name": "main", "maximumWarning": "240kb", "maximumError": "280kb" }

]

CI enforcement

• Angular CLI fails the build if budgets are exceeded

• Attach bundle reports as artifacts for review

Source map explorer (optional)

Inspect what grew

npx source-map-explorer dist/my-app/browser/*.js --html bundles.html

Configuration you should set day one

functions/package.json:

• Node 20 runtime, region close to users

• minInstances=1 (or >1 for steady traffic)

• timeoutSeconds <= 30 to catch runaway renders

• concurrency tuned to CPU/memory budget

functions/package.json

{

"name": "functions",

"type": "module",

"engines": { "node": "20" },

"dependencies": {

"firebase-functions": "^4.6.0",

"express": "^4.18.2",

"compression": "^1.7.4"

}

}

Cache strategy

Set Cache-Control headers in your function to let the CDN serve cached HTML while you revalidate. This made our airport kiosk portal resilient during intermittent outages—no blank screens when Wi‑Fi hiccuped.

• Static assets: immutable 1y

• SSR HTML: s-maxage=60, stale-while-revalidate=300

Bot pressure

Add light user-agent rate limits or a CDN rule to prevent crawl storms from melting the function. Keep a simple allowlist of query params that affect SSR so you don’t nuke caching with marketing UTMs.

• Rate-limit known scrapers

• Drop query strings that bust SSR cache

Observability

Emit SSR render time to Firebase Logs and trace deployments by channel. When a preview channel shows a spike in hydration_time or TTFB, you can halt promotion before customers feel it.

• Structured logs for TTFB, render ms, error rate

• GA4 dimension: channel (preview/prod)

Telecom ads analytics dashboard

We moved a prime dashboard to Firebase Hosting with Functions v2. Hydration_time dropped from ~780ms to ~520ms after lazy-loading D3/Highcharts views. CI budgets blocked a 60kb regression in a routine campaign feature.

• SSR + hydration metrics cut time-to-interaction by ~32%

• Budgets stopped chart library creep in CI

Airport kiosk portal

For a major airline, we paired SSR with aggressive CDN caching and Signals-backed device indicators for scanners/printers. The kiosk felt instant even when LTE flapped. Docker-based peripheral simulation let us test edge cases before rollout.

• Offline-tolerant SSR with stale-while-revalidate

• Docker hardware simulation kept device state reliable

Bring in help if

As a remote Angular consultant, I’m comfortable jumping into Nx monorepos, PrimeNG-heavy UIs, and Firebase stacks. If you need an Angular expert who can ship SSR with guardrails and board-ready metrics, let’s talk.

• Hydration jank persists after SSR

• Bundle budgets keep failing or aren’t set

• Cold starts / timeouts hurt TTFB under load

• You’re mid-upgrade (v12→20) and can’t freeze features

Do this next

SSR that’s measurable and guarded is what leadership expects in 2025. Pair it with Signals/SignalStore for stable state and you’ll have a dashboard that feels instant and stays that way as the codebase grows.

• Add hydration metrics now; verify in GA4 by route

• Set budgets and watch one PR fail (on purpose)

• Enable preview channels and protect main with promotion only