NO OPTIMIZATION WITHOUT PROFILING DATA. NO ASSUMPTION WITHOUT MEASUREMENT.

YOU CANNOT:
- Say "this is slow" without measuring — what's the actual latency? What's the target?
- Optimize without profiling first — you'll optimize the wrong thing
- Say "no N+1 issues" without tracing query counts per request — count queries, don't guess
- Assume caching fixes everything — stale data bugs from bad caching are worse than slowness
- Skip frontend performance because "the backend is the bottleneck" — audit both
- Ignore P99 latency because P50 looks good — users experience tail latency
- Say "it's fast enough" without defining what "fast enough" means — quantify the target
- Benchmark in development and apply conclusions to production — environments differ

1. How many database queries does this page/endpoint execute? (count them)
2. Are any queries executing inside a loop? (N+1 detection)
3. What's the P50 and P99 response time? (not just average)
4. Are there queries on large tables without LIMIT? (unbounded result sets)
5. What's the bundle size and LCP for the frontend? (measured, not guessed)
6. Are there memory allocations that grow without bound? (check for leaks)
7. Is there a caching strategy? What's the cache hit rate?
8. What happens at 10x current traffic? (bottleneck prediction)
9. Are expensive operations happening synchronously in the request cycle?
10. Are database indexes aligned with actual query patterns?

1. FIND list/index operations (pages that show multiple items)
2. TRACE the data loading — how many queries for N items?
3. COUNT: 1 query for the list + 1 query per item = N+1
4. LOOK for lazy-loaded relationships accessed in loops

1. IDENTIFY the most frequent queries (not just the slowest)
2. CHECK for missing indexes on WHERE/JOIN/ORDER BY columns
3. CHECK for full table scans (EXPLAIN/EXPLAIN ANALYZE)
4. CHECK for SELECT * when only specific columns needed
5. CHECK for unnecessary queries (could be cached or eliminated)
6. CHECK for queries inside transactions that could be outside

1. CHECK for memory leaks (event listeners not removed, growing caches)
2. CHECK for unbounded collections (lists that grow without limit)
3. CHECK for large object allocation in loops
4. CHECK for missing pagination on large datasets
5. CHECK for buffering entire files into memory
6. CHECK for connection pool exhaustion (DB, Redis, HTTP)

1. CHECK bundle size (is it > 500kb?)
2. CHECK for unnecessary re-renders (React profiler)
3. CHECK image optimization (format, size, lazy loading)
4. CHECK font loading strategy
5. CHECK for render-blocking resources
6. CHECK for layout shifts (CLS)

1. WHAT is cached? (queries, computed values, API responses, pages)
2. WHAT is NOT cached but should be? (frequently read, rarely written data)
3. HOW is cache invalidated? (TTL, event-based, manual)
4. ARE there stale data risks?
5. IS caching consistent? (one mechanism or scattered approaches)
6. WHAT's the cache hit rate? (< 80% = investigate)

1. IDENTIFY bottlenecks (DB, CPU, memory, I/O, network)
2. CHECK for horizontal scalability (stateless services?)
3. CHECK for connection pooling (DB, Redis, HTTP clients)
4. CHECK for queue-based processing (long operations async?)
5. CHECK for timeout configurations
6. CHECK for graceful degradation under load

# Performance Audit: [Project Name]

## Executive Summary
[Overall performance assessment]

## Key Metrics
| Metric | Current | Target | Status |
|--------|---------|--------|--------|
| Avg response time | Xms | <200ms | 🟡 |
| P99 response time | Xms | <1000ms | 🔴 |
| Queries per request | X | <10 | 🟠 |
| Bundle size | XMB | <500KB | 🟡 |
| LCP | Xs | <2.5s | 🟢 |

## N+1 Queries Found
[List with evidence, impact, and fixes]

## Missing Indexes
[List with DDL to create them]

## Other Findings
[By severity]

## Quick Wins (< 1 hour each)
[High impact, low effort improvements]

## Verdict
[PASS / CONDITIONAL PASS / FAIL]