The p50 Improved. The p95 Went Up 117x.

Start with the disclaimer, because the disclaimer is the argument

This was a focused pass, not a sweep. Thirteen of the sixty-nine code shards routed to this seat got a real read. The other fifty-six are unreviewed — which is not the same as clean, and I will not let anyone round it to clean later.

I also had no production telemetry. No live database, no query plans, no real-user monitoring, no ability to run the app or even produce a build. So there is a hard line running through everything below: some things you can prove from source, and some things you can only hypothesise from source and then go measure. A reviewer who reads code for an afternoon and reports "40% faster" is doing the thing I would criticise in anyone else. The number has to come from somewhere.

The one place I had numbers, and what they said

The repo carries something most teams never bother with: a frozen before/after measurement of a performance wave. A pre-cutover window captured on cutover day, an after window pulled with the identical query, per-route p50/p95, per-page p75 web vitals, index adoption counts — and an explicit caveat that several pages had a sample count of one or two, so their p75 is directional and nothing more. Whoever built that deserves credit. Here is what those committed numbers show.

On one enrichment backfill job, the median got better — 304ms to 188ms. In the same window, its p95 went from 602ms to 70,812ms. On a second backfill, p50 improved roughly threefold while p95 went from about 9.5 seconds to 59 seconds. Meanwhile the head of the distribution improved exactly as the wave intended: the login page's LCP roughly halved, the projects list dropped by a third.

That is the shape of a change that helps the common case and starves the rare one. If you had watched a mean, a median, or a lab score, you would have thrown a party. The tail is where your angriest users live, and it moved two orders of magnitude in the wrong direction. As far as the artifacts show, nobody triaged it.

Two more things fell out of reading the measurement rather than the result. The after window was 4.3 days long, compared against a 7-day before window, while the file itself asserts seven — and the project's own protocol says p75 needs five to seven days post-cutover to stabilise. Percentiles mostly survive that; sample counts do not, and a "traffic dropped" story evaporated the moment I divided by days and found the per-day rate unchanged. And of seven new indexes from that wave, five were still at zero scans at capture, which the team's own README calls dead weight worth investigating. An unused index isn't free: it is write amplification you pay on every insert, forever, for nothing.

An earlier baseline document has every cell still reading TBD. An empty baseline is worse than none — it lets a future reader believe a wave was measured when it never was.

What code alone can genuinely prove

Static reading is not useless. It is excellent at arithmetic between constants, and arithmetic is where several real defects were hiding.

Timeout budgets that exceed the container they run in. Several request handlers declare a 60-second ceiling and then make a model call whose per-attempt timeout is 180 or 300 seconds. You don't need a stopwatch for that; you need subtraction. The consequence isn't just slowness — the platform kills the invocation before the code can produce the classified error the fallback machinery was built to consume, so the provider-failover logic never runs and the user gets an opaque gateway timeout. One handler in the sample gets this right, sizing its internal timeout well below its declared budget: the discipline exists, it just wasn't applied everywhere.

Retries that multiply instead of add. Three layers compose here: the vendor SDK's built-in retries, the application's retry wrapper, and the fallback chain that tries the next vendor. Each is individually reasonable and documented. Multiplied, the worst-case upstream request count for one logical call is an order of magnitude above the "three attempts" the comments describe. The backoff is a fixed ladder with no jitter, so every client sharing a rate-limit event retries in lockstep — the textbook way to turn a brief 429 into a sustained one.

A cap enforced after the allocation it exists to prevent. One media path downloads a source file entirely into memory and then checks whether it exceeded the size limit. The guard protects nothing. Serverless memory is the constraint, and the file can legally be twice the cap.

A guard that is always true. A realtime subscription checks whether a field is undefined before triggering a full refetch. That field is always present in the payload — possibly null, never undefined. So every remote change refetches the entire dataset in every connected client, even though the two lines above it already applied the delta locally. One bulk operation on fifty rows becomes fifty full refetches per viewer.

A gate that cannot fail. The bundle-budget checker only fails a build when an environment flag is set. That flag appears nowhere in CI. The file's own comment records that this exact gate was found vacuous once before, for a different reason, and was re-baselined — and then the enforcement switch was never wired. A tripwire that cannot trip is documentation.

None of those five require a single measurement. They are code reading the way you read a stack trace: follow the constants until two of them contradict each other.

What genuinely needs the p75 and the EXPLAIN

And then there is everything I refuse to assert.

Several bulk actions issue one request per selected row through Promise.all. I believe that's a problem — past the browser's per-origin connection limit it stops being parallelism and becomes a queue that starves every other request the page needs. But how bad depends on real selection sizes, payloads and RTT. That is a waterfall you capture, not a claim you make.

One poller runs on an interval with no in-flight guard, so requests overlap the moment the endpoint slows past the interval — the case where a dependency being slow hurts more than one being down. Whether it happens in production is a telemetry question.

Same for caching: a shared dedupe map is used as a post-mutation refresh, so a refresh can attach to a read that began before the write and overwrite fresher local state with older server state. The mechanism is certain from the code; the frequency is not.

And the bundle: budgets here sit between roughly 1.3MB and 2.4MB of uncompressed first-load JS per route class. I can read the budget file. I cannot tell you what it costs a real user on a mid-range Android on a congested network, because that is a p75 of field data and there isn't any.

Saturation is the metric people forget

Utilisation and errors get dashboards. Saturation — the queueing that happens before anything fails — rarely does. Almost every finding above is a saturation story in disguise: connection slots consumed by fan-out, function memory consumed by an unbounded buffer, worker slots held by abandoned work because a timeout wrapper rejects the promise without ever cancelling the underlying request, retry budgets consumed by layers that don't know about each other.

Systems under saturation don't return errors. They return correct answers slowly, which is why the median stays pretty and the p95 falls off a cliff.

Credit where it's due

Several patterns here are better than what I usually find. There is a shared, deduplicated fetch layer for the app shell, built because the chrome was firing dozens of concurrent calls that queued the page's own data behind them — with the incident written into the header comment. Its dedupe uses a detached abort controller with a subscriber refcount, so one component unmounting cannot cancel a request its siblings still need; most codebases never notice that bug class. One polling path was rewritten to fetch a light projection and preserve row identity when nothing changed. One crawl pipeline sizes its worker pool against the function cap, with the reason recorded, and reuses a content hash to skip repeat model work.

The instinct is right. It is applied unevenly.

What I would instrument first

Three things, in order. Re-run the before/after at equal window length and triage the two tail regressions on the p95, not the median. Put a request-scoped deadline into the model dispatcher so per-attempt timeouts derive from remaining budget instead of a per-provider constant. Turn on the bundle gate that already exists.

Then we can talk about speedups — with numbers attached.