Web workers for performance

Can the reviews be read somewhere else?

Lesson 27.3 left Ravi's tea list in good shape. reviews.js reads this week's 4,000 reviews in pieces of 10 ms. It rates the six teas on Asha's screen first. Her clicks get in between the pieces.

Then Ravi opens the trace. The work is cut up, but all of it is still there. It still runs on the main thread: the one thread that runs the page's JavaScript, answers clicks and draws the screen. Each picture it draws is a frame. While the pieces ran, Chrome drew only 10 frames.

Meera has plans for more, like a chart of the reviews. So Ravi asks a new question. Does this work have to run on the main thread at all? Could it run somewhere else, and leave the main thread free?

It can. A web worker is a second thread that a page starts for its own JavaScript. Lesson 6.1 moved a photo filter into one, and a tap stopped waiting. This lesson moves reviews.js's work into a worker. Here is what changed on Asha's phone:

1// Asha's phone, while the reviews were read: each thread's busy time in ms, and the frames drawn.2const pages = [3  { name: "10 ms pieces", mainThread: 657.6, worker: 0, frames: 10 },4  { name: "A worker", mainThread: 91.2, worker: 410.4, frames: 23 },5];6for (const page of pages) {7  console.log(`${page.name}: main thread ${page.mainThread} ms, worker ${page.worker} ms, ${page.frames} frames`);8}

• Line 1 is a comment. Busy times are in milliseconds (ms). A millisecond is a thousandth of a second.
• Lines 3 and 4 hold two versions of the page. mainThread is how long the main thread was busy while the reviews were read. worker is how long the worker was busy. frames counts the frames Chrome showed.
• Line 7 prints 10 ms pieces: main thread 657.6 ms, worker 0 ms, 10 frames. Then it prints A worker: main thread 91.2 ms, worker 410.4 ms, 23 frames.

The work didn't vanish. It moved: 410.4 ms of it ran in the worker. The main thread's share fell from 657.6 ms to 91.2 ms. And Chrome drew more than twice as many frames. Asha clicked Add on Mint tea while the reviews were read. These are real frames Chrome captured:

With the 10 ms pieces, the frame on her screen was 53.2 ms old when she clicked. Cart: 1 appeared 51.2 ms after her click. With the worker, the frame was 10.8 ms old, and Cart: 1 came after 36.7 ms. Why it matters: a main thread with fewer jobs gets to each frame and each click sooner.

The JavaScript lessons Web Workers, How workers work and Parallel patterns with workers teach the Worker API, what happens inside, and patterns like pools. This lesson measures what a worker does for speed, in five steps:

1. What can move to a worker, and what moving saves.
2. What a message costs, copied or transferred.
3. Comlink, which makes a worker look like a set of functions.
4. OffscreenCanvas, which lets a worker draw on the page.
5. Shared memory, and the isolated page it needs.

How the course recorded it

• Six pages: lesson 27.3's tea list with its 10 ms pieces, three pages with a worker, and two pages that draw a chart. A lab page measured messages on its own. A local server sent them all over HTTPS.
• Asha's phone: this computer in Chrome 157, with its processor, the CPU, slowed 4 times. The server held this week's reviews back 1 second, as in lesson 27.3.
• The worker's speed: DevTools can slow the page's main thread, but not a worker. So most worker pages do each piece of work 4 times over, to stand in for Asha's phone. One runs at this computer's full speed. The next section checks how close the stand-in comes.
• Loads: each page loaded three times, taking turns. Each time, Chrome kept a trace: a detailed record of everything it did, with screenshots. The lesson quotes the middle load.
• Clicks: in every load, Asha clicks Add on Mint tea 150 ms after the reviews arrive. The click is a mouse press and release sent through Chrome's DevTools protocol. Chrome passes it straight to the page.

What can move to a worker

A worker has its own thread and its own global variables. It has no page. There's no document in a worker, so it can't read or change the DOM. web.dev lists more it can't reach, like WebUSB, WebRTC and Web Audio. What it can do is work on data: numbers, text and lists.

