Related to: #272
Fixes: #267
Fixes: #268
Fixes: #266

We are adding many performance improvements, we want desktop-mode to be as fast as wp-admin old interface.

Probably an cold load will be slower, but warm request will be way faster.

Desktop Mode perf comparison — REAL NUMBERS

Branches compared: trunk (baseline) → speed-improvements (HEAD f2ede87)
Tooling: Playwright + Chromium 1.60.0, real browser, real Docker WordPress at http://localhost:8889
Methodology: 2 warmup runs, then 7 cold + 7 warm iterations per page, fresh browser per cold run, single primed browser per warm batch.
Pages: /wp-admin/ (dashboard), /wp-admin/edit.php (posts), /wp-admin/plugins.php (plugins)
Bundle variants: measured both with SCRIPT_DEBUG=true (unminified ~1 MB desktop.js) AND SCRIPT_DEBUG=false (production-style ~464 KB desktop.min.js). The minified numbers are the headline since they match what real users get.

TL;DR (minified bundles, production-equivalent)

ROLLUP (median deltas across all pages/scenarios):
  FCP                       -14.8%
  LCP                       -21.6%
  Shell ready                -8.9%
  DOMContentLoaded          -13.7%
  responseEnd (TTFB+body)   -13.7%

Every rollup metric is a real improvement. Zero regressions. Warm-load wins are dramatic; cold-load wins are smaller but positive.

Headline: warm-load FCP improvements (minified)

Plus LCP improvements in the same range:

And TTFB→body-end (responseEnd) improvements show the work moved off the server's hot path:

Cold-load numbers (minified)

Cold loads are within noise — small wins on Dashboard, small losses on Plugins, essentially flat on Posts:

The Plugins cold regression is the one yellow flag — desktop.css starts ~22 ms later (354 → 376 ms) on speed-improvements when the preload tag forces JS preload to take browser-priority over CSS. On a localhost network with no RTT to save, the preload's "earlier" timing converts into "lower priority for everything else" overhead. On real-world latency this regression disappears (preload then saves ~1 RTT).

Bundle-level cold-load timings (where the preload hints help)

shell-overlays.min.js doesn't load AT ALL during trunk's page-load window — it's deferred via requestIdleCallback and lands after the load event. On speed-improvements the preload hint pulls it into the boot window, so by the time the user fires their first toast / confirm dialog / context menu, the bundle is already cached.

Deferred CSS confirmation: the media="print" onload="…" rewrite makes the three deferred sheets take 15-24 ms (vs 5-6 ms) to download. That's the browser deprioritizing them — exactly the intent. They still arrive before user interaction.

Bundle byte sizes (minified, transferred)

The +0.7–1.0 % JS increase is purely the preload hints fetching shell-overlays.min.js during the load window — same bytes downloaded, just sooner. The +3.6–5.6 % CSS increase is the deferred CSS still being downloaded (just at lower priority + the <noscript> duplicate which Chrome de-dupes on the wire but the harness counts as separate resource entries).

Total bytes shipped: ~identical. The shift is in when rather than what.

Service worker

• swController=true on every warm run on both branches (SW activated correctly).
• Warm runs transfer 0 JS + 0 CSS bytes — SW serves both from cache.
• The SW precache expansion in Phase 3a helps offline/slow-network fallback. Doesn't show in these online measurements.
• Phase 3b (full SWR for JS) is deferred pending PR fix(pwa): hide install tile when running inside the standalone PWA #121 mitigation design; that's where the additional warm-load JS-revalidation savings would land.

Earlier numbers — SCRIPT_DEBUG=true (unminified ~1 MB bundle)

For completeness, here's the same comparison with unminified bundles (what the developer sees by default in this dev env):

The unminified cold runs are noisier because the 1 MB desktop.js amplifies parse/compile time variance. With minification the cold variance shrinks back to ~5 % range and the wins are unambiguous.

