What this prompt does
This prompt runs a structured performance optimization playbook over an Angular [angular_version] app that has known [current_issues], aiming at concrete [performance_targets]. It works through change detection, lazy loading, @defer blocks, virtual scrolling, bundle reduction, image optimization, trackBy, Web Workers, SSR, and a runtime profiling workflow — and asks for before/after metrics on each step so the work is accountable.
It works because it attacks the usual sources of Angular slowness in order and ties each fix to your numbers. Migrating [cd_candidates] to OnPush cuts needless change-detection runs, splitting [module_count] routes into lazy chunks shrinks the initial load, and virtual scrolling keeps [list_component] smooth at [item_count]+ rows. Offloading [cpu_tasks] to a Web Worker stops heavy computation from blocking the main thread. Framing the work around moving from [current_bundle] to [target_bundle] and hitting [performance_targets] makes the output measurable rather than a list of generic tips.
When to use it
- An Angular app feels slow and you need a prioritised plan, not scattered advice
- Initial load is heavy and you want to lazy-load
[module_count]routes with a preloading strategy - Data tables or lists janky at scale and
[list_component]needs virtual scrolling - Bundle size has crept up and you need to get from
[current_bundle]toward[target_bundle] - Migrating components to OnPush change detection across the app
- Justifying optimization work to stakeholders with before/after
[performance_targets]numbers
Example output
You get an ordered optimization plan: which [cd_candidates] to move to OnPush, a lazy-loading split for [module_count] routes with a preloading strategy, @defer block placement for below-the-fold content, virtual scrolling config for [list_component], a bundle-analysis and tree-shaking pass targeting [target_bundle], NgOptimizedImage usage, trackBy functions for every loop, Web Worker offloading for [cpu_tasks], SSR setup for [ssr_pages], and a DevTools/Chrome profiling workflow — each step paired with before/after metric placeholders.
Pro tips
- State
[current_issues]with real symptoms (4s load, janky table scroll, 2.5MB bundle) so the playbook targets your actual bottlenecks - Set
[performance_targets]as measurable thresholds (LCP, INP, bundle size) because they decide which steps matter most - Pick
[cd_candidates]carefully; OnPush helps most on frequently-rendered components like table rows and cards - Match
[item_count]to your real data — virtual scrolling pays off at thousands of rows, less so at a few dozen - Add trackBy to every *ngFor or @for loop over dynamic data, since rebuilding DOM nodes needlessly is a quiet cause of jank
- Reach for @defer blocks on below-the-fold or conditionally rendered content, so heavy components load only when they're actually needed
- Treat the before/after metrics as required, not optional; measure with Angular DevTools and the Chrome Performance tab rather than guessing
- Only enable SSR for
[ssr_pages]that benefit (landing, blog, docs); rendering an authenticated dashboard server-side adds complexity for little gain
