When it makes sense to "block" the main thread: when correct architecture slows your website down

What happened and why it matters

A developer building a Chrome extension called Fastary, which captures screenshots, ran into an unusual problem. Every time, he measured a delay of 2 to 3 seconds, even though he had moved the work to the background, exactly as practically every website performance guide recommends. The finding is surprising and highly relevant for business owners: sometimes moving data to the background is slower than simply doing the work on the browser's main thread.

This matters because the speed of your website hides technical decisions that most owners never see, yet visitors feel them first-hand. A slow, stuttering page means fewer inquiries, more abandoned carts and a worse ranking on Google. That is why it pays to understand what is going on under the hood, even if you are not a developer.

The sacred rule everyone repeats

In web development there is a rule that is supposedly never to be broken: "Never block the main thread." You will find it in almost every performance guide. And it does make sense.

The browser's main thread is single-threaded, which means it can only do one thing at a time. On top of that, it is not ours alone. We share it with the browser's rendering engine, with handling clicks and input, and with other critical jobs. The less time we occupy the main thread, the more responsive the page feels. So we got used to moving heavy tasks to the background, as if there had to be a hard boundary between the user interface and computation that must never be crossed.

That looks like the "recommended" architecture. But the truth is more nuanced: sometimes the very act of moving the work, that is packing, copying and unpacking the data, freezes the page just as much as the work itself.

How the browser isolates its environments

To understand why this happens, let us look at how the browser separates its environments. The browser is not a single environment but several running at once, each with its own memory space and rules:

• The main thread is the one we know best. This is where the logic runs, where the page structure lives, where styles are rendered and where the user clicks.
• Web Workers are separate threads that can run code without access to the page content. We use them for heavy data processing.
• Service Workers are network proxies that intercept network requests and can even run while the page is closed.
• Chrome extension contexts, which include background scripts and so-called Offscreen documents.

Each of these environments is isolated from the others. A background worker lives in a different memory space than the main thread, and they cannot simply read each other's variables. This is called a "share nothing" architecture. For environments to exchange data at all, they have to explicitly send each other messages through interfaces such as `postMessage()`.

The hidden cost of sending data

When you call `postMessage()`, the browser uses the so-called structured clone algorithm. It is similar to the familiar conversion to a text format, only more powerful. It is a deep, recursive copy: the browser walks the entire data structure, clones every value, converts it into a transferable form, sends the bytes to the target environment and reassembles everything there.

For a small piece of data, say the setting "theme: dark", this is imperceptible. The story changes with heavy data, because it is a synchronous, blocking operation whose cost grows linearly with the size of the data. Concretely: if a user clicks a button and an 8 MB image is sent to the background, the main thread must immediately stop everything it is doing and perform that serialization and copying. If packing, sending and unpacking takes longer than simply processing the data on the main thread, there is no point in moving the work to the background.

There are, admittedly, so-called transferable objects, where ownership of the data is handed over without copying, which is extremely fast. According to measurements by Chrome's developers, transferring 32 MB takes under 7 milliseconds, while cloning the same data takes around 300 milliseconds, that is 43 times slower. But this has its downsides: you lose the data after sending it, not everything can be transferred, and Chrome extension interfaces often force everything through classic serialization. In practice this shortcut is frequently not even available.

When the correct architecture is the wrong architecture

The developer of Fastary wanted his extension to work like a native app, instant and smooth. So, following the recommendations, he used an Offscreen document, a hidden document that runs in the background and supports image processing. He sent captured screenshots there, processed them, cropped them and sent them back. On paper, a perfect architecture.

In practice, the capture kept stuttering with that persistent 2 to 3 second delay. The culprit was not the image processing but precisely the moving of the large image data back and forth between environments. The key thought to take away is this:

> The rule is not "never block the main thread" but "never block the main thread for too long."

Before you move work to the background, you have to ask: is this task expensive to process or expensive to move? If moving is more expensive than processing, it is better to leave the work on the main thread. The browser has to render a new frame every 16.6 milliseconds, and a task longer than 50 milliseconds counts as "long". The real art is not blindly following rules but knowing when which rule applies.

What this means for your business and your website

You might think this does not concern you because you are not building Chrome extensions. But the principle is universal and hides inside every fast or slow website.

• Speed is not a single switch you flip. It is a series of decisions about where and how each piece of work is done. The same feature can be lightning fast or painfully slow depending on how it is built under the hood.
• Blindly following "best practices" does not guarantee speed. As this case shows, the recommended architecture can even slow a product down. That is why you need someone who understands why a rule exists, not just that it exists.
• Visitors feel every delay. Three seconds of stutter during an interaction is the difference between a visitor trusting you and leaving for a competitor. And Google measures speed and rewards it with better rankings.

If you run an online store with a product image viewer, a configurator, filters or interactive elements, these are exactly the areas where such hidden costs appear. At Carpolab we do not blindly follow fashionable patterns; we weigh every decision by how your site will actually behave in the hands of a real visitor on a real phone.

If you are curious what a fast, thoughtfully built website or store would cost, you can get a rough estimate in our calculator. And if your site already stutters and you do not know why, get in touch and we will find the cause together.

How Carpolab approaches speed

Our philosophy is simple: speed is not an add-on, it is the foundation. Instead of mechanically moving every task to the background, we ask where the real bottleneck is. Sometimes the solution is precisely to leave the work where it is and avoid the expensive data transfer. The result is a site that responds instantly and gives the visitor the feeling of using a native app rather than a slow web page.

That difference is what separates a website that keeps a visitor from one that loses them.

Frequently asked questions

Is the rule "never block the main thread" wrong?

No, it is a good guideline, but it is not absolute. The more accurate version is "never block the main thread for too long". For some tasks, moving to the background is the smart choice; for others, the cost of moving the data outweighs the benefit. The decision always depends on the specific case.

How do I know whether my website suffers from problems like this?

The signs are stuttering on click, slow opening of image viewers or filters, and a general feeling of "stickiness". Speed measurements, for example with Google's tools, reveal so-called long tasks. If you spot them, it is worth having an expert look under the hood.

Can you improve an existing slow site, or does it need to be rebuilt?

It depends on its condition. In many cases targeted fixes can significantly improve speed without a full rebuild. Sometimes, though, a site is built in a way that makes a fresh build more sensible and cheaper in the long run. Either way, we first find the cause and only then propose a solution.