Skip to content

Lesson 11 — Performance and rendering evidence

Objective

Measure a slow interaction, improve its actual cause, and defend the complexity/latency tradeoff with comparable evidence.

Prerequisites

Rendering identity, signals, route loading, testing, and browser development tools.

Mental model

Performance has separate startup, rendering, interaction, memory, and network budgets. OnPush and signals can reduce checking but cannot fix expensive computation, huge DOM, layout thrashing, or waterfalls.

Why it exists

Users experience latency and instability, not framework slogans. Measurement identifies the constrained budget and prevents speculative complexity.

Working model: fewer checks and lazy code make Angular faster.

Engineering reality: moving work can improve one metric while worsening another. Development timings, synthetic data, and one machine are evidence with limits—not production truth.

Minimal example

Record metric, environment, data size, interaction, repeated samples, variability, before value, after value, and the code change. Without that record, “faster” is not defensible.

Real-world usage

Large lists, startup bundles, optional panels, change detection, SSR/hydration, and low-end devices require different interventions and monitoring.

Common mistakes

  • optimizing before reproducing a bottleneck;
  • tracking rows by index;
  • invoking expensive functions per row/template check;
  • reporting development-build timings as production evidence;
  • deferring work without accounting for later latency/layout shift;
  • treating lab measurements as real-user monitoring.

Mini lab

Task: Profile startup and filtering; generate 2,000 topics; compare stable/index tracking; move repeated derivation to computed; inspect lazy chunks; defer a noncritical panel; set build budgets; evaluate virtualization.

Constraints: same machine/data/interaction for before and after; production build for bundle evidence; optimize only the observed bottleneck.

Expected result: one measured budget improves, side effects are reported, and the recommendation includes conditions that would reverse it.

Hint 1

Separate CPU, DOM size, network, memory, and layout evidence before choosing a tool.

Hint 2

A function that sorts the entire list from every row template multiplies work and allocations.

Solution direction — last resort

Preserve view identity, derive expensive results by source/filter dependencies, split or defer only noncritical code, and virtualize when DOM volume is the constraint.

Verification

Add a full-list sort called by every row, record invocation/allocation evidence, then replace it with derivation. Report before/after numbers, method, and variability.

Mastery evidence: reproduce, measure, improve, and explain a bottleneck without attributing causality from intuition alone.

Bloom challenge

  1. Understand: distinct performance budgets.
  2. Apply: capture a comparable profile.
  3. Analyze: identify the dominant cost.
  4. Evaluate: lazy loading, preloading, deferral, or virtualization.
  5. Create: define low-end-device budgets and CI/RUM evidence.

Summary

Performance engineering is a measurement and tradeoff discipline; Angular APIs are tools, not outcomes.

Spaced review

Repeat Lesson 2's identity bug under load and Lesson 1's lazy-route claim with bundle evidence.

What comes next

Continue to architecture and production readiness.