perf(mobile): post-hydration chunk wave causes 20 long tasks / 9.5s TBT (#4487)

[koala73]

Problem

Mobile production lab analysis has a distinct post-hydration main-thread congestion wave that is not owned by the existing interaction-specific INP work. DebugBear analysis 83261112 (UK mobile, 4x CPU throttle, 2026-07-10 07:03 UTC) reports:

• Comparison regression: Fetch +396 KB, request count +25, JavaScript execution +5,076 ms.
• 20 long tasks, total blocking time 9,532 ms, and time-to-interactive 35,281 ms.
• Worst tasks: products chunk 1,498 ms at 27.4 s; main 1,108 ms at 21.4 s; main 804 ms at 29.3 s; widget-store 610 ms at 26.4 s; RSS chunk 610 ms at 19.7 s.

This is post-load work. It may contribute to field INP input delay, but this trace does not attribute it to a user interaction and must not be represented as an INP root cause without RUM correlation.

Waterfall evidence

The trace has 315 requests: 187 fetches (1.97 MB) and 101 scripts (1.19 MB). Two late waves align with the long tasks:

1. At 19.0-22.5 s, three rss-proxy responses (34 KB, 22 KB, 13 KB) and RPC-client chunks overlap the 610 ms RSS task.
2. At 26.0-31.5 s, deferred panel chunks overlap the 1,498 ms products and subsequent main tasks: panels-markets (36 KB), panels-economy (36 KB), panels-risk (31 KB), panels-energy (26 KB), and panels-defense (21 KB), followed by font fetches.

The DebugBear waterfall has request timing and bytes but no initiator stack, so the alignment is evidence for profiling, not proof that any one fetch causes the task. Sentry begins after 17 s; that preserves the closed #4417 audit-window acceptance and is only a contributing late-execution candidate here.

Scope

• Parent: perf: Core Web Vitals FAILED in field (LCP 4.8s/INP 870ms mobile) — prioritized fix #4487.
• Related: perf(INP): own INP as an interaction problem (field 374ms desktop / 870ms mobile) — instrument + chunk hot handlers, not folded into the boot-split (#4487) #4537 (main-thread congestion / INP), but distinct from perf(INP/mobile): map-tap presentation delay owns mobile INP — p75 799ms, 30% good, flat 3 weeks while desktop improves (#4487 Track M) #5080 mobile map-tap presentation delay.
• Profile hydration scheduling and dynamic-import execution before changing defer boundaries. Do not regress the now-passing mobile LCP path.

Acceptance

• Attribute the top post-hydration long tasks to code paths with a reproducible performance trace.
• Split or schedule the confirmed work so no task in this wave exceeds 50 ms on the representative mobile profile.
• Re-run the same mobile DebugBear profile and record TBT, long-task count, request count, and LCP/FCP trade-offs.
• Check field/RUM INP input-delay trends separately; a lab trace alone is not field-INP proof.

[koala73]

2026-07-10 validation — request-level diff of the two runs splits this issue in two

Diffed analysis/83162056 (07-09, TBT 3,672ms) vs analysis/83261112 (07-10, TBT 9,532ms) via the requests API:

1. The +396KB / +25 requests are ATTRIBUTED — and they're not JavaScript. ~15 new nunito-*.woff2 files (~250KB) + the DebugBear RUM script (14KB, expected, PR #5089) + hash-rotated same-size assets. The Nunito files are resourceType: "fetch" — they're service-worker precache installs (vite.config.ts:1013 globs **/*.woff2), not page font loads; both runs show the SW install wave, but 07-10's manifest carries 15 more woff2 (11→26). Cause: #5089's happy-theme.css static→dynamic split changed how the @fontsource Nunito assets enter the precache manifest. Same bug class as #4891/PR #4899 (SW precache sweeping deploy-generated assets). Concrete fix candidate: exclude font files from globPatterns and let them runtime-cache on first real use (fonts are variant-gated at runtime via secondary-startup.ts; precaching all variants' fonts taxes every install). Bounded cost: ~250KB bandwidth per SW install — it does NOT execute, so it cannot explain the TBT spike.

2. The +5,076ms JS execution / 20 long tasks are NOT explained by any code change — script requests are byte-identical between the runs (main, widget-store, rss, panel chunks: same hashes-modulo-rotation, same sizes). The long-task wave at 19–31.5s is the designed lazy-panel tail, present in both runs; what changed is how long the same work took (news-cycle data volume and/or 4×-throttle run variance — prior 4 runs ranged TBT 3.7–5.1s). Treat the 9.5s as unconfirmed until the 07-11 daily run: if it reverts to ~4s, the regression framing drops and this issue is purely the (real, pre-existing) "chunk the post-hydration wave to ≤50ms tasks" work. If it repeats, bisect the 07-09 merge batch.

The measure-first acceptance in this issue is exactly right — adding: capture the next daily run's TBT before investing in the scheduling work.

[koala73]

2026-07-11 arbitration — prediction CONFIRMED; the "regression" was the SW font-precache window artifact, now fixed

Manually triggered lab runs post-#5173 (woff2 precache trim), analyses 83325177 (mobile) / 83325178 (desktop):

Mobile 4×	Jul 9 (pre-batch)	Jul 10 (spike)	Now (post-#5173)
TTI	29,422	35,281	29,812 ✓
TBT	3,672	9,532	4,144 ✓
JS execution	5,483	10,559	6,118 ✓

Exactly as the request-diff analysis predicted: the Jul-10 spike was the enlarged SW precache wave (+15 Nunito woff2) extending the network-busy period → TTI +5.9s → the TBT/JS counting windows swallowed the always-present lazy tail. Same chunks, same schedule, no code regression — and with the fonts out of the precache manifest, the window snapped back.

This issue's remaining scope is therefore the pre-existing post-hydration chunk wave (20 long tasks in the 19–31s band — real, by-design lazy-tail work worth chunking to ≤50ms tasks per the acceptance), NOT a regression hunt. The wm:panel:deferred-mount-* marks from #5173 are now in the lab timeline for attributing it.

[koala73]

Variance check closing the residual question (3 manual mobile runs post-#5173: analyses 83325177/83325223/83325224):

Mobile 4×	pre-spike band (Jul 7–9)	post-#5173 ×3
TBT	3,672–5,127 (mean ~4,453)	3,727/4,144/4,173 (mean 4,015)
JS execution	5,483–6,517 (mean ~6,141)	5,664/6,042/6,118 (mean 5,941)
styleLayout	1,709–2,743 (mean ~2,190)	2,122/2,444/2,478 (mean 2,348)

Post-fix runs straddle the pre-spike band on every metric (TBT mean slightly better). The apparent "+0.5s vs Jul 9" was distance-to-the-band-floor, not a residual — Jul 9 was the week's best single run. No regression remains; this issue's scope is the pre-existing lazy-tail chunking (attribute via the wm:panel:deferred-mount-* marks, ≤50ms task acceptance).

[koala73]

2026-07-11 — long-task wave ATTRIBUTED (acceptance step 1 done)

Correlated the LHR long-tasks audit from post-#5173 run 83325177 with the wm:hydration:* / deferred-mount marks (#5173):

hydration phase (marks)	long tasks inside it
tier-1: 11→18s	rss-*.js 483ms@17s · main-*.js 629ms@18s
tier-2: 18→20s	sentry-*.js 165ms@19s
tier-4: 20→21s	widget-store-*.js 353ms@21S
second viewport cycle starting @21S	products-*.js 791ms@22s · main-*.js 431ms@23s · dashboard 173ms@22s

Bootup-by-script confirms the owners: main 1,421ms script, rss 1,172ms, products 1,047ms, widget-store 548ms. The wave = the tiered hydration scheduler executing each tier's panel work monolithically, plus a second viewport-triggered cycle at ~21s re-running tiers.

Fix design (acceptance step 2): yield between panels within a tier (scheduler.yield / isInputPending in the tier executor), and split the three biggest single bites — products (791ms), rss parse (483ms), widget-store (353ms) — so no task exceeds 50ms at 4×. Also worth checking why a second viewport hydration cycle fires at 21s (marks show viewport:start twice).

Sequencing: implementation can start now; recommend merging AFTER the #5202 soak read (~07-13) — chunking reduces INP input-delay collisions on the same mobile page, and a clean window keeps slice-2's presentation-axis attribution unambiguous. Local caveat: the wave under-reproduces on fast dev hardware (max 351ms tasks) — verify on DebugBear mobile (trigger via POST /api/v1/page/693057/analyze).

[koala73]

2026-07-11 post-#5220 arbitration (3 triggered mobile runs) — targets moved, wave NOT reduced; ≤50ms acceptance NOT met

Mobile 4×	pre-#5220 (n=3, this morning)	post-#5220 (n=3)
TBT	3,727 / 4,144 / 4,173 (mean 4,015)	7,404 / 3,979 / 6,689 (mean 6,024, huge spread)
TTI	29.8 / 30.5 / 32.5s	35.3 / 32.2 / 35.3s
JS execution	5,664–6,118	6,405–9,497

What worked (structural, verified in the LHR): the attributed targets are gone from the wave — no products task (was 791ms), no rss task (was 483ms), widget-store shrank to 176ms@5s. The PR did what it said.

What didn't: the wave persists with reshuffled owners — persistent-cache-*.js 1,123ms@28s (new name; likely inheriting the late cache-write burst that used to attribute to products), main 917/909ms, widget-sanitizer 555ms@26s (the deferred chunk now evaluates inside the wave — CustomWidgetPanel/McpDataPanel pull it at mount; cost relocated, not removed), dom-utils 524ms. And the added yields appear to stretch the activity tail: TTI +3–5s consistently, which widens the TBT counting window — the same window mechanics as the 07-10 font-precache episode, this time self-inflicted. Mean TBT is worse though the spread (4.0–7.4k) overlaps the old band, so "regression" isn't provable either; one run sat exactly in-band.

Why the tier yields couldn't hit ≤50ms: the yield boundaries sit BETWEEN loaders, but the remaining long tasks are single monolithic bodies (module evaluation + synchronous setup of big chunks) — a yield can't split a chunk's eval. Getting under 50ms needs smaller chunks or idle-scheduled imports for the named owners, not more boundaries.

Recommendation — cap further lab-TBT investment here pending field data. This issue's own framing was right from day one: "may contribute to field INP input delay… must not be represented as INP root cause without RUM correlation." Mobile input delay is the minor sub-part in the field (227ms bad-tail p75), and the fixes that moved actual field metrics this week were all elsewhere. Next scheduled check (July 13 pass): Sentry mobile INP inputDelay sub-part + DebugBear selector p75s post-#5220 — if input delay improved or held, the wave work has hit diminishing returns vs. e.g. the first-visit LCP slice; if it regressed, revisit with the named owners above (persistent-cache write batching, sanitizer/McpData mount scheduling, splitting the main-chunk wave bodies).

Issue stays open with acceptance unmet; the double-viewport-cycle follow-up also remains.

[koala73]

2026-07-12 correction — yesterday's "TBT worse" read was deploy-adjacency; clean-window post-#5220 is IN-BAND

The daily-schedule timeline exposes the confound: a 7,794ms TBT run existed at 07-11 07:04, BEFORE #5220 merged (13:52Z) — every run within ~2h of any deploy reads 6.7–7.8k (SW re-precaching rotated assets on the cold lab profile extends the TTI window), across three separate deploy events now. The clean-window runs tell the real story:

clean runs (≥5h post-deploy)	TBT	TTI	JS
07-11 03:36–03:43 (pre-#5220, ×3)	3,727–4,173	29.8–32.5s	5.7–6.1k
07-11 19:08 (post-#5220)	3,632	30.9s	5,728
desktop 19:09 (post-#5220)	1,553 — best in series	8,990 — best	2,998

So: no TBT regression from #5220 — retract yesterday's "mean 6.0k vs 4.0k" framing. The wave in the clean run is also smaller than the adjacent-window read suggested, with the same owners at lower magnitudes: persistent-cache 774ms, main 549/458, widget-sanitizer 313, dom-utils 376. The ≤50ms acceptance remains unmet, and the cap-pending-field-data recommendation stands — next lever, if field input-delay says it's worth it: the monolithic chunk-eval bodies (persistent-cache burst batching, sanitizer mount scheduling).

Process rule now in force for this page: never arbitrate on a lab run within ~2–3h of a deploy; n≥3 clean-window runs.