Lesson 24.2 showed one way around the missing page. Partytown ran third-party tags in a worker, and carried their questions about the page to the main thread. Ravi's own code is simpler to move. He splits reviews.js in two. The page keeps the jobs that need the page:

1// reviews.js: hands this week's reviews to a worker, and shows each rating it sends back.2const about = document.querySelector("#about");3const onScreen = (tea) => document.querySelector(`[data-tea="${tea.id}"]`).getBoundingClientRect().top < innerHeight;4const worker = new Worker("rate-worker.js");5worker.postMessage([...TEAS.filter(onScreen), ...TEAS.filter((tea) => !onScreen(tea))]);6worker.onmessage = (event) => {7  const { id, rating, read } = event.data;8  document.querySelector(`[data-tea="${id}"] .stars`).textContent = "★ " + rating;9  about.textContent = "Reviews read: " + read + " of 4000";10};

• Line 3 checks which teas are on screen. It reads the page's layout, so it stays on the main thread.
• Line 4 starts the worker. new Worker() runs rate-worker.js on a thread of its own.
• Line 5 sends the teas, the screen's six first. postMessage() sends one message: here, the whole list.
• Lines 6 to 10 run each time the worker sends a message back. Line 8 writes the tea's rating into its row. Line 9 updates the reviews line. Changing the DOM stays on the main thread too.

The worker gets the heavy part:

1// rate-worker.js: reads every review on the worker's own thread.2const SLOWER = 4; // 4 stands in for Asha's 4x slower CPU. DevTools can't slow a worker.3let done = 0;4const work = (count) => { let sum = 0; for (let i = 0; i < count * SLOWER; i++) sum += Math.sqrt(i); done += sum; };5let read = 0;6onmessage = (event) => {7  for (const tea of event.data) {8    let total = 0;9    for (const stars of tea.stars) {10      work(23_000); // reading one review's words11      total += stars;12      read += 1;13    }14    postMessage({ id: tea.id, rating: (total / tea.stars.length).toFixed(1), read });15  }16};

• Lines 2 to 4 make the course's stand-in work, work(). Line 2 sets SLOWER, which you'll meet in a moment.
• Line 6 runs when the page's message arrives. event.data is the list of teas.
• Lines 9 to 13 read each review: 23,000 steps of work, then add its stars.
• Line 14 sends the tea's rating back as soon as it's ready.

Notice what's missing: there are no yields. Nothing else runs on the worker's thread, so no click waits for it. The HTML standard says workers allow "long tasks to be executed without yielding to keep the page responsive."

DevTools can't slow a worker

Measuring this has a catch. DevTools' CPU slowdown pauses one thread over and over: the page's main thread. Chromium's code starts it for the thread that asked, and only a page can ask. When the course asked for a worker, DevTools answered: "Operation is only supported for pages, not workers". So the course timed the same loop in both places:

1// The same loop, timed where it ran, on Asha's phone. Middle of 7 runs, in ms.2const main = 36.53; // the page's main thread, slowed 4 times3const worker = 9; // a worker: DevTools' slowdown doesn't reach it4const workerSlower = 35.09; // a worker doing the work 4 times over5console.log(`The main thread took ${(main / worker).toFixed(1)} times as long as the worker.`);6console.log(`Done 4 times over, the worker took ${workerSlower} ms.`);

• Line 2 is the loop on the page's main thread, slowed 4 times: 36.53 ms.
• Line 3 is the same loop in a worker: 9 ms. It ran at this computer's full speed.
• Line 4 is the worker doing the loop 4 times over: 35.09 ms.
• It prints The main thread took 4.1 times as long as the worker. and Done 4 times over, the worker took 35.09 ms.

So doing the work 4 times over brings the worker close to Asha's phone. That's what SLOWER = 4 does. The course also recorded the worker with SLOWER = 1, at full speed. Why it matters: with DevTools' slowdown on, a worker still runs at your computer's speed. Its numbers will look better than a phone's.

Where the time went

