Tab switching is slow: conversation fully re-rendered 2-3x per switch (~5s main-thread block on long sessions)

[ashwin-pc]

Summary

Switching between pinned session tabs is very slow (UI frozen ~5+ seconds when switching to a long session). The network is not the bottleneck — the cost is synchronous re-rendering of the entire conversation, done 2–3× per switch.

How it was measured

Pinned 4 long sessions (1453, 1315, 1069, 808 messages) and instrumented tab switches in the browser with:

• a wrapped fetch for per-endpoint timing,
• a MutationObserver on the messages container to detect render settle,
• a longtask PerformanceObserver to quantify main-thread blocking.

Results — switching to the 877-node "Ui" session

• 5,564 ms total main-thread blocking, dominated by two ~2,580 ms long tasks
• firstRenderMs ≈ 2,600–3,000 ms; total settle ≈ 5,750 ms
• /api/messages returned in 38 ms, /api/sessions/open 6–290 ms, /api/state ~80 ms

The two back-to-back ~2.58 s long tasks are two full re-renders of the same conversation.

Root causes (in order of impact)

1. Entire conversation is re-rendered synchronously on every switch — and twice

The double render happens because a switch triggers refreshMessages() down two independent paths:

• openSessionTab() → refreshState() → refreshMessages() (src/sessions/sessionDrawer.ts:475, src/main.ts refreshState)
• The server's /api/sessions/open handler calls broadcast({ type: "state_changed" }) (server.ts:1805), and the realtime client responds with another refreshMessages() (src/realtime/realtime.ts:288-289)

Each refreshMessages does clearInternal() + rebuild of hundreds of DOM nodes + markdown parsing, with no virtualization, no diffing, and no per-session render cache (src/messages/messageList.ts:512). Logs showed 2–3 /api/messages calls per switch.

2. "Slow" artifact fetches are a symptom, not a cause

