Separate experiment

Show content now.
Attach behavior next.

Every version starts with an empty HTML shell. A JavaScript render chunk creates the useful page, then a separate interaction layer attaches inline editing and the full editor.

Read the full write-up: Bundle for Perceived Performance, Not Just Size ↗

An inline edit is attempted 150 ms after JS-rendered content appears. The click is queued until handlers exist.
Content delivery Rendered by JavaScript
Fastest content improvement Run the race
Interaction trade-off Measured automatically
Actual production output

Same editing features, three activation strategies

The HTML shell is identical. JavaScript controls when content renders and when inline events and advanced tools become available.

Progressive activation race

Watch usefulness arrive in layers

Content paint, inline readiness, early-click delay, and full tools are measured independently.

01

Monolithic activation

Rendering, inline events, and the full editor all wait for one large application bundle.

02

Parallel split activation

The render and interaction chunks start together. The smaller render chunk can display the page while behavior keeps loading.

03

Post-render activation

The render chunk displays the page first. Only then does the browser request the interaction and editor chunk.

Methodology

Same throttling and cold-cache rules as the read-then-edit lab

This experiment reuses the same server: fixed RTT latency, a per-profile bandwidth limiter, and a fresh no-store run ID for every load. Each build card also has a Throttled link and a Raw (unthrottled, DevTools-controlled) link for manual profiling.

See the full methodology on the read-then-edit lab for the exact network profiles, build invariants, and what read-ready-style marks do and do not measure. For the measured write-up with traces, see Bundle for Perceived Performance, Not Just Size ↗.