With pieces, the main thread did everything. With the worker, most of its 91.2 ms went on drawing frames: 56.3 ms. Handling the worker's 40 messages took 14 ms. Read the table across. Each row is one version on Asha's phone. Times are in ms after reviews.js started.

Two warnings come with these numbers.

• TBT was 0 with the pieces too. Total Blocking Time, or TBT, adds up the part of each long task over 50 ms. The 10 ms pieces already kept every task short. Here the worker's gain is the main thread's time and the frames.
• A stand-in is still a stand-in. The plain loop matched. But on the page, the stand-in worker showed all 40 ratings at 430.5 ms, and the pieces at 706 ms. Don't read that as the worker being faster. On a real phone, the worker runs on the same slow processor. web.dev says plainly that moving work "doesn't make your app faster".

Pick a version to see all its numbers. The fourth uses Comlink, which comes later:

A worker isn't free

Starting one costs time. On the lab page, a new worker answered its first message after 4.26 ms. That was this computer's worker thread, not slowed. The HTML standard warns that workers "have a high start-up performance cost, and a high per-instance memory cost." So start one worker early and keep it, instead of one per job. How workers work explains why.

What a message costs: copy or transfer

Every message crosses from one thread to the other. By default, postMessage() copies it. The copy is made by structured clone: the browser's way to copy a value for a message. You can call it yourself, as structuredClone().

Here are both, with structuredClone. Press Edit & run to try it:

1const photo = new ArrayBuffer(48_000_000); // a 12-megapixel photo's pixels2const copy = structuredClone(photo);3console.log(photo.byteLength, copy.byteLength);4const moved = structuredClone(photo, { transfer: [photo] });5console.log(photo.byteLength, moved.byteLength);

• Line 1 makes an ArrayBuffer: a block of raw bytes. 48 million bytes is a 12-megapixel photo's pixels, at 4 bytes each.
• Line 2 copies it. Line 3 prints 48000000 48000000: two buffers, both full.
• Line 4 copies it again, but lists it under transfer. Line 5 prints 0 48000000. The bytes moved to moved, and the original is empty.

postMessage() takes the same list as its second argument: worker.postMessage(buffer, [buffer]). Only some objects can be transferred. ArrayBuffer is the common one. Plain objects and arrays are always copied.

Who pays for a copy? Both sides. Surma measured it for his article "Is postMessage slow?", and put it this way: "serialization blocks the sending realm, while deserialization blocks the receiving realm." Serializing turns the value into bytes for the trip. Deserializing builds it again on the other side. In Chrome, the receiver pays when it first reads event.data. Chromium's code rebuilds the data right there.

Ravi's message is small

The worker page sends one message with this week's teas. The lab page timed it:

1// The worker page's one big message: this week's teas. Middle of 7, in ms.2const teas = { json: 9154, send: 0.03, receive: 0.04 };3console.log(`${(teas.json / 1000).toFixed(1)} KB as JSON: ${teas.send} ms to send, ${teas.receive} ms to read in the worker`);

• Line 2 holds the teas' size as JSON text, 9,154 characters, and the two times.
• Line 3 prints 9.2 KB as JSON: 0.03 ms to send, 0.04 ms to read in the worker.

That's nothing next to 410.4 ms of work. Why it matters: a worker pays off when the work is big and the message is small.

Big messages: copy or transfer?

The lab page sent buffers of five sizes each way, seven times each, on Asha's phone. Its clock counts in steps of 0.005 ms; the last section says why. Here is what the main thread paid:

1// The main thread's side of each message: [sending it, reading a reply that size]. Middle of 7, in ms.2const sizes = [3  { size: "1 KB", copy: [0.01, 0], transfer: [0.01, 0] },4  { size: "100 KB", copy: [0.01, 0.02], transfer: [0.01, 0] },5  { size: "1 MB", copy: [0.87, 0.12], transfer: [0.01, 0] },6  { size: "10 MB", copy: [4.71, 6.39], transfer: [0.02, 0] },7  { size: "48 MB", copy: [37.99, 26.79], transfer: [0.03, 0.03] },8];9for (const { size, copy, transfer } of sizes) {10  console.log(`${size}: copy ${copy[0]} + ${copy[1]}, transfer ${transfer[0]} + ${transfer[1]}`);11}

