---
overlay: Performance Research
parent_agent: Super Researcher
description: "Performance analysis and optimization strategies"
---

## PERFORMANCE RESEARCH REFERENCE

These frameworks help structure performance research. Use what's relevant — a specific "why is X slow" question needs profiling guidance, while a "should we use X or Y" question needs benchmark methodology. Let the question guide your approach.

---

### BENCHMARK METHODOLOGY

When evaluating or comparing performance:
- **Warm-up:** Discard first N iterations (JIT, cache warming)
- **Sample size:** 100+ for micro, 10+ for integration
- **Percentiles:** Report p50, p95, p99 — not averages (averages hide tail latency)
- **Environment:** Note hardware, OS, runtime, load — results aren't portable without context
- **Comparison:** Same environment, same workload, same methodology, warm-up excluded

---

### PROFILING BY LAYER

When investigating performance issues, identify the bottleneck layer first:

| Layer | Tools | Key Metrics |
|-------|-------|-------------|
| Frontend | Lighthouse, DevTools | FCP, LCP, CLS, TTI, bundle size |
| Network | DevTools Network, curl -w | TTFB, transfer size, connections |
| Backend | Profiler, APM | Response time, CPU, memory |
| Database | EXPLAIN ANALYZE, slow query log | Query time, index usage, locks |
| Infrastructure | top, iostat, docker stats | CPU%, memory%, disk I/O |

**Rule of thumb:** Identify WHICH layer is the bottleneck before recommending optimizations.

---

### CORE WEB VITALS (Reference)

| Metric | Good | Poor | Measures |
|--------|------|------|----------|
| LCP | <2.5s | >4.0s | Largest content rendered |
| INP | <200ms | >500ms | Interaction responsiveness |
| CLS | <0.1 | >0.25 | Visual stability |

Lab tools: Lighthouse, WebPageTest. Field tools: CrUX, RUM.

---

### OPTIMIZATION HIERARCHY

When recommending optimizations, higher levels yield bigger gains:

```
1. ALGORITHM (Big-O)     — up to 1000x (right data structure? unnecessary work?)
2. ARCHITECTURE           — up to 100x  (caching, async, connection pooling)
3. IMPLEMENTATION         — up to 10x   (batching, streaming, pagination)
4. MICRO-OPTIMIZATION     — up to 2x    (object pooling, SIMD, JIT hints)
```

A better algorithm always beats a micro-optimized bad algorithm.

---

### DATABASE PERFORMANCE PATTERNS (Reference)

| Problem | Diagnosis | Solution |
|---------|-----------|----------|
| Slow queries | EXPLAIN ANALYZE | Add indexes, rewrite, denormalize |
| N+1 queries | Count queries/request | Eager loading, batch, DataLoader |
| Lock contention | pg_stat_activity | Optimize transactions, reduce scope |
| Connection exhaustion | Pool metrics | Pool sizing, timeouts |