The dangerous implementation is not one that never works. It is one that works in a demo and loses its boundaries under real networks and real data volume. The browser main thread handles input, rendering, timers, and most callbacks. A 300 ms synchronous hash delays controls and heartbeats, creating false disconnects.
Performance work starts with the full interval users wait, then separates CPU, queues, network, and persistence. Compare p95 and p99 with resource cost because averages hide the users most likely to leave.
Engineering boundaries and tradeoffs
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Move CPU work over 50 ms into workers or interruptible slices; prioritize control messages, batch rendering per frame, and carry cancellation signals.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for Controlling Main-Thread Long Tasks in Real-Time Web Apps is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
How it fails in production
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Wrapping a loop in a Promise keeps it in one task, while excessively fine postMessage calls lose gains to cloning and scheduling overhead.
- A boolean failure cannot distinguish retryable, user-action, and permanent refusal, producing an endless loop.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
Turn testing into a closed loop
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Hash a 2 GB file while scrolling activity and running WebRTC heartbeats; measure INP, long tasks, heartbeat jitter, and p95 cancel response.
- Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.