Performance Profiling & Optimization Plan

## ROLE
You are a performance engineering specialist who has optimized applications from millisecond-critical trading systems to consumer web applications serving millions of users. You believe that premature optimization is the root of all evil, but measured, targeted optimization is engineering at its best. You use data, not intuition, to find bottlenecks.

## OBJECTIVE
Create a comprehensive performance profiling and optimization plan for [APPLICATION_NAME], a [APPLICATION_TYPE] application built with [TECH_STACK]. Current performance metrics show [CURRENT_METRICS], and the target is [TARGET_METRICS]. The optimization must be completed within [TIMELINE] with [TEAM_RESOURCES] available.

## TASK

### Step 1 — Performance Baseline & Budget
Establish the measurement foundation:
- **Core Web Vitals (if web):** Define target budgets for LCP (< [LCP_TARGET]ms), FID/INP (< [INP_TARGET]ms), CLS (< [CLS_TARGET]), and TTFB (< [TTFB_TARGET]ms). Measure current values across [DEVICE_PROFILES] device profiles.
- **API Performance:** For the top [TOP_N_ENDPOINTS] most-called API endpoints, measure and document: p50, p95, p99 latency, throughput (RPS), error rate, and payload size. Identify the slowest and most-called endpoints.
- **Database Performance:** Capture slow query logs for queries exceeding [SLOW_QUERY_THRESHOLD]ms. Measure connection pool utilization, query frequency distribution, and lock contention.
- **Resource Utilization:** Document CPU, memory, disk I/O, and network utilization under normal load, peak load, and stress conditions. Identify which resource saturates first.
- **User-Perceived Performance:** Define the critical user journeys ([CRITICAL_JOURNEYS]) and measure end-to-end completion time for each. This is what actually matters.

### Step 2 — Profiling Methodology
For each layer of the application, define the profiling approach:

**Frontend Profiling (if applicable):**
- **Bundle Analysis:** Run [BUNDLE_ANALYZER] to identify the largest modules. List the top 10 heaviest dependencies with their gzipped sizes. Identify unused code that ships to production.
- **Runtime Profiling:** Use browser DevTools Performance tab to capture flame charts for [CRITICAL_JOURNEYS]. Identify long tasks (>50ms), layout thrashing, forced synchronous layouts, and excessive re-renders.
- **Network Waterfall:** Analyze the resource loading waterfall. Identify render-blocking resources, unoptimized images, missing compression, and suboptimal caching headers.
- **Memory Profiling:** Take heap snapshots before and after key interactions. Identify memory leaks from detached DOM nodes, event listener accumulation, or growing closures.

**Backend Profiling:**
- **CPU Profiling:** Run [PROFILER_TOOL] under representative load. Identify hot functions consuming the most CPU time. Distinguish between application code and framework overhead.
- **I/O Profiling:** Identify blocking I/O operations — synchronous file reads, unparallelized external API calls, sequential database queries that could be batched.
- **Concurrency Analysis:** Measure thread/goroutine/process utilization. Are we CPU-bound, I/O-bound, or memory-bound? This determines the optimization strategy.
- **Garbage Collection:** Analyze GC pause times and frequency. Identify allocation-heavy code paths that pressure the garbage collector.

**Database Profiling:**
- **Query Plan Analysis:** Run EXPLAIN ANALYZE on the top [TOP_N_QUERIES] slowest queries. Identify sequential scans, missing indexes, and inefficient joins.
- **Index Usage:** Check pg_stat_user_indexes (or equivalent) for unused indexes (wasting write performance) and missing indexes (causing slow reads).
- **Connection Analysis:** Monitor active connections, idle connections, and wait times. Are queries queuing behind the connection pool?
- **Lock Analysis:** Identify queries causing lock contention. Are there long-running transactions blocking others?

### Step 3 — Optimization Priorities
Rank optimizations by impact and effort:

**Quick Wins (< 1 day each):**
- Enable compression (gzip/brotli) if not already active.
- Add missing database indexes identified in profiling.
- Configure HTTP caching headers for static assets.
- Remove unused dependencies from the bundle.
- Add connection pooling or increase pool size.

**Medium Effort (1-5 days each):**
- Implement code splitting and lazy loading for below-the-fold components.
- Rewrite the top 3 slowest database queries with optimized execution plans.
- Add a caching layer (Redis/Memcached) for the most frequently read, rarely changing data.
- Implement pagination for all list endpoints returning unbounded result sets.
- Convert sequential external API calls to parallel execution.

**Large Effort (1-4 weeks each):**
- Migrate from [CURRENT_ORM] to raw queries for the critical path if ORM overhead is significant.
- Implement a read replica strategy to offload read-heavy queries from the primary database.
- Add a CDN for static assets and API response caching at the edge.
- Redesign the data model for the most performance-critical feature to optimize for the actual access patterns.
- Implement background job processing for operations that do not need to be synchronous.

### Step 4 — Load Testing Plan
Validate optimizations under realistic conditions:
- **Tool Selection:** Use [LOAD_TEST_TOOL] for load testing. Configure realistic user scenarios based on production traffic patterns.
- **Test Scenarios:** Design tests for normal load ([NORMAL_LOAD]), peak load ([PEAK_LOAD]), and breaking point discovery. Include ramp-up and sustained load phases.
- **Success Criteria:** Define pass/fail criteria for each scenario based on latency percentiles, error rates, and throughput targets.
- **Regression Prevention:** Integrate performance tests into CI/CD. Define the performance budgets that block deployment if exceeded.

### Step 5 — Monitoring & Alerting
Ensure optimizations are sustained:
- **Performance Dashboards:** Define the key metrics for a real-time performance dashboard. Include both technical metrics (latency, throughput, errors) and business metrics (conversion rate, abandonment rate).
- **Alerting Rules:** Set up alerts for performance degradation — p99 latency exceeds [LATENCY_ALERT_THRESHOLD], error rate exceeds [ERROR_ALERT_THRESHOLD]%, or throughput drops below [THROUGHPUT_ALERT_THRESHOLD].
- **Performance Review Cadence:** Schedule weekly performance review of metrics trends. Monthly deep-dive profiling session to catch regressions early.

## OUTPUT FORMAT
Produce a performance optimization report with: current baseline measurements, profiling results with flame charts described, a prioritized optimization backlog with estimated effort and expected improvement for each item, a load testing plan, and a monitoring configuration.