docs/solutions/performance-issues/2026-04-01-side-by-side-editor-demos-should-support-single-engine-mount-for-honest-metrics.md
A side-by-side editor demo is fine for eyeballing behavior, but it is a bad default measurement surface. Mounting both editors at once adds extra DOM, layout, and page-level work that can make one engine look slower than it is.
The Huge Document docs page was doing exactly that: it rendered Plate and Slate next to each other, then showed timing stats as if those numbers were clean per-engine measurements.
Plate + Slate mode reporting a visible slowdown in one run:
10 ms21 ms73 msSlate only mode dropped back to the near-zero /
non-reporting class, which is where standalone Slate also tended to land
under automation.Treating the side-by-side view as both demo and benchmark surface was the mistake. The numbers looked comparable, but the page itself was part of the overhead.
Copying the local .tmp/slate-v2 transform-benchmark controls into the docs page
would have made this worse. That work belongs in a dedicated benchmark harness,
not in a public example page.
Add a Mounted editors control with:
Plate + SlatePlate onlySlate onlyKeep Plate + Slate as the parity/demo view, but make single-engine mount the
obvious truth mode for anyone looking at timing stats.
Also add an explicit note in the stats panel:
Mount one editor at a time for cleaner engine-specific numbers. The two-editor view is useful for eyeballing parity, not for honest perf baselines.
The control separates two jobs that were previously mixed together:
That keeps the docs page useful for both audiences without pretending the two-editor layout is a neutral measurement surface.
/dev/editor-perf for transform and
mount investigations.