• Lines 3 to 7 hold one size each, from 1 KB to 48 MB. copy holds two times: sending a copy to the worker, and reading a copy from it. transfer holds the same two for a transfer.
• Line 10 prints five lines. The last is 48 MB: copy 37.99 + 26.79, transfer 0.03 + 0.03.

Up to 100 KB, a copy cost hundredths of a millisecond. At 10 MB, sending and reading a copy took about 11 ms together. At 48 MB, sending a copy took 37.99 ms, and reading one took 26.79 ms. Each is longer than a whole frame, which is 16.7 ms at 60 frames a second. A transfer stayed under a tenth of a millisecond at every size.

Surma's advice fits: "even on the slowest devices, you can postMessage() objects up to 100KiB and stay within your budget." His budget is 100 ms for answering a click. With animations running, he keeps messages under 10 KiB. Why it matters: for anything big, like pixels or sound, put it in an ArrayBuffer and transfer it.

Pick a size to see both sides of each message:

Now try it in your own browser. This lab starts a small worker that reads each message:

1// What Send does, with the size you picked.2const buffer = new ArrayBuffer(size);3const start = performance.now();4worker.postMessage(buffer, transfer ? [buffer] : []);5const send = performance.now() - start;6console.log(send, buffer.byteLength); // the time, and the bytes left here

Calling a worker like a function

Ravi's worker understands one message. A real app sends many kinds: rate these, search that, sort those. Parallel patterns with workers built a helper for that. Each request gets an ID, and each reply finds its promise. That's a remote procedure call, or RPC: a function call that runs somewhere else. Comlink is a small library from Google Chrome Labs that does it for you.

Here is the worker with Comlink 4.4.2:

1// rate-worker.js, with Comlink: exposes rate() to the page.2importScripts("comlink.js");3const SLOWER = 4; // 4 stands in for Asha's 4x slower CPU. DevTools can't slow a worker.4let done = 0;5const work = (count) => { let sum = 0; for (let i = 0; i < count * SLOWER; i++) sum += Math.sqrt(i); done += sum; };6Comlink.expose({7  rate(tea) {8    let total = 0;9    for (const stars of tea.stars) {10      work(23_000); // reading one review's words11      total += stars;12    }13    return (total / tea.stars.length).toFixed(1);14  },15});

• Line 2 loads Comlink into the worker. importScripts() runs another script file inside a worker.
• Lines 6 to 15 offer the page one function, rate(). It reads one tea's reviews and returns its rating.

And the page:

1// reviews.js, with Comlink: the worker's rate() looks like an ordinary async function.2const about = document.querySelector("#about");3const onScreen = (tea) => document.querySelector(`[data-tea="${tea.id}"]`).getBoundingClientRect().top < innerHeight;4const rater = Comlink.wrap(new Worker("rate-worker.js"));5async function rateAll(teas) {6  let read = 0;7  for (const tea of teas) {8    const rating = await rater.rate(tea);9    read += tea.stars.length;10    document.querySelector(`[data-tea="${tea.id}"] .stars`).textContent = "★ " + rating;11    about.textContent = "Reviews read: " + read + " of 4000";12  }13}14rateAll([...TEAS.filter(onScreen), ...TEAS.filter((tea) => !onScreen(tea))]);

• Line 4 wraps the worker. rater looks like the object the worker offered.
• Line 8 calls rater.rate(tea). Comlink's README says calls are "inherently asynchronous". So it returns a promise, and await waits for it.
• Lines 9 to 11 count the reviews and write the rating, as before.

Inside, it's still postMessage(). Comlink's source gives each call a new ID and sends one message. The reply with the same ID settles the promise. Every argument and result is copied, by default. Comlink.transfer() marks a buffer to transfer instead.

What Comlink cost

