Angular Performance Optimization Checklist — In the Right Order

Most Angular performance checklists are collections of possible optimizations. They tell you what can make an application slow but not which cause is worth investigating first.

I prefer a diagnostic order. Start with the causes that are fast to verify and frequently responsible, then move deeper only when the evidence requires it.

0. Reproduce Angular performance on realistic hardware

Before changing code, reproduce the complaint on hardware and network conditions that resemble the environment where users experience it.

A fast development laptop on a local connection can hide network waterfalls, main-thread pressure and rendering costs that become obvious on a mid-range device.

1. Check duplicate and serial Angular API requests

Open the network panel, reload the route and sort requests by name. Identical endpoints appearing several times during one navigation are often the cheapest performance problem to identify and remove.

Then inspect the waterfall. Requests that execute sequentially even though they do not depend on each other unnecessarily extend the route loading time.

2. Profile Angular change detection

Use Angular DevTools to profile the interaction that feels slow. Look for components being checked repeatedly during interactions unrelated to them.

rg -L  "ChangeDetectionStrategy.OnPush"  src  --type ts  -g "*.component.ts"  | wc -l

Do not automatically convert an entire application based on the count. A component becomes a performance concern when profiling shows that its checks are contributing to the interaction cost.

3. Analyze the Angular production bundle

The useful question is not only whether the bundle is large. Ask what is inside the initial bundle and whether the first route actually needs those dependencies.

ng build  --configuration production  --stats-json npx source-map-explorer  dist/**/*.js

Look for large libraries imported for small features, entire icon packages, charting libraries loaded before their route and lazy routes accidentally made eager through another import.

4. Inspect Angular rendering work

Once network, change detection and bundle cost have been investigated, inspect rendering. Large lists, expensive template expressions, unnecessary DOM nodes, missing identity tracking and layout instability can all increase interaction cost.

5. Prevent the Angular performance regression

A performance fix without a guard can disappear several releases later. Add the relevant protection after the cause is known: bundle budgets, automated performance checks, request-count expectations or field monitoring.

The guard should match the failure. A bundle budget will not protect against duplicate API calls, and a Lighthouse score alone will not explain a slow interaction inside a dense authenticated application.

Sometimes Angular is not the bottleneck

Profiling may show that the browser is mostly waiting for the backend. That is still a useful performance finding because it prevents a frontend team from spending weeks optimizing code that is not responsible for the delay.

The purpose of the checklist is not to perform every optimization. It is to eliminate possibilities in an order that reaches the actual bottleneck with the least wasted work.