Repository navigation
🤖 perf: seeded workspace page mobile Lighthouse 93 -> 70 since #7625 (static view no longer the final LCP) #7637
Description
Summary
Since #7625 (dependency bump, merged as 0c9a0c0db4), the seeded workspace page scores 69-70 in mobile Lighthouse on the perf VM. On the previous commit (6959dfc263) it scored 89-94. Desktop is unchanged.
Evidence (VM cycles, read from the run folders)
| Cycle | Commit | Mobile score | Simulated LCP | Observed LCP | TBT |
|---|---|---|---|---|---|
| 20261026T190454Z | 6959dfc | 89 / 94 / 93 | 1959 / 1958 / 1957 ms | 86 ms | 399 / 269 / 280 |
| 20261026T192035Z | 0c9a0c0 | 69 / 70 / 70 | 8581 / 8571 / 8559 ms | 503 ms | 284 / 265 / 251 |
- The LCP element is the same in both: the code line of the seeded transcript (
div.code-block-container > div.code-line). - Before 🤖 fix: bump effect to stable 4.0.4 and dependencies within range #7625, the static workspace view (🤖 perf: inject the static workspace view on a phone's workspace page #6880) painted that line at first paint, and the live app did not record a later LCP entry. Now a later LCP entry appears at ~500 ms, when the live app replaces the static view. Lighthouse then simulates LCP at the end of the JS load (8.5 s, equal to TTI).
- The HTML document is unchanged (9,986 vs 9,991 B). The request count is unchanged (33).
- Font files grew:
Geist-Variable58,858 -> 69,839 B,GeistMono-Variable58,438 -> 71,583 B.
Suspects (not verified)
geist1.5.1 -> 1.8.1: new font metrics can change the live code line's box size, so it no longer matches the static copy.tailwindcss/@tailwindcss/vite4.1 -> 4.3: changed utility output can do the same.
Next step
The perf owner is bisecting this with an LCP-entry check in headless Chromium (count of largest-contentful-paint entries after the static view, mobile emulation). The fix must bring the seeded mobile observed LCP back to the static view's first paint and VM seeded mobile back to >= 90.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
Activity
ThomasK33 commentedon Oct 26, 2026
Correction from the perf owner (workspace 8e18f4aada), read from the run folders. The issue body gave the observed LCP of run 2 only. Per run (observed FCP / observed LCP, ms):
6959dfc263)0c9a0c0db4)So a later LCP entry by itself is not the full cause: run 1 before #7625 had one at 406 ms and still simulated at 1,959 ms. The bisect must also compare which node Lighthouse picks as the LCP node (the auditor reports the live
code-linenode, 312x38, in all 3 runs after #7625, and a detached static node before).Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high🤖 fix: keep Geist Mono's 1.5.1 vertical metrics so the phone static v…