First, its size. Comlink's minified file is 4,721 bytes, and 2,069 compressed with gzip. Then the time per call, on the lab page:

1// 40 tiny calls to a worker, one after another, on Asha's phone. Middle call, in ms.2const plain = 0.01; // postMessage, then wait for the reply3const comlink = 0.03; // await api.next(n)4console.log(`Plain messages: ${plain} ms a call. Comlink: ${comlink} ms a call.`);

• Lines 2 and 3 hold the middle of 40 tiny calls, one after another, each way.
• Line 4 prints Plain messages: 0.01 ms a call. Comlink: 0.03 ms a call.

Comlink itself is cheap. But the Comlink page was slower: all 40 ratings were on screen at 619.9 ms, against 430.5 ms with plain messages. The worker was also busy longer, 520.9 ms against 410.4 ms. Look at line 8 again. It waits for each tea before asking about the next. So 40 round trips sit between the pieces of work, and the worker waits too. The plain page sent all the teas in one message.

Why it matters: a wrapper makes a worker easy to call, but a call is still a message. Ask for big jobs, not many small ones. One call could take every tea, with Comlink.proxy() around a function the worker calls back for each rating.

Drawing in a worker with OffscreenCanvas

Meera's next wish is a chart: one dot for each of this week's 4,000 reviews. There's a column for each tea and a row for each star. The page draws it on a canvas: an HTML element that JavaScript paints pixels on.

1// chart-draw.js: one dot for each of this week's 4000 reviews. A column per tea, a row per star.2function drawChart(context, teas) {3  context.fillStyle = "#1f6f4a";4  teas.forEach((tea, column) => {5    tea.stars.forEach((stars, index) => {6      work(10_000); // working out where the dot goes7      context.fillRect(4 + column * 9.6 + (index % 7), 100 - stars * 18 + (Math.floor(index / 7) % 12), 2, 2);8    });9  });10}

• Line 2 takes a drawing context, the object you draw with, and the teas.
• Line 6 does 10,000 steps of work for each dot. It stands in for working out where the dot goes.
• Line 7 paints the dot: a square 2 pixels wide.

On the first chart page, chart.js calls drawChart() on the main thread, once the reviews arrive. That's one task. Asha clicks Add while it runs. But a canvas belongs to the page. Can a worker draw on it?

That key is OffscreenCanvas. Here is the second chart page:

1// chart.js: hands the canvas to a worker, which draws the chart.2const canvas = document.querySelector("#chart").transferControlToOffscreen();3const worker = new Worker("chart-worker.js");4worker.postMessage({ canvas, teas: TEAS }, [canvas]);

• Line 2 calls transferControlToOffscreen(). It returns an OffscreenCanvas: a canvas with no page attached. The canvas element stays on the page and shows what the OffscreenCanvas draws.
• Line 3 starts the worker.
• Line 4 sends the canvas and the teas. The canvas goes in the transfer list: an OffscreenCanvas can be transferred, not copied.

1// chart-worker.js: draws on the page's canvas from the worker's own thread.2importScripts("chart-draw.js");3const SLOWER = 4; // 4 stands in for Asha's 4x slower CPU. DevTools can't slow a worker.4let done = 0;5const work = (count) => { let sum = 0; for (let i = 0; i < count * SLOWER; i++) sum += Math.sqrt(i); done += sum; };6onmessage = (event) => drawChart(event.data.canvas.getContext("2d"), event.data.teas);

• Line 2 loads the same drawChart() into the worker.
• Line 6 gets a context from the OffscreenCanvas, and draws. Same code, other thread.

The HTML standard pushes each finished drawing to the page's canvas. It encourages browsers to show it without waiting for the page's main thread. That helps most "in cases where the OffscreenCanvas is updated from a worker event loop and the window event loop of the placeholder canvas element is busy." Here is what Asha got:

1// Asha clicks Add while the chart is drawn. In ms after her click, from the recording.2const pages = [3  { name: "Main thread", cart: 154.7, chart: 154.7 },4  { name: "Worker", cart: 39.3, chart: 124.8 },5];6for (const page of pages) {7  console.log(`${page.name}: Cart: 1 on screen at ${page.cart} ms, the whole chart at ${page.chart} ms`);8}

