TypeScript Developer
for SaaS

Performance optimization is fundamentally about measurement. Intuition about what's slow is wrong often enough that optimizing without profiling wastes effort. The tooling stack makes performance visible... Datadog or OpenTelemetry APM shows where time goes inside request traces, pg_stat_statements and EXPLAIN ANALYZE reveal query inefficiencies, k6 or Artillery expose scaling limits under realistic burst patterns. Most performance problems fall into predictable categories: database queries scanning entire tables, N+1 patterns fetching data one row at a time, missing caching for expensive computations, synchronous operations that could be async, unoptimized images shipping 4MB hero assets to mobile users, render-blocking JavaScript, and cold start penalties on serverless runtimes. These patterns have known solutions... the skill is identifying which apply to your specific system and which matter for your user experience. The goal isn't maximum performance; it's appropriate performance at reasonable cost. A 50ms API response might be adequate; optimizing to 5ms might cost 10x engineering effort with no user benefit. TraceForge taught me this the hard way: the 337x speedup came from moving work to the GPU, not from tweaking the CPU path for another 20%. Architectural moves beat micro-optimizations, and knowing when to stop optimizing is as valuable as knowing what to optimize.

Performance optimization engagements begin with baseline measurements. I instrument the application with Datadog or OpenTelemetry, enable pg_stat_statements, configure slow query logging at a pragmatic threshold, and set up synthetic monitoring for critical user flows. This produces the data for informed decisions instead of guessing. The profiling phase analyzes production data to identify actual bottlenecks. I look at P50, P95, and P99 latencies... the P99 often reveals problems invisible in averages, where one slow query every 100 requests drags the tail latency past SLA. Database query analysis identifies slow queries, missing indexes, and N+1 patterns hidden inside ORM abstractions. Frontend work uses Lighthouse, WebPageTest, and Chrome DevTools performance traces to find render-blocking resources, layout thrashing, and wasted hydration. From profiling data, I architect a prioritized optimization plan. Each item has estimated effort, expected impact, and a measurable success criterion. Highest-impact, lowest-effort items come first... a missing index can ship in an afternoon and cut P99 by 80%. Implementation follows the measure-optimize-verify loop. Each optimization is measured before and after in production-realistic conditions. Changes that don't measurably improve the target metric get reverted, no exceptions. Load testing with k6 replays real traffic patterns, including the burst profiles that cause incidents, to validate optimizations hold under peak load. The engagement ends when the next optimization costs more than it saves... not before, not after.