Why is the app fast in development but slow in production?

Because most bottlenecks scale with data, not with your test setup. An N+1 query is invisible against ten local rows at sub-millisecond each and dominant against production tables; the same goes for unpaginated endpoints and missing indexes. The code did not get slower, the data got bigger and the shortcuts came due.

Can we just upgrade the database instance instead of fixing the code?

For a while, yes, which is exactly why teams keep doing it. But hardware buys time linearly while problems like N+1 queries and nested loops grow with the data, so the upgrades work until they abruptly do not. You cannot provision your way out of an O(n squared) loop.

How do I find N+1 queries in my own codebase?

Turn on query logging, exercise a hot path, and count the queries per request; a list page issuing one query per row is the signature. The fix is usually a one-liner (select_related, includes, or a JOIN depending on your ORM), and once you find one instance, grep for its siblings, because the same author pattern tends to repeat.

We already have APM monitoring, so why would humans need to read the code?

Monitoring tells you that an endpoint is slow and sometimes where the time goes; it rarely tells you the shape of the mistake or how many other places the same pattern lives. It also only measures traffic you have today, while an audit reads for the bottleneck you will hit at next year's scale, like the endpoint that is fine at thousands of rows and a timeout at hundreds of thousands.

What does a performance-focused audit actually check?

Roughly what this article walks through: query patterns and indexes, over-fetching, synchronous work sitting on the request path, caching in both failure directions, bundle composition, and infrastructure seams like pool sizing and missing timeouts. Webisoft's free audit covers these areas by hand, an engineer reads your hot paths and sends a written report of what is slow, why, and what to fix first, within a few business days.

Performance Bottlenecks a Code Audit Reveals

“It’s slow, and we don’t know why”

The app was fast at launch. Two years and forty features later, the dashboard takes eight seconds, mobile users bounce, and the team’s diagnosis is a shrug plus a proposal to upgrade the database instance. Again.

Here’s the uncomfortable pattern we see in audits: performance problems are almost never one dramatic flaw. They’re an accumulation of small, individually-reasonable decisions, each one invisible at the traffic level it was written under. The code didn’t get slower; the data got bigger and the shortcuts came due. That’s also why throwing hardware at it works for a while and then abruptly doesn’t: you can’t provision your way out of an O(n²) loop.

A performance-focused code audit reads the code asking one question the original authors couldn’t: what does this line do at 100× the data? Here’s where the answers usually hide.

The database layer: where most of the time goes

N+1 queries

The single most common finding, in every ORM, every stack. Load a list, then loop and load a related record per item:

orders = Order.objects.all()          # 1 query
for order in orders:
    print(order.customer.name)        # 1 query PER order

Two hundred orders, 201 queries. It’s invisible in development (10 rows, local DB, sub-millisecond each) and dominant in production. The fix is a one-liner (select_related / includes / a JOIN); the hard part is finding every instance, which is why auditors read the hot paths with query logging on rather than trusting the ORM to have done the right thing.

Missing indexes, and queries that defeat existing ones

Every WHERE, JOIN, and ORDER BY column on a large table is a candidate; audits run EXPLAIN on the top queries and look for sequential scans on big tables. The subtler variant: an index exists but the query wraps the column in a function (WHERE LOWER(email) = ...) or leads with a wildcard (LIKE '%term'), so the index never fires. This layer is deep enough that we gave it its own article.

Over-fetching

SELECT * on a table with a JSON blob column; loading full objects to render three fields; fetching 10,000 rows to display 20 because pagination happens in application memory. Each is a bandwidth and memory tax that scales with your data, not your traffic: the nastiest kind, because it grows while traffic is flat.

The application layer: work in the wrong place

Synchronous work on the request path

Sending a welcome email, resizing an avatar, calling a third-party API, generating a PDF. Inline, inside the HTTP request. The user waits for all of it, and one slow third party takes your endpoint down with it. The audit question is simple: does the response depend on this work? If not, it belongs in a queue. Finding fifteen violations of that rule in one codebase is typical, because each one was added on a day when it was the fastest way to ship.

Loops that multiply

An API call inside a loop. A loop inside a loop over two lists that should have been a hash join. Per-item database writes that should be one bulk insert. In our experience the worst offenders are in nightly jobs and admin pages: nobody profiles those until the nightly job starts finishing at noon.

Missing caching, and broken caching

Recomputing an expensive aggregate on every page load when a five-minute-stale answer would be fine. But the flip side shows up too: caches with no invalidation strategy (“why does the dashboard show yesterday’s numbers?”), cache keys missing the user ID (users seeing each other’s data; now it’s a security finding), or caching so aggressive that the cache itself is the memory bottleneck. An audit checks both directions.

The frontend: shipping too much, too early

Bundle bloat

The classic audit moment: run a bundle analyzer, find that the marketing homepage ships a charting library, a PDF renderer, and all of moment with locales: 2 MB of JavaScript for a page with none of those features, because everything is imported at the top level and nothing is code-split. Every kilobyte is parse-and-execute time on the median phone, which is much slower than the M-series laptop the team tests on.

Quick check on any JS project:

npx source-map-explorer dist/assets/*.js

If the biggest block is a library you use on one admin screen, that’s a lazy-import away from fixing.

Waterfalls and render thrash

Component A fetches, renders, then child B fetches, renders, then C: three round trips serialized by the component tree, when one composed request would do. Add unmemoized re-renders re-fetching on every keystroke and you get UIs that are slow on fast connections, which confuses everyone. This one’s found by reading component code and watching the network tab; no static analyzer flags it.

The infrastructure seams

Not code exactly, but audits catch them because the code implies them: connection pools sized smaller than the worker count (requests queue for a connection under load, and the symptom looks exactly like a slow database), missing gzip/CDN on static assets, containers with memory limits that guarantee OOM restarts at peak, no timeout on outbound HTTP calls so one hung dependency pins every worker. That last one is a reliability finding wearing a performance costume.

Why an audit finds what monitoring misses

If you have APM, you might reasonably ask why you’d need humans to read code. Two reasons.

First, monitoring tells you that an endpoint is slow, and sometimes where the time goes; it rarely tells you the shape of the mistake or how many other places the same pattern lives. An auditor who finds one N+1 greps for its siblings and finds nine.

Second, monitoring only measures traffic you have. An audit reads for the bottleneck you’ll hit at next year’s scale: the unpaginated endpoint that’s fine at 5,000 rows and a timeout at 500,000. Fixing that before the growth spike is a code review; fixing it during is an incident. The gap between tool output and human reading is the theme of manual vs. automated code audits, and it applies double to performance.

The pattern across everything above: each bottleneck was invisible when written and became expensive silently. No single commit made the app slow. That’s why “we’ll optimize when it hurts” underperforms: by the time it hurts, the causes are two years deep in the history and load-bearing.

Get a free code audit

If your app has crossed from “snappy” to “we apologize in demos,” the causes are findable: they’re in the code, in roughly the places this article describes. We offer a genuinely free manual code audit: a Webisoft engineer reads your hot paths, checks the query patterns, bundle composition, and request-path work described above, and sends a written report of what’s slow, why, and what to fix first. Genuinely free, delivered by a human who has done this before. Get a free code audit.