Speed up thread loading over Connect

[brsbl]

The problem

When you open a thread through bb connect, your browser has to talk to your laptop through a long pipe that runs out to Cloudflare and back. Every single question your browser asks down that pipe takes about 95 milliseconds to get an answer, no matter how small the answer is. That's just how long the trip takes.

So if you ask two questions one after the other, you wait ~190 ms. If you ask them at the same time, you wait ~95 ms. The number of questions matters way more than how big the answers are.

Opening a thread used to ask more questions than it needed to, and it asked some of them in a line when they could have been asked all at once.

What this changes

1. Stop waiting in line. Loading a thread needs two things: the thread itself, and its timeline. Neither one needs the other. But the code asked for the thread, waited for the whole answer to come back, and only then asked for the timeline. Now both go out at the same time.

2. Stop asking twice. Right after loading the thread, the app immediately asked for the same thread again. Now it skips the second ask if the first one just answered (within 5 seconds).

3. Stop asking for things nobody looked at. There's a "Parent" dropdown in the thread sidebar. The app fetched the list of possible parent threads on every thread open — even though most people never open that dropdown. Now it only fetches when you actually click it. You'll see a brief "Loading threads…" the first time, and a retry option if it fails.

4. Let answers be zipped. The pipe had a rule that said "don't send me compressed data." That rule made your laptop unzip everything before pushing it through the pipe, so we shipped big uncompressed answers when small zipped ones would do. That rule is gone.

Did it actually work?

Yes for #1, barely for #4. I tested this against the real production Connect — real Cloudflare, real tunnel, not a simulation.

Asking both questions at once (change #1):

	how long
Before (one after the other)	255 ms
After (both at once)	141 ms

That's 114 ms faster, about 45%. This is the change that matters.

Zipping the answers (change #4): barely moves the needle, ~0–10 ms.

The reason is boring: the answers are already small. Earlier work capped how much timeline gets sent at once, so even the biggest threads on my machine only produce 15–61 KB. Zipping shrinks that by 3–4×, which sounds great, but the pipe moves data fast enough (~18 MB/s) that 40 KB was never the problem. The 95 ms trip was.

Zipping still earns its place in two spots, though:

• On a slow connection (say hotel wifi at 10 Mbps), that same 40 KB is worth ~35 ms per request.
• It turns the app's precompressed asset files back on. Those had been silently disabled over Connect this whole time by the "don't send me compressed data" rule, and they're much bigger than any API response.

Bottom line: don't expect to feel the zipping on fast internet. Do expect thread opens to feel snappier.

Things that will look different

• A new "Parent: None" row. If you have a project with only one thread, the Parent row used to be hidden — the app knew there was nothing to pick. Now it can't know that without asking, and asking is the thing we're trying to avoid. So the row is always there for root threads.
• The Parent dropdown can be tabbed to in a couple of cases where it previously couldn't.
• Re-opening a thread you've seen before now asks "what's new since X?" instead of "give me everything," and falls back to asking for everything if the server can't answer that.

The part to be careful about

To let zipped data through the pipe, I rewrote the piece of code that forwards requests, swapping fetch for Node's lower-level HTTP client. This touches every thing that goes through the tunnel — including any dev server you've shared with bb connect expose <port>, not just BB itself. It's the riskiest part of this PR.

Things that could have broken, and why they didn't:

• Garbled responses. Raw headers now get forwarded as-is, which is dangerous if a "this data is chunked" header rides along with data that's already been un-chunked. The relay already throws those headers away (apps/connect/src/tunnel-do.ts:44), so it can't happen.
• Wrong length. A "this is 500 bytes" header on a body that isn't 500 bytes would break things. Checked both places that set it — they always match what actually gets sent.
• Redirects. The old code told fetch not to follow them. Node's client doesn't follow them anyway. Same behavior.
• Reused memory. The new code hands out views into Node's internal buffer. Safe here, because it's copied out synchronously before Node can reuse it.

No daemon protocol version bump needed — the wire format didn't change, no worker code changed, and the already-deployed relay handles these headers fine.

One thing tests can't cover: whether Cloudflare's runtime passes a zipped response through untouched. I confirmed it by hand (step 2 below). Running it locally uses the same runtime but skips Cloudflare's CDN layer, so local testing isn't a full substitute.

How to check it yourself

Node 22, pnpm 9, clean checkout:

pnpm install --offline --frozen-lockfile
pnpm run ensure-native-modules
pnpm exec turbo run test typecheck --filter=@bb/tunnel-client --filter=bb-plugin-connect --force
pnpm exec turbo run test --filter=@bb/app --force -- src/hooks/cache-owners/cache-owner-registry.test.ts src/hooks/queries/thread-queries.test.tsx src/components/secondary-panel/ThreadMetadataContent.test.tsx src/views/thread-detail/ThreadDetailSecondaryContent.test.tsx
pnpm exec turbo run typecheck --filter=@bb/app --force

Then open DevTools → Network and load a thread through bb connect:

1. The thread and timeline requests start together, and the thread isn't requested twice.
2. The timeline response has content-encoding: gzip and a server-timing: bb_connect_origin header.
3. The Connect host log prints timing (originTtfbMs, originBodyMs, responseBytes, contentEncoding).
4. Nothing requests parent candidates until you click Parent. First click shows "Loading threads…", then the list.
5. A root thread in a project with no other threads shows the Parent: None row.

Tests

All green. Tunnel client 6/6, connect plugin 65/65, four focused app suites 28/28, plus typechecks. The full GitHub matrix passes — app, server, integration, packages, checks, and macOS/Linux smoke.

The new tests are the interesting ones. They check that the timeline request really does leave before the thread request comes back, that a warm cache asks for a delta and merges the answer correctly, that the duplicate thread request is skipped when fresh but still happens when stale, and that zipped bytes cross the tunnel byte-for-byte identical.