Audit Performance
Overview
Generate a performance budget audit against Core Web Vitals (LCP, INP, CLS), bundle size, and API latency. Defines thresholds, identifies violations, and provides actionable recommendations for image optimization, code splitting, lazy loading, and caching improvements.
Workflow
Read engineering context -- Scan .chalk/docs/engineering/ for architecture docs, existing performance budgets, and infrastructure configuration. Check the codebase for build configuration (webpack, vite, next.config) and existing performance tooling.
Parse the audit target -- Extract from $ARGUMENTS the page, feature, or endpoint to audit. If unspecified, audit the most critical user-facing page (typically the landing page or main dashboard).
Determine the next file number -- Read filenames in .chalk/docs/engineering/ to find the highest numbered file. The next number is highest + 1.
Define performance budgets -- Set thresholds (use existing budgets from docs if available, otherwise use industry standards):
| Metric |
Good |
Needs Improvement |
Poor |
| LCP |
< 2.5s |
2.5-4.0s |
> 4.0s |
| INP |
< 200ms |
200-500ms |
> 500ms |
| CLS |
< 0.1 |
0.1-0.25 |
> 0.25 |
| Bundle size (JS) |
< 200KB gzipped |
200-350KB |
> 350KB |
| API latency (p95) |
< 300ms |
300-1000ms |
> 1000ms |
Analyze the codebase for performance issues -- Review:
- Bundle: large dependencies, tree-shaking gaps, missing code splitting
- Images: unoptimized formats, missing lazy loading, no responsive sizes
- Rendering: layout shifts from dynamic content, render-blocking resources
- Data fetching: waterfall requests, missing caching, over-fetching
- API: slow queries, missing indexes, N+1 problems
Report violations -- For each budget exceeded or at risk, document: current value (if measurable from code analysis), threshold, root cause, and recommended fix.
Prioritize recommendations -- Rank fixes by impact (how much improvement) and effort (how hard to implement). Quick wins first.
Write the file -- Save to .chalk/docs/engineering/<n>_performance_audit.md.
Confirm -- Share the file path and highlight the top 3 highest-impact fixes.
Output
- File:
.chalk/docs/engineering/<n>_performance_audit.md
- Format: Plain markdown with budget table, violations list, and prioritized recommendations
- First line:
# Performance Audit: <Target>
Anti-patterns
- Auditing without budgets -- "The page is slow" is not actionable. Define thresholds first, then measure against them. Without budgets, there is no pass/fail.
- Only measuring lab data -- Lab metrics (Lighthouse) and field metrics (CrUX) can differ significantly. Note which measurements are lab-based and recommend field monitoring.
- Recommendations without priority -- A list of 20 optimizations without ranking overwhelms teams. Prioritize by impact-to-effort ratio and present quick wins first.
- Ignoring bundle composition -- "Bundle is too large" without identifying which dependencies contribute most is not helpful. Break down the bundle and identify the largest contributors.
- Missing API latency -- Frontend performance audits that ignore API response times miss half the picture. Include backend latency in the audit scope.
1---2name: audit-performance-33description: Audit performance against Core Web Vitals and performance budgets when the user asks to check performance, audit speed, or analyze web vitals4---5
6# Audit Performance
7
8## Overview
9
10Generate a performance budget audit against Core Web Vitals (LCP, INP, CLS), bundle size, and API latency. Defines thresholds, identifies violations, and provides actionable recommendations for image optimization, code splitting, lazy loading, and caching improvements.
11
12## Workflow
13
141. **Read engineering context** -- Scan `.chalk/docs/engineering/` for architecture docs, existing performance budgets, and infrastructure configuration. Check the codebase for build configuration (webpack, vite, next.config) and existing performance tooling.
15
162. **Parse the audit target** -- Extract from `$ARGUMENTS` the page, feature, or endpoint to audit. If unspecified, audit the most critical user-facing page (typically the landing page or main dashboard).
17
183. **Determine the next file number** -- Read filenames in `.chalk/docs/engineering/` to find the highest numbered file. The next number is `highest + 1`.
19
204. **Define performance budgets** -- Set thresholds (use existing budgets from docs if available, otherwise use industry standards):
21
22 | Metric | Good | Needs Improvement | Poor |
23 |--------|------|-------------------|------|
24 | LCP | < 2.5s | 2.5-4.0s | > 4.0s |
25 | INP | < 200ms | 200-500ms | > 500ms |
26 | CLS | < 0.1 | 0.1-0.25 | > 0.25 |
27 | Bundle size (JS) | < 200KB gzipped | 200-350KB | > 350KB |
28 | API latency (p95) | < 300ms | 300-1000ms | > 1000ms |
29
305. **Analyze the codebase for performance issues** -- Review:
31 - Bundle: large dependencies, tree-shaking gaps, missing code splitting
32 - Images: unoptimized formats, missing lazy loading, no responsive sizes
33 - Rendering: layout shifts from dynamic content, render-blocking resources
34 - Data fetching: waterfall requests, missing caching, over-fetching
35 - API: slow queries, missing indexes, N+1 problems
36
376. **Report violations** -- For each budget exceeded or at risk, document: current value (if measurable from code analysis), threshold, root cause, and recommended fix.
38
397. **Prioritize recommendations** -- Rank fixes by impact (how much improvement) and effort (how hard to implement). Quick wins first.
40
418. **Write the file** -- Save to `.chalk/docs/engineering/<n>_performance_audit.md`.
42
439. **Confirm** -- Share the file path and highlight the top 3 highest-impact fixes.
44
45## Output
46
47- **File**: `.chalk/docs/engineering/<n>_performance_audit.md`
48- **Format**: Plain markdown with budget table, violations list, and prioritized recommendations
49- **First line**: `# Performance Audit: <Target>`
50
51## Anti-patterns
52
53- **Auditing without budgets** -- "The page is slow" is not actionable. Define thresholds first, then measure against them. Without budgets, there is no pass/fail.
54- **Only measuring lab data** -- Lab metrics (Lighthouse) and field metrics (CrUX) can differ significantly. Note which measurements are lab-based and recommend field monitoring.
55- **Recommendations without priority** -- A list of 20 optimizations without ranking overwhelms teams. Prioritize by impact-to-effort ratio and present quick wins first.
56- **Ignoring bundle composition** -- "Bundle is too large" without identifying which dependencies contribute most is not helpful. Break down the bundle and identify the largest contributors.
57- **Missing API latency** -- Frontend performance audits that ignore API response times miss half the picture. Include backend latency in the audit scope.
majiayu000