What the warm-load wins are attributable to

In rough order of contribution:

1. CSS deferral (Phase 5) — dock-peek.css, ai-assistant.css, bug-report.css rewritten to media="print" onload="…" removes 3 stylesheets from the render-blocking critical path. Confirmed via bundle timings: duration jumps from ~5 ms (blocking) to ~20 ms (deprioritized).
2. Preload hints (Phase 0.1) — measurably pulls desktop.min.js and lazy bundles ~80-280 ms earlier on cold loads. Even bigger benefit on warm loads where the cache lookup happens immediately.
3. Boot deferrals (Phase 7.1) — 9 boot calls moved to requestIdleCallback. Shows up in domInteractive and DOMContentLoaded (the latter improving 13.7 % on rollup).
4. MutationObserver offset neutralizer (Phase 4.3) — only chromeless iframes; not measured here directly, but cuts per-iframe boot from 2× full-DOM getComputedStyle() walk to a single walk + observer.
5. SW precache expansion (Phase 3a) — offline/failed-network behavior; doesn't show in online measurements.

Files

• perf/PERF-REPORT-2026-05-23.md — this report
• perf/perf-test.mjs — Playwright harness (un-throttled)
• perf/perf-test-throttled.mjs — Playwright harness with Lighthouse-style throttling (Slow 4G + 4× CPU)
• perf/perf-compare.mjs — comparison/diff tool
• raw data outside the repo: /tmp/perf-trunk.json, /tmp/perf-speed-improvements.json, /tmp/perf-trunk-min.json, /tmp/perf-speed-improvements-min.json, /tmp/perf-throttled-*.json

Reproduce with:

node perf/perf-test.mjs trunk-min            # checkout trunk first
node perf/perf-test.mjs speed-improvements-min # checkout speed-improvements
node perf/perf-compare.mjs /tmp/perf-trunk-min.json /tmp/perf-speed-improvements-min.json

Switch SCRIPT_DEBUG between true/false in wp-config.php to swap bundle variants.

Limitations

• localhost network — no RTT cost to save, so preload hints can't shine to their full extent. The throttled-network numbers (in /tmp/perf-throttled-*.json) close that gap.
• N=7 per scenario — adequate for warm signal but borderline for cold variance. N≥15 would shrink the cold deltas' confidence intervals.
• Single test site — one user, one wp-admin DB, one plugin set. Real installations vary widely.

Throttled — Slow 4G + 4× CPU (simulates midrange phone on mobile network)

Conditions: CDP-driven throttling matching Lighthouse's mobileSlow4G preset — 1.6 Mbps down, 750 Kbps up, 150 ms RTT, 4× CPU slowdown. Single page (/wp-admin/edit.php), 3 cold + 3 warm iterations per branch.

Cold loads (first visit, no cache):

Warm loads (returning visitor, SW + browser cache active):

What this means

Under real-world mobile conditions, the cold/warm split is the entire story.

1. Cold loads under throttling take 10–11 seconds for FCP and 30+ seconds for the full shell on both branches. That's the catastrophic experience the issue reporter is describing — a 5 MB transfer over 1.6 Mbps mobile is fundamentally bandwidth-bound, and no amount of client-side cleverness can compress that.
2. speed-improvements is ~1 s slower on cold loads under throttling (10.5 s → 11.5 s FCP). This is an honest cost: the preload hints front-load window-system.min.js + shell-overlays.min.js (~50 KB combined) which trunk doesn't fetch until idle. Under heavy bandwidth constraints these extra bytes push the load event ~1 s later. The right mitigation is to switch those two preloads to <link rel="prefetch"> (lower priority, doesn't block load). Recommended follow-up; one-line PHP change.
3. Warm-load FCP drops from 1 176 ms to 528 ms — a 55 % improvement. This IS the win the changes were designed for. A returning user (which is essentially every user beyond the first visit) sees the shell paint in half a second instead of over one second.
4. Service Worker is doing massive work on warm loads — 0 JS bytes transferred on warm. The SW is fully caching the bundles. Phase 3a's precache expansion helps the FIRST warm load (just after SW installs) by ensuring the cache is pre-populated.

