perf(pro): Pro Mobile lab score 63 — 3MB post-load Clerk parse + 406KB preloaded chunk; weekly-report delta was mostly a transient 07-17..19 cross-page elevation

## 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 (#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 #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.

Start by inspecting the generated files in public/pro/assets, especially the entry index-*.js, the 3MB clerk-*.js chunk, and the 406KB index-D0F7eEoT.js modulepreload. Reproduce the Pro Mobile lab baseline and trace when Clerk loads and what the preloaded chunk contains. Done means the unnecessary work is deferred or split and the lab score, FCP, and LCP improve against the stated baselines without changing anonymous-user behavior.

Written by the indexing model from the issue text.