Performance budgets belong in unit tests

Write the budget as an assertion

describe("thread transport payload budget", () => {
  // …
  expect(projectedBoundedRpcJsonBytes / fullRpcJsonBytes).toBeLessThanOrEqual(0.02);
});

The targets are concrete numbers, not "fast enough":

If someone adds a field that bloats the payload, the test fails on their machine, before review. A ratio is better than an absolute size here: it stays meaningful as the fixture data grows.

Benchmark the path users actually run

The performance doc warns that old benchmark fixtures seeded data in the previous format, and running them against the new client "can produce reassuring timings while missing the active transport path." A benchmark that measures the wrong path is worse than none, because it tells you you're fine.

Five patterns from the commit log

1. Fix it, then make it impossiblePR #15265 was a one-line fix: a broad CSS :has() selector made every DOM change restyle the whole page. PR #15274 added a lint rule that flags those selectors, so the whole class of bug is gone.
2. "Did anything change?" before "what changed?"Watching pull requests used to read each PR in full on every pass. Now it checks a cheap one-point fingerprint first and reads in full only when it moves: about 90% fewer GitHub API points (#16270). It's the ETag idea applied to a polling loop.
3. Per batch, not per itemBackground branch lookups share one GitHub query per sweep (#16760). PATH is scanned once per command, not on every spawn (#12600). Streamed tool output no longer persists a snapshot per chunk (#16682).
4. Keep heavy data off the wireRaw command output, tool result bodies and inline diffs are never pushed over the socket. Stored events keep everything; the client fetches a body only when someone opens it.
5. Skip work nobody can seeTimers pause on hidden mobile screens (#15397), the command palette is virtualized (#15266), live git and PR queries are leased to visible rows plus a small overscan, and an unchanged poll returns the same array so subscribers don't re-render.

Reconnects that don't stampede

Without jitter, every client of a restarted server reconnects in the same second; with a short cap, a client that can never connect retries all day.

So: jittered exponential backoff, capped at five minutes, reset only after a connection has stayed up. The reset rule matters: resetting on connect would let a flapping server pull every client back into a tight loop.

Turn one of this codebase's performance expectations into a unit test.

The idea: write the budget down as a number (bytes sent, queries per request, items rendered, calls made) and assert it in a normal test, so a regression fails the build instead of reaching users.

1. Find the hot path that matters most to users here: a page load, an API response, a sync, a render. Measure what it does today: payload size, number of queries or calls, or work per item.
2. Propose one or two budgets with concrete numbers and a little headroom, and explain why each number matters. Prefer deterministic counts over wall-clock time.
3. Write the tests against the code path users actually run, not a simplified fixture.
4. Find the most recent performance fix in the git history. If a lint rule or check could stop that whole class of bug, propose it.

Keep the change small and show me the measured numbers.