• Lines 3 and 4 hold each chart page: when Cart: 1 reached the screen, and when the whole chart did.
• Line 7 prints Main thread: Cart: 1 on screen at 154.7 ms, the whole chart at 154.7 ms. Then it prints Worker: Cart: 1 on screen at 39.3 ms, the whole chart at 124.8 ms.

On the main thread, the drawing was one task of 265.4 ms. Asha's click waited 116.6 ms for it to end, and TBT was 215.4 ms. With the worker, her click waited 1.2 ms, and TBT was 0. Here is her screen, 60 ms and 140 ms after she clicked:

The worker took about as long to draw: 250.4 ms. It just stopped blocking her. Why it matters: slow drawing can leave the main thread and still land on the page.

Shared memory needs an isolated page

Messages copy data or move it. A SharedArrayBuffer does neither. It's a block of bytes that the page and its workers can all read and write at once. Parallel patterns with workers explains it, and Atomics: functions that read and write shared bytes safely.

Ravi tries it for the reviews line. The worker adds one to a shared count after each review. The page reads the count before each frame. There's no message per review at all:

1// progress-worker.js: adds one to the shared count after each review.2onmessage = (event) => {3  const { teas, progress } = event.data;4  for (const tea of teas) {5    for (const stars of tea.stars) {6      work(23_000); // reading one review's words7      Atomics.add(progress, 0, 1);8    }9  }10};

• Line 3 takes the teas and progress: an Int32Array, a list of whole numbers. Its one number lives in shared memory.
• Line 7 adds 1 to the count with Atomics.add(). The page never sees a half-written number.

1// The page: one number in shared memory, read before each frame.2const progress = new Int32Array(new SharedArrayBuffer(4));3worker.postMessage({ teas: TEAS, progress });4requestAnimationFrame(function show() {5  const read = Atomics.load(progress, 0);6  about.textContent = "Reviews read: " + read + " of 4000";7  if (read < 4000) requestAnimationFrame(show);8});

• Line 2 makes the shared memory: 4 bytes, room for one number.
• Line 3 sends it. The page and the worker now hold the same bytes.
• Lines 4 to 8 read the count with Atomics.load() before each frame, and stop at 4,000.

On the lab page, the reviews line showed 9 counts in 134.1 ms, from 0 to 4,000. Each frame read the count with no message at all.

Why the lock? MDN says browsers turned off shared memory and precise timers in 2018, because of Spectre. Spectre is an attack that reads memory it shouldn't, by timing things very precisely. So today a page gets shared memory only when it is cross-origin isolated: kept apart from other sites' windows and files. Two headers from the server do that:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

• Line 1 is COOP, the Cross-Origin Opener Policy. It keeps other sites' windows out of the page's group, so neither can reach the other.
• Line 2 is COEP, the Cross-Origin Embedder Policy. The page may load another origin's files only if they agree to it. credentialless is the other value that works.

The page must also be a secure context: served over HTTPS, or from your own computer. The HTML standard ignores COOP anywhere else. The course served the same lab page twice over HTTPS, with the headers and without:

1// The lab page on shop.example over HTTPS, with and without the two headers. From the recording.2const pages = [3  { page: "Without the headers", isolated: false, sharedArrayBuffer: "undefined", posting: "DataCloneError" },4  { page: "With them", isolated: true, sharedArrayBuffer: "function", posting: "posted" },5];6for (const page of pages) {7  console.log(`${page.page}: crossOriginIsolated ${page.isolated}, SharedArrayBuffer is ${page.sharedArrayBuffer}, posting shared memory: ${page.posting}`);8}

• Lines 3 and 4 hold what each page reported.
• Line 7 prints Without the headers: crossOriginIsolated false, SharedArrayBuffer is undefined, posting shared memory: DataCloneError. Then it prints With them: crossOriginIsolated true, SharedArrayBuffer is function, posting shared memory: posted.