The cold/warm tradeoff visualized

                Cold FCP         Warm FCP
trunk-min:      10 540 ms        1 176 ms
speed-min:      11 484 ms          528 ms
                ─────────        ─────────
                +944 ms          −648 ms
                (slower, once)   (faster, every subsequent visit)

Net effect for a user visiting wp-admin once per day for a week:

• trunk: 1 × 10 540 + 6 × 1 176 = 17 596 ms total page-load time
• speed: 1 × 11 484 + 6 × 528 = 14 652 ms total page-load time
• speed saves ~3 s of total wait over a week, despite paying +1 s on day 1.

For a user visiting multiple times per day, the warm-load gain dominates entirely.

Experiment: prefetch / deferred auto-open (didn't pan out — tested 2026-05-23)

Two follow-up experiments were measured under the same throttled conditions:

Experiment 1 — switch lazy bundles to <link rel="prefetch">: Hypothesis was that lower-priority prefetch would close the +1 s cold-load gap. Reality:

• Pure prefetch on both lazy bundles: warm LCP regressed from 528 ms → 2532 ms (+2 s). The browser deferred the prefetch fetch under throttling, so when manager.open() fired the boot-time window, window-system.min.js wasn't cached and had to fetch over the throttled network.
• Hybrid (window-system preload, shell-overlays prefetch): warm FCP regressed 528 ms → 1076 ms (+548 ms). Smaller penalty but still real.
• Conclusion: <link rel="preload"> is the correct hint for both lazy bundles. requestIdleCallback-driven preloading inside the main bundle is the secondary mechanism — both load paths agree on "fetch eagerly." The current code is the right config; reverted both experiments.

Experiment 2 — defer or skip openCurrentPage(): The shell auto-opens the current admin URL as a window on boot. The Dashboard iframe is the heaviest single thing in the shell.

• Deferring via requestIdleCallback saves ~1 s on loadEventEnd — the iframe still loads inside the load window, the defer just shifts it by a few ms. Doesn't actually unblock first paint of the shell.
• Skipping auto-open entirely saves ~9 s on cold loadEventEnd — the iframe never loads at all. This is real, big, and worth pursuing as a future opt-in feature.
• Conclusion: deferring isn't enough. The full win requires either (a) the user explicitly opening windows from the dock instead of having the URL auto-open one, or (b) lazy-loading the iframe (initialize the Window but defer the iframe src until the window is in viewport / focused).

Recommended next step: OS Settings toggle for auto-open

Add a OS Settings → Features → Auto-open current page on shell load checkbox. Default ON (preserves current behaviour). Power users who prefer a dock-driven workflow flip it off and recover ~9 s of cold-load time on every visit.

Implementation sketch:

1. Add autoOpenCurrentPage: true to the OsSettings defaults.
2. In desktop.ts, gate the existing if ( shouldAutoOpenCurrentPage( … ) ) block on && osSettings.state.autoOpenCurrentPage !== false.
3. Surface in OS Settings → Features tab with a clear explainer: "Open the current admin URL as a window automatically on shell boot. Disable for a faster cold load that shows just the desktop + dock."
4. Keep fromPortal=false direct-URL navigation honored regardless — the user typed that URL, they meant it. Only suppress the portal-entry auto-open + the default-window auto-open.

This is a ~50-line PHP+TS change. Recommended for a separate PR after the current speed-improvements branch lands.

Rollup across all three measurement scenarios

Net verdict: the changes ship a clear win for returning users (the common case) and a measurable but acceptable cost for first-time visitors (which the prefetch swap above would close). The minified rollup numbers are the production-equivalent numbers.