Trigger

DebugBear weekly report (13–19 Jul): Worldmonitor – Pro (Mobile) lab Performance score 63 (−14), FCP 3.38s (+381ms), LCP 4.38s (+491ms) — the worst movers in the project. Countries (Mobile) and Countries UK (Mobile) also +343–380ms FCP in the same window.

Investigation (2026-07-21)

1. The delta was mostly a transient, cross-page elevation — not a Pro code change.

• Three unrelated pages regressed together by ~+350–400ms → shared cause, not page code.
• RUM confirms a ~3-day elevation on 07-17..19 across surfaces: /pro mobile FCP p75 1034→1336/1514/1532 (07-15 vs 17/18/19), desktop 908→1320; /dashboard desktop TTFB p75 230 (07-09) → 340-400 (07-17..19). Largely recovered 07-20 (/pro mobile FCP 1005, desktop 668 — best of the month; dashboard TTFB back to 339).
• The only public/pro change in the window (fix(checkout): retry transient create-checkout failures once with an Idempotency-Key (WORLDMONITOR-Q4) #5374, 07-18) rotated one 87KB chunk hash — cannot explain the delta.
• Suspect for the transient window: edge/server-side (the KV/Worker serving rollout U-K4 feat(bootstrap): serve public tier from KV via the Worker (U-K4, #5338) #5357 merged 07-17, or platform variance) — flagging as an observation, not a finding.

2. The durable problem: Pro (Mobile) absolute lab numbers are poor regardless of the delta.

• public/pro/assets totals 4.8MB; the critical path is ~625KB: entry index-*.js 87KB + modulepreloaded 406KB index-D0F7eEoT.js + 87KB sentry chunk + 45KB CSS. On the 4×-CPU/150ms-RTT lab profile that yields FCP 3.4s / LCP 4.4s.
• Clerk is a 3.0MB chunk (clerk-*.js), dynamically imported from the entry after window.load + setTimeout(0) (verified in the minified bundle: .addEventListener("load",()=>setTimeout(a,0),{once:!0}) gating the loader). It does not block FCP/LCP, but its ~3MB fetch+parse lands inside the lab trace window → the CPU/TBT hit behind the score of 63.
• RUM for /pro is passable (mobile LCP p75 1.4–2.1s, n≈130-370/day) — this is a slow-device-tail and lab-score problem today, but the 3MB post-load parse is real CPU on real low-end phones.

Proposed work (in impact order)

1. Defer Clerk to intent — load the 3MB chunk on sign-in/账户 UI interaction (or at least requestIdleCallback with a long timeout), not unconditionally post-load. Expected: lab mobile CPU/TBT/score recover; zero UX change for anonymous visitors (the majority).
2. Audit the 406KB modulepreloaded chunk — what's in index-D0F7eEoT.js and does the landing view need all of it pre-FCP? Splitting it off the preload list directly moves lab FCP/LCP at 4× throttle.
3. Re-check the weekly report after a clean week to confirm the 07-17..19 elevation was transient (if it recurs, investigate the edge/Worker serving path timing separately).

Baselines for acceptance: lab Pro (Mobile) score 63 / FCP 3.38s / LCP 4.38s; RUM /pro mobile FCP p75 ~1.0-1.5s.