Repository navigation
🤖 perf: the workspace page loads the artifact frame chunk since #7455 (seeded desktop LCP +40 ms) #7510
Description
Since #7455 (agent interface view), the seeded workspace page loads the artifact frame chunk on every open, even when the Agent interface view experiment is off. VM Lighthouse seeded desktop LCP moved up by about 40 ms and has stayed there. #7472 fixed the first-load main chunk (#7471), but not this.
Evidence (VM Lighthouse run folders, seeded desktop)
- Every real cycle on 10-25 before 🤖 feat: agent interface view shows the agent's status page instead of the chat #7455 had a desktop median of 1560-1570 ms (021720Z, 022743Z, 050604Z, 061246Z, 080651Z, 090608Z). Every real cycle since has been 1600-1612 or 1641-1651 ms (the known +40 build-byte step). The old trigger at 1647.3 ms now fires on commits with no browser change (173614Z on
fbbce35749, CI only). - Transfer bytes, run 1 of 090608Z (
61e9f05199) vs run 1 of 173614Z (fbbce35749):
| Chunk | before | after | delta |
|---|---|---|---|
SandboxedArtifactFrame-*.js |
0 | 14,227 | +14,227 |
mermaid-*.js |
239,422 | 252,499 | +13,077 |
McpAppFrame-*.js |
24,774 | 14,549 | -10,225 |
RightSidebar-*.js |
110,087 | 101,093 | -8,994 |
| total | 1,154,371 | 1,161,323 | +6,952 |
Cause (import chain, read on origin/main)
src/browser/components/ChatPane/ChatPane.tsx:74 statically imports AgentInterfaceStatusView, and ChatPane always renders it (ChatPane.tsx:1660). AgentInterfaceStatusView.tsx:15 imports ArtifactViewer, which imports SandboxedArtifactFrame (ArtifactViewer.tsx:18). So the frame code loads with the workspace page, whether or not the status view can ever show.
I did not attribute the mermaid-*.js growth. It is probably shared code that Rollup now places in that chunk. Check it with a source-map diff of the chunk.
Fix sketch
Load AgentInterfaceStatusView through a module-level React.lazy wrapped in LazyFeature, and render it only when the view is status (the open condition stays in ChatPane, per AGENTS.md "Module Imports"). Check WorkspaceMenuBar.tsx:17 (AgentInterfaceViewToggle) the same way.
Gate: SandboxedArtifactFrame-*.js is absent from the seeded page's requests with the experiment off, the mermaid-*.js delta is explained or reverted, and the VM seeded desktop median goes back below the 1647.3 ms line on a 3-run cycle (and under 1620 ms in 2 of the next 3 cycles).
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
Activity
ThomasK33 commentedon Oct 25, 2026
Issue coordinator desk (workspace 3203e76efb): file clearance for #7510. No desk lane holds
src/browser/components/ChatPane/ChatPane.tsx,src/browser/components/WorkspaceMenuBar/WorkspaceMenuBar.tsxorsrc/browser/rendererFirstLoad.test.ts(or a sibling test). No one has claimed #7510. The desk's only running lane works onsrc/node/runtime/sshAskpass.ts(#7498) andPluginsSettingsSection.hooks.test.tsx(#7494).Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 25, 2026
Perf owner:
#7515made the seeded desktop page slower, so I am reverting it and reopening this issue.Result. A same-session VM A/B (seeded desktop, 6+6 ABBA,
runs-ab/20261025T195728Z, all runs quiet) measured median LCP 1615.0 ms oncf7b78bd55(before) and 1687.5 ms on47d2e4df7d(#7515). That is +72.5 ms, over the +40 ms limit. Score 93 in both arms, TBT about 0.Cause. The seeded workspace page also loads the right sidebar (RightSidebar, McpAppFrame). Those chunks import the artifact stack too:
McpAppFrame.tsx:59importsARTIFACT_IFRAME_SANDBOXfromSandboxedArtifactFrame.AgentInterfaceStatusViewchunk shareuseArtifactInteractions, the viewers andHighlightedCode/diffparse. Rollup split them into new shared chunks.Before
#7515, the frame code loaded in the early wave (about 150 ms, in parallel). After it, the frame chunk and two new chunks (useArtifactInteractions13.0 KB,parse2.5 KB) load in the right-sidebar wave (about 335-380 ms), plusartifacts(3.1 KB) in the early wave. Requests go from 33 to 36 and script bytes rise by 5.8 KB. LCP equals TTI in every run, so the later end of the request graph moves LCP.My gate was wrong. I set the lane's byte gate on the static closure of
mainandAIView. The seeded page's real request list also contains the right-sidebar wave. The next attempt must gate on the seeded page'snetwork-requestslist (noSandboxedArtifactFrame, no new requests) and on a VM A/B, not on a closure sum.Next.
#7515(link follows). The lane's work is not wrong in itself; the page needs the sidebar side fixed first.ARTIFACT_IFRAME_SANDBOX(and other constants McpAppFrame needs) to a light module, and keep the artifact viewer stack out of the RightSidebar chunk until the Artifacts tab opens. Then the status view can go lazy again.Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 25, 2026
Perf owner, fact for this issue:
#7514(merged085270490b, artifact frame backdrop color) adds 944 B brotli to theSandboxedArtifactFramechunk (14,231 -> 15,175 B on the VM). The seeded workspace page still downloads that chunk in its early wave, so this cost lands on every workspace load until this issue is fixed. Requests stay at 33. VM cycle20261025T233220Z: seeded desktop LCP 1647/1648/1648 ms (the upper of the two current desktop levels; no A/B, because the level also appears on commits with no renderer change).Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high🤖 perf: load the agent interface status view only with the view (code…
🤖 perf: revert coder#7515 (status view lazy load added late sidebar r…
ThomasK33 commentedon Oct 26, 2026
Perf owner update: the desktop LCP "upper level" is not caused by the artifact frame load. I am narrowing this issue.
Evidence (Lighthouse auditor VM, seeded desktop, 3 runs per cycle, all on main after #7521):
pand placeholder tips occur in both levels).So the ~40 ms step is inside the Lantern simulation, not in measured page timing. The frame cost from #7455 is real (A/B in #7521) but it is not the two-level effect. Next: Lantern debug traces for both levels to find the node that moves. The "light module for ARTIFACT_IFRAME_SANDBOX" plan stays, gated on its own A/B.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 26, 2026
Perf owner: first Lantern simulation traces (cycle 20261026T132208Z on e09bb8e, upper level, desk 1652.6 / 1644.2 / 1659.1) show what ends the simulated LCP.
The simulated LCP is the end of the
RightSidebar-*.jsdownload (~101 KB). Optimistic and pessimistic estimates are equal in all 3 runs, so the blend is not the cause. The last part of the simulated critical path, run 1, in ms:Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 26, 2026
Perf owner: a third desktop level (~1565 ms) has a found cause: the GeistMono font request. The 1607 vs 1648 split is still open.
Cycle 20261026T170210Z on 59af183, seeded desktop, Lantern traces kept for each run:
RightSidebar-*.jsends at 1565 instead of 1645, and the 6 lazy chunks start at 1323 instead of 1402.GeistMono-Variable-*.woff2is 58,438 B at priority VeryHigh. It is not preloaded.@font-faceinsrc/browser/styles/globals.css:55loads it when the first monospace text lays out during startup.New lead (not started, needs an A/B): find which startup element uses the mono font. If it is not needed for the first transcript paint, rendering it later (or with the primary font) takes 58 KB off the LCP path. Expected gain: up to ~80 ms desktop Lantern, plus less bandwidth competition for real users on slow links.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 26, 2026
Perf owner: proven. The two desktop LCP levels (~1607 / ~1648 ms) are a Lantern simulation artifact. A ~100 B change in the compressed size of
API-*.jsdecides which level a cycle lands on. No code change causes the upper level.Evidence
API-*.jsends at 685 instead of 646, andmain.jsat 845 instead of 806. Both are +39 ms, which is one desktop RTT (40 ms). Every later node shifts by that.API-*.jshas the sameresourceSize(489,040 B) in both runs, but itstransferSizechanges by about ±150 B from build to build, because the renamed chunk hashes compress differently. Across 188 desktop runs on Oct 25-26 it separates the levels with no overlap: low ≤ 132,856 B, high ≥ 132,864 B.LanternLargestContentfulPainton copies of the saved trace + devtools log. OnlyencodedDataLengthofAPI-*.jschanges. Delta 0 reproduces the report exactly). I reran it myself:132,860 B = 91 × 1460 B (TCP MSS). The 92nd segment needs one more simulated TCP round, which adds 40 ms. Changing
main.jsby ±500 B does not change the LCP.Consequences
API-*.jstransferSize. At ≤ 132,860 B, the reference is 1607.3. Above that, the reference is 1647.3. The trigger line is the reference + 40 ms. Each report states the API size and the level.Tooling:
lantern_flip.mjs(Lighthouse auditor workspace) recomputes Lantern LCP with one request's size changed, from a run saved withLANTERN_DEBUG.Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 26, 2026
Desk rule addendum (perf owner, workspace 8e18f4aada): since #7625 (
0c9a0c0db4) the bundler names the chunkglobals-*.jsinstead ofAPI-*.js. It is the same chunk: resource size 489,040 -> 491,944 B, same request start, same position in the graph. From now on the level check uses that chunk under either name: transfer size <= 132,860 B -> reference 1,607.3 ms, otherwise 1,647.3 ms, trigger at reference + 40. If neither name exists, the level is unknown and the low reference applies. The 132,860 B threshold for the renamed chunk is unproven until a Lantern trace run, since it rests on the same 91-segment boundary.Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 26, 2026
Desk rule change (perf owner, workspace 8e18f4aada). Since #7625 the chunk-size rule (issuecomment-6424990818, addendum issuecomment-6425404821) no longer predicts the level.
Evidence: I reran the auditor's
lantern_flip.mjson a copy of VM cycle 20261026T193404Z run 1 (f446f78738, Lantern trace saved). Simulated desktop LCP:The bump made both Geist font files 11-13 KB larger, so the simulated graph changed and the
globals-*.js(formerAPI-*.js) segment step no longer sets the end of LCP.New rule from now: one desktop reference, 1,647.3 ms, for every cycle; trigger at 1,687.3. A low-level build then needs about +80 ms to fire (the same accepted cost as decision D-A). I re-derive the levels only from a Lantern-traced cycle that lands on the low level.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:highThomasK33 commentedon Oct 27, 2026
Fact for this issue (perf owner, workspace 8e18f4aada). #7661 (
329ee8f3ff, merged without a perf clearance) addsagentInterfaceStatusBar.ts(349 lines) behindAgentInterfaceStatusView, whichChatPane.tsx:74still imports statically. So the code lands on the workspace page's first load.VM cycle 20261027T061246Z against 20261027T020708Z (seeded mobile run 2, transfer sizes): the page chunk
mermaid-LQXJBOYN-*.jsgrew 248,164 -> 251,092 B (+2,928),SandboxedArtifactFrame+162,globals.css+93. Requests stay at 33. Metrics did not move: seeded mobile LCP 1,958 ms (reference 1,958.2), desktop 1,643 ms (trigger 1,687.3).No action now. It adds to the cost of the eager
AgentInterfaceStatusViewimport that this issue tracks. Any fix here must also keep the status bar off the first load, and it must pass the gates in issuecomment-6424990818 (seeded request list plus a VM A/B before merge).Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high