Google's Core Web Vitals turn "does this page feel fast?" into three numbers, and they matter twice: users feel them directly, and Google uses them as a page-experience signal in search. A single-page app has its own twists: routes change without a page load, the first render often waits on data, and one slow click handler can ruin a metric for the whole session. This lesson ties the rest of Module 8 together into a measurement-first workflow.

This is lesson 8.6 of the Angular Tutorial. It builds directly on OnPush (8.1–8.2), @for tracking (8.3), NgOptimizedImage (8.4) and bundle analysis (8.5). You'll learn what each metric measures, how to read lab versus field data, what's different in an SPA, and the Angular-specific fix for each metric.

The three metrics #

Google assesses each at the 75th percentile of real visits: a page passes if three out of four visits are "good". INP replaced First Input Delay (FID) as the responsiveness metric in March 2024, and it's much harder to pass, because it looks at every interaction, not just the first.

Lab data vs field data #

PageSpeed Insights shows both for a URL: field data at the top (if the page has enough traffic) and a Lighthouse run below. Use field data to decide what to fix and lab data to fix it. A green Lighthouse score with poor field INP is common in SPAs: Lighthouse only loads the page, while real users click around for minutes.

What's different in a single-page app #

• Route changes aren't page loads. LCP and the initial CLS are measured on the first load only. When the router swaps views, there's no new LCP, so a slow route transition doesn't show up there. Chrome is experimenting with measuring "soft navigations", but it isn't part of the official metrics yet.
• INP and CLS keep accumulating. INP reports roughly the worst interaction of the whole visit, and CLS keeps adding up across views, so a janky filter on page three or a banner that pushes content down after a route change counts against the URL the user first landed on.
• The first render often waits on data. If the hero needs an API response before anything meaningful appears, LCP includes that round trip.

Measure real users with web-vitals #

For field data on every route and interaction, add Google's small web-vitals library and send the numbers to your analytics:

// main.ts (after bootstrapApplication)
import { onCLS, onINP, onLCP } from 'web-vitals/attribution';

function report(metric: { name: string; value: number; rating: string; attribution?: unknown }) {
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    name: metric.name, value: metric.value, rating: metric.rating,
    path: location.pathname, attribution: metric.attribution,
  }));
}

onLCP(report);
onINP(report);
onCLS(report);

The attribution build tells you why: the LCP element, the slow interaction's target and its processing time, and which element shifted. Group results by path to find the routes that need work.

Fixing LCP in Angular #

1. Mark the LCP image priority with NgOptimizedImage and serve the right size (lesson 8.4). This is the most common fix.
2. Don't block the hero on data. Render the page shell and hero text immediately; load data-dependent sections with @defer or a resource() while the hero is already on screen.
3. Ship less JavaScript up front (lesson 8.5). The browser can't render a client-rendered page until main has downloaded and run.
4. Server-render or prerender content pages. For landing pages, articles and product pages, SSR or static prerendering puts the LCP element in the initial HTML. Module 9 covers this.
5. Speed up fonts: preconnect to the font host, and use font-display: swap so text renders immediately.

Fixing INP in Angular #

INP is about the time between a user action and the next frame. Anything that keeps the main thread busy in that window hurts:

• Keep change detection small. OnPush plus signals (lessons 8.1–8.2) means a click re-renders only what changed.
• Stop re-creating lists. A good track (lesson 8.3) turns "rebuild 500 rows" into "update 1 row".
• Virtualise long lists. For thousands of rows, the CDK's virtual scroll renders only what's visible.
• Do less in handlers, and do it later. Update the UI first, then do heavy work after the next paint:

async applyFilters() {
  this.loading.set(true);                         // paint "Filtering…" right away
  await new Promise(r => setTimeout(r));          // yield so the browser can paint
  this.results.set(filterLargeDataset(this.all(), this.filters()));   // heavy work after
  this.loading.set(false);
}

• Debounce high-frequency input. Filtering on every keystroke of a 10,000-item list is the classic INP killer; debounce the signal (lesson 3.4) or move the work to a Web Worker.
• Audit third-party scripts. Chat widgets and tag managers run on the same main thread; load them late or on interaction.

Fixing CLS in Angular #

• Give images dimensions, which NgOptimizedImage enforces (lesson 8.4).
• Size your @defer placeholders like the real content, so the swap doesn't push the page:

@defer (on viewport) {
  <app-reviews [productId]="id()" />
} @placeholder {
  <div class="reviews-skeleton" style="min-height: 420px"></div>
}

• Don't insert content above what the user is reading: cookie banners, "new version" notices and ads belong in reserved space or overlays.
• Animate with transform and opacity, not top, height or margin, which move layout.
• Match fallback fonts to web fonts with size-adjust so text doesn't reflow when the web font arrives.

A measurement-first workflow #

1. Check field data in PageSpeed Insights or your web-vitals reports; pick the worst metric on your highest-traffic route.
2. Reproduce in the lab: Lighthouse for LCP and CLS, DevTools' Performance panel (with CPU throttling) and the Angular DevTools profiler for INP.
3. Fix one thing, using the lists above.
4. Verify in the lab, deploy, then confirm in field data over the following weeks. CrUX is a 28-day rolling window, so improvements take time to show.

Gotchas #

What's next #

Lesson 8.7 is a practical memory-leak playbook: finding detached components and lingering subscriptions with heap snapshots, and the leak patterns that survive takeUntilDestroyed(). Then 8.8 pulls the whole module together into a checklist for avoiding unnecessary re-renders.

Try it yourself #

Run PageSpeed Insights on your app's busiest page and note which metric is worst in the field data. Add the web-vitals snippet above, logging to the console first, then click through the app and watch INP update on each interaction. Find the slowest interaction and apply one fix from the INP list.