perf-audit
Performance Audit
Workflow
-
Detect build tool from
package.json(vite, webpack, next, rollup) -
Run production build if no recent build exists:
- Vite:
npm run build - Next.js:
npm run build(reads.next/analyze/ifANALYZE=true)
- Vite:
-
Analyze bundle output:
Vite:
npx vite-bundle-visualizerwebpack/Next.js:
npx webpack-bundle-analyzer <stats-file> -
Check
package.jsonfor known heavy packages (see table below) -
Report findings with size impact
Budget Thresholds
| Asset | Good | Warning | Critical |
|---|---|---|---|
| Initial JS (gzip) | < 150 KB | 150-300 KB | > 300 KB |
| Initial CSS (gzip) | < 20 KB | 20-50 KB | > 50 KB |
| Individual chunk | < 50 KB | 50-100 KB | > 100 KB |
| Total page weight | < 500 KB | 500 KB-1 MB | > 1 MB |
Heavy Packages
| Package | Size | Alternative | Savings |
|---|---|---|---|
moment |
~230 KB | date-fns / dayjs |
~200 KB |
lodash (full) |
~70 KB | lodash/merge or native |
~60 KB |
@mui/material (full) |
~300 KB | Named imports | ~150 KB |
react-icons (all) |
variable | Import only used icon packs | varies |
axios |
~15 KB | ky or native fetch |
~10 KB |
Lighthouse Scores
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| Performance | >= 90 | 50-89 | < 50 |
| FCP | < 1.8s | 1.8-3s | > 3s |
| LCP | < 2.5s | 2.5-4s | > 4s |
| TBT | < 200ms | 200-600ms | > 600ms |
| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
Output format
- Bundle summary: total size / gzipped size vs budget
- Large chunks: name + size + % of total
- Heavy deps: package + size + lighter alternative
- Quick wins: sorted by estimated savings
Rules
- Compare against budget thresholds above
- Report gzipped sizes (what the browser downloads)
- Never auto-change dependencies -- report and suggest only
Error Handling
- Build fails -- report the error and stop; fix build issues before auditing
- No build output found -- run production build first
- Build tool unrecognized -- fall back to scanning
package.jsonfor heavy packages only
More from helderberto/skills
ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
46explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
45safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40