How can I diagnose performance issues in an Angular application using measurements?

Diagnosing performance bottlenecks in an Angular application relies on collecting quantitative data before and after changes. The following procedure assumes you have access to Chrome DevTools, the Angular DevTools extension, webpack‑bundle‑analyzer (or source‑map‑explorer), and Lighthouse. Adjust tool versions to match your project’s Node and Angular CLI versions.

1. Establish a baseline. Run the app in production mode (ng build --configuration production) and serve it locally. Record:
   • Bundle size (using webpack-bundle-analyzer or source-map-explorer).
   • Time to First Paint (TTFP) and Largest Contentful Paint (LCP) from Lighthouse.
   • Average change detection cycle duration (enable Angular DevTools > Profiler, interact with the app, note the mean time per cycle).
   Verify that the measurements are taken with a clean cache and no throttling unless you deliberately want to simulate slower networks.
2. Profile change detection. Open Angular DevTools, switch to the Profiler tab, and record a typical user interaction (e.g., clicking a button that updates a list). Look for components that appear frequently in the flamegraph. If many components re‑render despite unchanged inputs, consider adding OnPush change detection or memoizing inputs.
3. Analyze rendering time. In Chrome DevTools Performance tab, record a session while scrolling or animating. Examine the “Main” section for long tasks (>50 ms) and note whether they originate from Angular’s zone.js callbacks or from heavy template expressions. Replace expensive template calls with pure pipes or move calculations to component properties.
4. Inspect bundle composition. Run the bundle analyzer and sort by size. Identify large third‑party libraries that may be imported wholly when only a subset is needed. Consider lazy‑loading modules, using dynamic imports, or replacing heavy libraries with lighter alternatives.
5. Apply a hypothesised fix. Implement one change at a time (e.g., add OnPush to a component, split a lazy route, or replace a large library).
6. Re‑measure. Repeat steps 1‑4 after each change. Compare the new metrics to the baseline. An improvement is considered successful if TTFP/LCP drops by ≥10 % and change detection cycle time decreases without regressing functionality.
7. Rollback if needed. If a change does not yield measurable improvement or introduces bugs, revert the commit or feature flag and return to the baseline before trying another hypothesis.

Throughout the process, keep a simple spreadsheet or markdown log of each experiment, the tools used, the raw numbers, and the conclusion. This log aids reproducibility and helps communicate findings to the team.