4 min read • Guide 380 of 877
How to Track Performance Optimization Work?
How to track performance optimization work?
Track performance work by creating tasks with measurable targets (e.g., "Reduce page load from 4s to 2s"), documenting baseline metrics in task descriptions, labeling by performance type (perf:frontend, perf:database), and requiring before/after measurements for done. Use NoteVault to maintain performance benchmarks and optimization history.
Performance labels
| Label | Purpose |
|---|---|
| perf:frontend | Frontend/client performance |
| perf:api | API response times |
| perf:database | Database query optimization |
| perf:memory | Memory usage issues |
| perf:bundle | JavaScript bundle size |
| perf:images | Image optimization |
| perf:caching | Caching improvements |
| perf:p1 | Critical performance issue |
Performance task template
## Perf: [Component] - [Optimization Goal]
Category: [Frontend/API/Database/Memory]
Priority: [P1/P2/P3]
Baseline metrics:
- Current: 4.2s page load (P95)
- Target: Under 2.0s (P95)
- Measurement: Lighthouse + RUM data
Impact:
- Pages affected: Dashboard, Reports
- Users affected: All users
- Business impact: 32% bounce rate
Root cause:
[Investigation findings]
Proposed optimization:
1. [Specific change 1]
2. [Specific change 2]
3. [Specific change 3]
Verification:
- [ ] Local profiling shows improvement
- [ ] Staging metrics improved
- [ ] Production metrics improved
- [ ] No regressions in other areas
Definition of Done:
- [ ] Before/after metrics documented
- [ ] P95 under 2.0s for 7 days
- [ ] No memory leaks introduced
Performance optimization workflow:
- Identify issue - User reports, monitoring alerts
- Profile and measure - Establish baseline
- Create task - Use template with metrics
- Investigate root cause - Profiling, analysis
- Propose solution - Document approach
- Implement fix - Development work
- Measure improvement - Verify locally
- Deploy to staging - Test in production-like env
- Monitor production - Verify real-world improvement
- Document results - Before/after in NoteVault
Performance metrics by type
| Type | Key Metrics |
|---|---|
| Frontend | LCP, FID, CLS, TTI, bundle size |
| API | Response time P50/P95/P99, throughput |
| Database | Query time, connection pool usage |
| Memory | Heap size, GC frequency, leaks |
| Infrastructure | CPU, memory, I/O utilization |
NoteVault performance documentation
# Performance Benchmarks
## Current Targets (2025)
| Metric | Target | Current |
|--------|--------|---------|
| Dashboard LCP | < 2.0s | 2.3s |
| API P95 | < 200ms | 180ms |
| Bundle size | < 250KB | 312KB |
## Optimization History
### 2025-01-20: Dashboard Load Optimization
- Before: 4.2s LCP
- After: 2.3s LCP
- Changes: Code splitting, lazy loading
- Impact: 45% improvement
### 2025-01-10: Database Query Optimization
- Before: 850ms avg query
- After: 120ms avg query
- Changes: Added indexes, query rewrite
- Impact: 86% improvement
Performance task prioritization
| Priority | Criteria | Example |
|---|---|---|
| P1 | Unacceptable, critical path | Checkout takes 10s |
| P2 | Suboptimal, high-traffic | Dashboard slow |
| P3 | Nice-to-have | Settings page |