Without the headers, Chrome hid SharedArrayBuffer, as the HTML standard says to. The page could still make shared memory through WebAssembly. But posting it to a worker threw DataCloneError.

Isolation costs something too. On the isolated page, an image from images.example, the shop's image server, didn't load. It loaded once that server sent Cross-Origin-Resource-Policy: cross-origin with it. Every image, script and frame from another site needs that, or CORS. And one more change came with isolation: performance.now() counted in steps of 0.005 ms, against 0.1 ms without. Why it matters: isolate a page only when it really needs shared memory, and check its third parties first.

Where should this work run?

Each job below comes from a real shop page. Sort it by where it should run:

Common mix-ups

• "A worker makes the work faster." No. It moves the work to another thread. The main thread's share fell from 657.6 ms to 91.2 ms, and the worker did 410.4 ms of it.
• "Sending data to a worker is free." No. A copy costs both sides. At 48 MB, sending one took the main thread 37.99 ms.
• "Transferring a buffer copies it quickly." No. It moves the bytes. The sender's buffer is left empty, with a byteLength of 0.
• "DevTools' CPU slowdown slows workers too." No. It slows the page's main thread only. The same loop took 36.53 ms there and 9 ms in a worker.
• "Comlink shares objects between threads." No. It sends messages. Arguments and results are copied, unless you transfer them.
• "Any page can use SharedArrayBuffer." No. Only a cross-origin isolated page can. Without COOP and COEP, the constructor is hidden.

Practice exercises

Answer first, then use the hints.

const tea = { id: "mint-tea", stars: [5, 4] };
const sent = structuredClone(tea); // the copy postMessage makes
sent.stars.push(1);
console.log(tea.stars.length, sent.stars.length);

const stars = new Uint8Array([5, 4, 5, 3]);
const moved = structuredClone(stars, { transfer: [stars.buffer] });
console.log(stars.length, moved.length);

Check your understanding

For each question, ask which thread does the work, and what crosses between them.

Key takeaways

• A worker runs JavaScript on its own thread. It moves work off the main thread; it doesn't make it smaller.
• Work on data can move. Anything that reads or changes the page stays on the main thread.
• DevTools' CPU slowdown doesn't reach a worker. Measure the worker's own time, and remember a phone is slower.
• A message is copied by default, and both sides pay. Transfer big ArrayBuffers instead: the cost stays tiny.
• Comlink makes calls look local, but each call is a round trip. Ask for big jobs.
• OffscreenCanvas lets a worker draw on the page, while the main thread answers clicks.
• SharedArrayBuffer needs a cross-origin isolated page: HTTPS, COOP and COEP.

Sources

The facts on this page come from these specs, docs and source files:

• HTML Standard: Web workers, WHATWG.
• Use web workers to run JavaScript off the browser's main thread, web.dev.
• inspector_emulation_agent.cc, Chromium 157.0.8103.52, Chromium on GitHub.
• thread_cpu_throttler.cc, Chromium 157.0.8103.52, Chromium on GitHub.
• HTML Standard: Safe passing of structured data, WHATWG.
• Transferable objects, MDN.
• Worker: postMessage() method, MDN.
• message_event.cc, Chromium 157.0.8103.52, Chromium on GitHub.
• Is postMessage slow?, Surma.
• Comlink README, version 4.4.2, GoogleChromeLabs on GitHub.
• comlink.ts, version 4.4.2, GoogleChromeLabs on GitHub.
• OffscreenCanvas, MDN.
• HTML Standard: The OffscreenCanvas interface, WHATWG.
• SharedArrayBuffer, MDN.
• Window: crossOriginIsolated property, MDN.
• Making your website cross-origin isolated using COOP and COEP, web.dev.
• HTML Standard: Cross-origin opener policies, WHATWG.
• ThreadAppender.ts, Chrome DevTools, ChromeDevTools on GitHub.

Coming next: WebAssembly for performance. Some work runs faster in WebAssembly, and some doesn't. You'll measure which, and what it costs to load.