Worker vs iframe postMessage benchmark

Each target receives a cloned payload, runs identical CPU-bound work, and replies with a similar-sized payload. One message in flight per target (round-trip gated, like the project engine). compute is measured inside the target; overhead = round-trip − compute, i.e. the transport cost.

Targets
Job
Main-thread load (simulates map/React rendering in the parent) 0 = idle. 8 ≈ half-loaded at 60fps, 16+ ≈ saturated. A rAF loop busy-waits this long every frame while the benchmark runs; achieved FPS is reported.

Hypothesis being tested: Chrome ≥127 puts sandboxed (no allow-same-origin) iframes in their own renderer process (IsolateSandboxedIframes). A process with no visible frames is backgrounded; on macOS that maps to background QoS → efficiency cores → slower compute. Predicted: hidden-iframe compute ≈ 2× worker compute, 1px-iframe compute ≈ worker compute. If instead overhead dominates, it's the cross-process postMessage hop. Set work iterations to 0 for a pure transport (ping-pong) test.

Caveats: Chromium may co-locate the two sandboxed iframes in one process — for a clean hidden-iframe reading, Reset and run it alone. Confirm process placement in Chrome's Task Manager (separate “Subframe” rows) or chrome://process-internals/#web-contents. Cross-check with relaunch flags: --disable-renderer-backgrounding (priority) and --disable-features=IsolateSandboxedIframes (process isolation).