performance-testinglisted

# Performance Testing ## Frontend performance (Core Web Vitals) Use Chrome DevTools MCP `performance_start_trace` / `performance_analyze_insight` or `lighthouse_audit`, or Claude in Chrome, to measure: - **LCP** (Largest Contentful Paint) — target < 2.5s. Usually a hero image/font/render-blocking JS problem. - **INP** (Interaction to Next Paint, replaced FID) �� target < 200ms. Heavy main-thread JS on interaction is the usual cause. - **CLS** (Cumulative Layout Shift) — target < 0.1. Usually images/ads/fonts without reserved dimensions. - **TTFB** (Time to First Byte) — server/CDN latency; if this is high, it's a backend/infra problem, not frontend. Capture a trace, then check for: unoptimized images, render-blocking CSS/JS in `<head>`, missing `font-display: swap`, excessive third-party scripts, no CDN/caching headers on static assets. ## Backend load testing (locust, in the qa-agent venv) Test types, don't conflate them: - **Load test** — expected peak traffic, sustained, confirm latency/error rate stays acceptable. - **Stress test** — ramp beyond expected peak until it breaks, to find the actual ceiling and failure mode (graceful degradation vs. cascading failure). - **Soak test** — moderate load sustained for hours, to catch memory leaks/connection-pool exhaustion that only show up over time. - **Spike test** — sudden traffic burst (e.g. 10x in 30s), to check autoscaling/rate-limiting behavior. ```bash ~/qa-agent/.venv/bin/python -m locust -f locustfile.py --headless