Performance Engineering
"Make it faster" is one of the most common engineering requests and one of the most commonly botched. The typical vibe-coder response is to add a cache, increase the server size, or try random optimizations until something seems to help. The engineering response is to measure first, identify the actual bottleneck using profiling tools, fix the specific problem, and measure again to verify improvement. Amdahl's Law is unforgiving: optimizing the wrong 20% of the code gives you nothing. This module teaches performance engineering as a discipline — starting with measurement and profiling before any optimization. You'll use flame graphs to find CPU hotspots in real applications, heap snapshots to identify memory leaks, EXPLAIN ANALYZE to find database query bottlenecks, and Lighthouse to analyze frontend performance. You'll understand the difference between latency and throughput, and why percentile metrics (p99, p999) matter more than averages for understanding user experience. The project is deliberately provocative: you'll take a slow application and optimize it by 100x, documenting every optimization and its measured impact. Not 10% — 100x. That level of improvement is possible when the bottleneck is a fundamentally wrong algorithm or missing index, and finding it requires the systematic profiling approach this module teaches.
What You'll Learn
-
1
The Performance Mindset — Measure first, Amdahl's Law, latency vs throughput
-
2
CPU Profiling — Flame graphs, sampling vs instrumentation, JIT effects
-
3
Memory Profiling — Heap snapshots, GC pressure, memory leak patterns
-
4
Database Query Optimization — EXPLAIN ANALYZE, index selection, N+1 in ORMs
-
5
Frontend Performance — Bundle analysis, render profiling, network waterfall, RUM
-
6
Load Testing — k6, Artillery, percentile charts, finding the knee of the curve
-
7
Caching Strategies in Practice — L1/L2/CDN, cache stampede prevention, TTL selection
-
8
Async and Parallel Processing for Performance — Concurrency vs parallelism, worker threads
Capstone Project: Optimize a Deliberately Slow Application 100x — Document Every Optimization
Take a deliberately underperforming application with multiple layers of intentional bottlenecks — missing indexes, N+1 queries, synchronous blocking I/O, unoptimized bundles, no caching — and systematically optimize it to handle 100x the original load. Every optimization must be preceded by a profiling step that identifies the bottleneck and followed by a measurement that quantifies the improvement, producing a written performance analysis that documents the full journey from 10 RPS to 1,000 RPS.
Why This Matters for Your Career
Performance is a feature, and performance engineering is one of the highest-leverage skills in production engineering. A 10x improvement in system throughput can defer a significant infrastructure spend. A 100ms reduction in page load time can meaningfully improve conversion rates. The engineers who can systematically find and eliminate bottlenecks are the ones who make these improvements happen reliably, not accidentally. N+1 queries in ORMs are one of the most common causes of preventable slowness in web applications. They're invisible in development with small datasets, catastrophic in production with real data, and trivially fixable once you know what to look for. Engineers who understand how ORMs generate SQL, how to read EXPLAIN ANALYZE, and how to eagerly load associations can catch and fix these issues as they're introduced rather than after users start complaining. Load testing separates systems that can handle real traffic from systems that pass development testing. Understanding how to design a load test, interpret percentile charts, identify the knee of the curve where the system starts degrading, and trace the bottleneck back to a specific component is what makes load testing useful rather than decorative. Engineers who can run and interpret load tests can tell you exactly what happens when your application gets on the front page of Hacker News.