Why dev profiling lies

Development environments are fast machines with small datasets and no concurrent users. The bottleneck in production is almost never the bottleneck you found in dev.

Real production slowness comes from: N+1 queries against tables with millions of rows, cache misses under actual traffic patterns, memory pressure from genuine concurrent load, third-party API timeouts, and database lock contention.

None of these reproduce reliably on a laptop.

What to measure first

Time to first byte : how long before the server sends anything. If this is slow, the problem is server-side: database, computation, or blocking I/O.

Database query time : instrument your ORM or query layer. Slow queries are the most common production bottleneck and the most actionable.

External service latency : track p95 and p99, not just averages. A third-party API that's fast 95% of the time and times out 5% of the time is a reliability problem that averages hide.

The query you're missing

Every application has one query that looked fine in development and becomes a problem at scale. Usually it's a join without an index, or a WHERE clause on an unindexed column that gets slow only when the table is large.

EXPLAIN ANALYZE is your first tool. A sequential scan on a large table is almost always fixable with an index.

Measuring what users actually experience

Real User Monitoring (RUM) data is more valuable than synthetic benchmarks. What pages do actual users find slow? What percentile of users are you optimizing for?

Optimizing the median experience while p99 users wait eight seconds is a common mistake. Look at the distribution, not the average.