What this prompt does
This prompt asks the model to act as a senior Angular performance engineer and audit your app, returning a prioritized action plan rather than generic advice. You set the [angular_version], the [app_scale], the [current_pain], and the [build_tool], and for each audit area it tells you what to check, how to measure it, the concrete fix, and the expected impact rated High, Med, or Low.
The structure works because it ranks fixes by impact so you address the 20% that moves the needle first. The audit covers change detection, rendering, routing and code-splitting, bundle analysis, assets, and Core Web Vitals, and it ends with a ranked table plus the single highest-ROI change to ship first. [current_pain] focuses the audit on your actual symptom, and [app_scale] calibrates which fixes are worth the effort. Forcing a what-to-check, how-to-measure, fix, and impact format for every area means you can confirm a problem exists before spending time on it, rather than acting on a hunch.
When to use it
- A page feels sluggish but you don't yet know where the time goes.
- You want a performance audit ranked by impact, not a generic checklist.
- You need fixes for change detection, bundle size, and lazy routes.
- You're chasing Core Web Vitals problems (LCP, INP, CLS) in an Angular app.
- You want each finding tied to a measurement method and a concrete fix.
- You want to know the single highest-ROI change to ship first.
- You want effort estimates alongside impact so you can plan the work.
Example output
Expect, per audit area, four things: what to check, how to measure it, the concrete fix, and an impact rating (High/Med/Low). It closes with a ranked table — Issue | Area | Impact | Effort | Fix — and then names the single highest-ROI change to ship first, with the reasoning. The areas span change detection, rendering, routing, bundle, assets, and Core Web Vitals, scoped to your [app_scale] and [current_pain]. Because each row pairs impact with effort, the table doubles as a backlog you can plan sprints around rather than a flat list of suggestions.
Pro tips
- Describe
[current_pain]precisely (e.g. slow initial load, laggy interactions on data-heavy pages) so the audit targets your real symptom. - Paste your component or route code under the prompt for sharper, code-specific results.
- Set
[app_scale]honestly (e.g. ~120 components, 30+ lazy routes) so the plan calibrates effort to your size. - Set
[build_tool]to what you use (e.g. Angular CLI with esbuild) so bundle-analysis advice matches your pipeline. - Use the impact ranking to fix the 20% that moves the needle first instead of chasing every finding.
- Match
[angular_version]to your major version so suggestions like signals or @defer apply.
