When it makes sense to block the main thread (Smashing Magazine)

A Smashing Magazine piece by Victor Ayomipo that pushes back on one of front-end performance’s firmest rules. The received wisdom is “never block the main thread”; Ayomipo’s revision is “never block it for too long.” Sometimes the cost of shipping work off to a background thread — serialize, transfer, deserialize — is larger than just doing the work on the main thread in the first place.

The argument

Isolated browser contexts (Web Workers, service workers, extension background/offscreen documents) are shared-nothing: they can’t touch each other’s memory, so they talk through postMessage(). And postMessage copies its payload with the Structured Clone Algorithm — a synchronous, blocking, O(n) deep copy. For a megabytes-large payload (say a screenshot’s pixel data), that clone can cost more than the actual processing you were trying to offload. So moving work off the main thread doesn’t remove main-thread cost; it can add it, on both ends of the message.

The escape hatch is transferable objects (ArrayBuffer, ImageBitmap, MessagePort), which hand over ownership of the memory instead of copying it — near zero-copy. Ayomipo cites Chrome’s own benchmark: a 32 MB transfer in 7 ms vs ~300 ms to clone the same data, roughly a 43× speedup. But transferables come with strings: the sender loses access to the object after handoff, only a few types qualify, and some contexts (Chrome extension messaging) force JSON serialization anyway, which rules transferables out entirely.

The worked example

The trigger for the piece was Ayomipo’s own Fastary screenshot extension, which showed 2–3 seconds of latency even though it followed the recommended Offscreen Document architecture. Profiling showed the work wasn’t the bottleneck: a screenshot is a 1 MB+ base64 string, doubled or tripled on Retina displays (devicePixelRatio 2–3), and it was being JSON-serialized across multiple round trips (background → offscreen → background → content script). The actual image crop took ~50 ms; the serialization dwarfed it. The fix was to stop offloading: do the image processing directly in the active tab’s content script (the main thread), which killed the serialization overhead and, as a bonus, fixed a DPI coordinate-mapping bug (Offscreen Documents default to devicePixelRatio 1, so coordinates had to be scaled by hand).

The decision framework

Ayomipo splits work into two kinds:

• CPU-bound — computation dominates (image compression, physics, parsing). Offload it. Transfer cost is negligible next to the processing time, so a worker keeps the main thread free.
• Data-bound — the payload dominates and the processing is light (cropping, filtering, a shallow copy). Keep it on the main thread. Offloading loses, because transfer overhead exceeds the work.

The rule of thumb is a cost equation:

Total = Serialization + Transit + Background Processing + Deserialization

Offloading only wins when background processing time vastly exceeds the combined transfer costs. Measure it empirically with performance.mark() / performance.measure() rather than assuming. And the whole thing is bounded by the “for too long” clause: blocking for ~1 second is defensible on an explicitly user-invoked action that needs an immediate result (a paint the user just asked for), where the frame budget matters less than shipping the answer now.

Why it matters here

This is the spoke’s first source squarely on the main-thread execution axis the synthesis had flagged — the “executing less” half of web-performance, where inp and Total Blocking Time live but no concept page existed. It also complicates the thesis: the wiki’s instinct is “less is faster,” and offloading work off the main thread looks like a pure win, but Ayomipo shows the transfer boundary has its own cost, so the right move is sometimes to keep blocking work on the thread. That parallels the delivery-side lesson already in synthesis — equal-byte pages differ on executed cost — now applied to where computation runs.

Source: Smashing Magazine, Victor Ayomipo, 17 July 2026 — smashingmagazine.com. T2 — a reputable independent front-end publication; a practitioner deep-dive with concrete (Chrome-sourced) benchmark figures, but an engineering argument rather than a standard or primary dataset.