performance-audit
Performance Audit Framework
Initial Assessment Questions
- What's slow? - Page load, API response, build time, runtime
- How slow? - Quantify: 3s vs 30s matters
- Baseline? - What's acceptable performance?
- When? - Always slow, or under certain conditions?
- Where? - Client, server, network, database?
Measurement First
NEVER optimize without measuring. Identify bottlenecks before fixing.
Web Performance Metrics
- LCP (Largest Contentful Paint) - Main content visible
- FID (First Input Delay) - Interactivity
- CLS (Cumulative Layout Shift) - Visual stability
- TTFB (Time to First Byte) - Server response
Tools
- Chrome DevTools Performance tab
- Lighthouse audit
- WebPageTest.org
- React DevTools Profiler
console.time()/console.timeEnd()
Common Performance Issues
Frontend
| Issue | Detection | Fix |
|---|---|---|
| Large bundle | Webpack analyzer | Code splitting, tree shaking |
| Render blocking | Network waterfall | Defer/async scripts, critical CSS |
| Excessive re-renders | React Profiler | useMemo, useCallback, React.memo |
| Memory leak | Memory timeline | Cleanup effects, remove listeners |
| Layout thrashing | Performance timeline | Batch DOM reads/writes |
Backend/API
| Issue | Detection | Fix |
|---|---|---|
| N+1 queries | Query logs | Eager loading, batching |
| Missing indexes | EXPLAIN plans | Add appropriate indexes |
| No caching | Repeated queries | Redis, in-memory cache |
| Sync blocking | Flame graphs | Async/await, worker threads |
| Large payloads | Network tab | Pagination, field selection |
Database
| Issue | Detection | Fix |
|---|---|---|
| Full table scan | EXPLAIN | Add index on filter columns |
| Too many indexes | Write latency | Remove unused indexes |
| Large result sets | Memory usage | Pagination, streaming |
| Lock contention | Deadlock logs | Optimize transactions |
Quick Wins Checklist
Frontend:
- Enable gzip/brotli compression
- Set cache headers
- Lazy load images and routes
- Use production builds
- Minimize third-party scripts
Backend:
- Add database indexes for common queries
- Implement response caching
- Use connection pooling
- Enable query result caching
- Optimize N+1 queries
Performance Budget
Set limits and enforce:
- Bundle size: < 200KB (gzipped)
- API response: < 200ms (p95)
- Page load: < 3s (LCP)
- Build time: < 60s
Output Format
When reporting:
- Current State - Measured performance with numbers
- Bottlenecks - Identified issues ranked by impact
- Recommendations - Specific fixes with expected improvement
- Priority - Quick wins vs larger refactors
More from jamelna-apps/claude-dash
cost-tracking
When user mentions "spending", "usage", "tokens", "API cost", "budget", "expensive", or wants to understand Claude API costs. Provides cost awareness and optimization guidance.
11page-cro
When the user mentions "conversion", "CRO", "landing page", "not converting", "bounce rate", "optimize page", or asks about improving page performance.
7session-handoff
When user says "continue", "pick up where we left off", "last time", "previous session", "what were we doing", or wants explicit session continuity. Provides structured context handoff between sessions.
4error-diagnosis
When user encounters "error", "exception", "failed", "stack trace", "crashed", or needs error categorization. Provides structured root cause analysis and prevention strategies.
4code-review
When the user mentions "review", "PR", "pull request", "code review", "check my code", "feedback on", or asks for code quality assessment.
3smart-routing
When deciding which Claude model (Opus/Sonnet/Haiku) to use, or when "route", "which model", "complex task", "multi-file", "architectural", or "deep debugging" is mentioned. Guides quality-first model selection.
3