Logs showed /api/artifacts/*.md taking ~2,300–2,500 ms each, but curling the server directly returns them in 1.5 ms (404 — the file belongs to a different session's cwd). The multi-second timing is purely because the await/.then() can't resume until the giant synchronous render finishes; the fetches are queued behind a blocked main thread. Two secondary issues feed this:

• enhanceArtifactLinks (src/markdown/render.ts:213) re-fetches every artifact preview on every render and caches nothing; each duplicated render wave re-fires them.
• Artifacts are resolved against the current server cwd, not the session's cwd, so cross-cwd sessions always 404.

Impact

Per switch to a long session the UI freezes ~5+ seconds, roughly half of which is purely redundant (the second full render from the websocket broadcast).

Suggested fixes (not yet applied)

1. Kill the double render — dedupe refreshState's refreshMessages against the state_changed broadcast the same client just caused (ignore self-triggered open broadcast, or coalesce refreshes). Roughly halves switch time on its own.
2. Stop full re-rendering — cache rendered conversation DOM per session and swap it in, or virtualize/window the message list and render markdown lazily (an IntersectionObserver-based lazy renderer exists in render.ts, but the initial build is still eager).
3. Cache artifact previews and resolve them against the session's cwd so they don't 404 / re-fetch on every render.

[ashwin-pc]

I agree with the diagnosis, but I’d prefer we avoid jumping straight to DOM caching or virtualization as the first fix.

Those approaches could make tab switching faster, but they also increase the amount of hidden state in the UI: stale cached DOM, event-listener lifetime issues, settings/theme invalidation, scroll restoration edge cases, browser find/selection behavior with virtualization, memory growth, etc. I think we can get a big win while making the app easier to reason about instead of more complex.

Suggested approach:

1. Make refresh ownership explicit: one switch → one message render

   • Today /api/sessions/open returns to the initiating client, which calls refreshState() → refreshMessages().
   • The server also broadcasts state_changed, and the same client handles that by calling refreshMessages() again.
   • We should either tag/skip the self-caused websocket event or otherwise coalesce that path so the initiating tab renders messages exactly once. The broadcast can still update other clients.

2. Centralize/coalesce message refresh scheduling

   • Instead of every module freely calling refreshMessages(), route refresh requests through a small coordinator with clear reasons like active-session-changed, messages-changed, or stream-ended.
   • This is not caching; it just gives us a single place that guarantees duplicate refresh requests in the same turn do not trigger duplicate full renders.

3. Keep full-history rendering simple, but remove avoidable synchronous work

   • For the first pass, keep the current mental model: fetch messages, rebuild the list.
   • But make bulk rendering cheaper:
     • don’t call scrollToBottom() for every message during refreshMessages();
     • build into a DocumentFragment or otherwise suppress layout-affecting work during the loop;
     • scroll/restore once at the end.
   • This should reduce layout thrash without introducing a cache invalidation model.

4. Postpone DOM caching/virtualization

   • I would treat rendered-session DOM caching and message virtualization as later options only if the simpler fixes still leave switching too slow.
   • They are much more likely to make the UI flaky over time than a single-refresh contract plus cheaper bulk render.

5. Artifact previews: correctness first

   • Make artifact resolution session/cwd-aware first.
   • If needed after that, add a small content cache for fetched preview text, not a cache of rendered preview DOM.

A good first PR would be intentionally small:

• prevent the self-triggered state_changed from causing a second refreshMessages() on session open;
• introduce a tiny refresh scheduler/coalescer if needed;
• suppress per-message scrolling/layout work during bulk message render;
• measure again before considering virtualization or DOM caching.

This should cut a large part of the tab-switch freeze while also simplifying the data-flow contract: session switch updates metadata once and renders messages once.

[ashwin-pc]

Follow-up: I measured the fragment approach directly — it works, but it's a partial win

I ran controlled experiments in the browser (real 877-message session, headless Chrome, longtask + CPU profile) to verify the proposed DocumentFragment + single-scroll change before we commit to it. Summary: it's real and worth doing, but it does not address the dominant per-render cost.

1. Fragment / single-scroll — validated, ~20% per render

Isolated microbenchmark (real message nodes pre-cloned so only the append+scroll pattern varies, 293 nodes):

pattern	time
current (append per node + per-node scrollHeight read)	~129 ms
fragment (one append, one scroll)	~37 ms (3.5× faster)

Live A/B on a real RB→Ui switch (877 nodes), neutralizing the per-node forced layout:

	main long task
baseline	2,607 ms
no per-node forced layout (≈ fragment)	2,068 ms

So the fragment change saves ~430–540 ms per render on the live pipeline (~20%), roughly double once the double-render is also fixed. Low risk, worth including. (Note: forceScrollToBottom shows ~943 ms self-time in the profile, but only ~430–540 ms is actually removable — the rest is layout that must happen once at paint anyway.)

2. The dominant cost is synchronous highlight.js, which the fragment change does NOT touch

CPU profile of a single ~2.4 s render, self-time by function:

cost	self time
highlight.js syntax highlighting (exec / escapeHTML / processLexeme / startNewMode / …)	≈ 1,700 ms
forceScrollToBottom (per-node forced layout)	≈ 943 ms (~430–540 ms removable)
set innerHTML (markdown HTML injection)	≈ 448 ms
set textContent	≈ 234 ms

Markdown parsing is already lazy via the IntersectionObserver in render.ts, but enhanceCodeBlocks / highlightMarkdownCode still run hljs.highlight/highlightAuto eagerly for the code blocks that do get rendered during the loop, and highlightAuto in particular is very expensive. This is the single largest contributor to each render and is not covered by step #3 of the current plan.

Updated impact ranking (all measured)

1. Kill the double render (refreshState + self-triggered state_changed → two refreshMessages) — ~50% off the total freeze. Highest impact, lowest risk. Confirmed: the fetch-only path produces one ~2.4 s task vs. two via the UI click path.
2. Defer/lazy syntax highlighting — only highlight code that's actually visible (tie it into the same IntersectionObserver path as markdown), or move highlighting off the main thread / onto requestIdleCallback. Targets the ~1,700 ms that dominates each render. This is the item the current plan is missing.
3. Fragment + single-scroll — real ~20% per render, cheap and safe, but not the big lever.

Happy to help with any of these; I'd suggest landing #1 first (biggest, simplest), then #2, and re-measuring before deciding whether virtualization/DOM caching is still needed.

[ashwin-pc]

Closing for now since the current tab-switching behavior has been addressed. We can reopen if long-session switching regresses.