The baseline from 09-01 splits the blame across four fronts, and this lesson attacks the first: your own code taking too long to run. Those are rows 2, 4, 6 and 7 of the table —480 ms of INP when typing in the search box, a long task of 1,180 ms at startup, 96 ms thrown away recomputing the same thing and a 940 ms planning report that leaves the screen frozen. You are going to see how the engine works internally (just enough not to sabotage it, without falling into useless micro-optimizations), why algorithmic cost outranks every other consideration, how to compute once what gets used many times with a properly invalidated cache, when to use debounce and when throttle, how to chunk long work so the event loop can breathe, and how to finally get the genuinely heavy work off the main thread with a Web Worker. We will finish with a table of debunked myths, because almost everything people repeat about "fast JavaScript" stopped being true fifteen years ago.

1. Where the time actually goes
2. How the engine works: parsing, interpretation and JIT
3. Hidden shapes, monomorphism and deoptimization
4. Practical rules for not sabotaging the engine
5. The cost that really rules: complexity
6. From the quadratic loop to a Map index
7. Computing only once: memoization
8. A properly invalidated cache in Board
9. Frequent handlers: debounce and throttle
10. Chunking long work so the thread is not blocked
11. Web Workers: a genuinely separate thread
12. The cost of crossing the boundary: serialization and transferables
13. The planning report, in a worker
14. Debunked myths
15. Common Mistakes and Tips
16. Exercises
17. Conclusion

Before touching anything, let us break down the 1,180 ms long task at startup. With the performance.mark/measure instrumentation from 09-01 and the Performance panel at CPU 4×, the split is this (median of 15 startups, 600 tasks, reference laptop):

This breakdown already makes two decisions for us. First: groupByTag() burns 148 ms doing something conceptually trivial, and that smells of the wrong algorithm. Second: micro-optimizing Task.fromJSON to shave 10% off its 103 ms would give you 10 ms, whereas fixing the grouping algorithm will give you 145. That is the order in which you have to work.

But before touching the algorithm it is worth knowing what the engine does with your code, because there are a handful of writing decisions that do matter —and an awful lot that do not.

A modern engine (V8 in Chrome and Node, SpiderMonkey in Firefox, JavaScriptCore in Safari) does not interpret your code line by line forever. It does something smarter: it starts fast and improves what gets used a lot.

Four ideas to hold on to:

Parsing is lazy. The engine does not fully parse the body of a function until you are about to run it. It looks at just enough to know where the function ends. That is why a 2 MB JavaScript file costs time even if you execute almost none of it: the whole thing has to be walked. That is an argument for 09-05, not for here, but it explains why "download less code" is an execution optimization as well as a network one.

Execution starts in the interpreter. Bytecode is generated quickly and runs straight away. That favors startup over peak speed.

Hot code gets compiled. When a function runs many times, or a loop iterates a lot, the engine promotes it to an optimizing compiler that generates machine code specialized for the types it has seen so far.

Assumptions can fail. If the optimized code assumed "this parameter is always a number" and one day a string arrives, the engine deoptimizes: it throws the machine code away, goes back to the interpreter and may reoptimize later. Repeated deoptimization inside a hot loop (what is known as a deopt loop) can make a fragment ten times slower without a single line having changed.

And here is the most important practical consequence of the whole section: what you have just read is, for 95% of code, cultural information. It is useful for not writing atrocities and for understanding odd measurements. It is not useful for deciding how to write a filter.

To make property access fast, V8 does not store each object as a dictionary. It assigns every object a hidden shape (hidden class or map) describing which properties it has and in what order, so it can reach task.estimatedHours at a fixed memory offset, as in a compiled language.

Two objects share a shape if they were built with the same properties in the same order:

When a piece of code accesses t.estimatedHours and every object that passes through has the same shape, that access is monomorphic: the engine keeps an inline cache with the offset and goes straight there. If two or three different shapes come through it is polymorphic (still reasonable), and if many do it is megamorphic: the engine gives up and does a generic lookup, which is far slower.

The good news is that Nómada Tasks already does the right thing without trying to, and the reason was never performance: it was design. The Task class from 05-02 assigns all its fields in the constructor, always in the same order, and #status is private and only changes through changeStatus. Result: the 600 tasks share a single shape and every access in the render is monomorphic.

Compare with the alternative we would have had if we had used loose object literals:

The second version is not just faster: it is better code, because the object has a predictable shape and there is no need to check for the existence of properties all over the place. And that is the general rule of this section: the practices that help the engine almost always coincide with the practices that help the reader. When they do not coincide, the reader wins, unless you have a measurement saying otherwise.

One clear warning: do not write strange code to "help the JIT". Engines change every six weeks, and the tricks that circulated in 2012 are counterproductive or irrelevant today. What remains true is the structural stuff: stable types, stable shapes, and never changing the nature of a variable halfway through its life.

These are the only five rules in this section worth remembering:

And the degraded-array example, which does produce a measurable difference:

None of this is going to fix the 480 ms of INP. What is going to fix it is the next section.

In 02-04 you saw that two nested loops over the same list produce a quadratic cost. Time to formalize it, because it is the only category of optimization that improves things by factors of 50× instead of by 15%.

Complexity describes how the work grows when the data grows, ignoring constants:

Look at the quadratic row: going from 6 to 600 tasks —a hundred times more data— multiplies the work by ten thousand. That explains why Nómada Tasks was perfect with the canonical backlog and crawls with the two-year one. It has not become slow: the defect was there from the start and only shows itself at volume.

The warning sign is always the same, and you can spot it at a glance:

for is O(n). filter is O(n). One inside the other is O(n²). If while reading a fragment you find a find, filter, includes, indexOf or some inside a loop that walks the same collection, you have found the problem.

This is the real groupByTag() of Nómada Tasks, the one that burns 148 ms:

With 600 tasks and 6 tags, the filter runs 6 times over 600 elements, and inside each one there is an includes over the task's own tag array. That is 3,600 outer iterations × the cost of the includes. And in the view's real usage it is called by assignee and by tag, which multiplies the nesting.

The solution is the one from 04-05, taken to its extreme: walk once and build an index.

The inner loop does not make this O(n²): it walks the tags of one task, which are one or two, not the 600 tasks. The total complexity is O(n · t) with t ≈ 1.5, that is, linear in practice.

Comparative measurement, using bench() from 09-01 (5 warm-up runs, 15 measured runs, CPU 4×):

Forty-eight times. No micro-optimization on earth produces that. And most important of all: with 6,000 tasks, the quadratic version would cost around 15 seconds and the linear one around 31 ms. The improvement grows with the data.

The same pattern applies to Board.findById, which the delegated controller from 06-04 calls on every click:

For a single click the difference is imperceptible (0.004 ms against 0.00008 ms). But when the BoardChannel from 07-04 receives a batch of 600 updates after a reconnection, those 600 linear searches are 360,000 comparisons: 34.2 ms against 0.8 ms. The rule is simple and admits no nuance: if you look something up by key more than once, index it by key.

A word of honesty, however. A Map takes up memory and has to be kept in sync with the array: if somebody removes a task and forgets the delete on the index, you have a data bug and a memory leak (09-03). The index is justified when there are many lookups; with six tasks and one click a minute, find is perfectly fine.

The second family of optimizations is not repeating identical work. In 03-04 you built createMemoizedCounter() with a closure; the general pattern is this:

And its natural use in Nómada Tasks: the Intl date formatting in util/format.js, which is surprisingly expensive because creating an Intl.DateTimeFormat involves loading locale data.

With 600 tasks and around 200 distinct dates, memoizing turns 600 formattings into 200: 4.6 ms → 1.7 ms. Not much, but free and risk-free.

Now the three conditions you have to verify before memoizing anything, because memoizing badly produces bugs that are very hard to find:

1. The function must be pure. If it depends on something that changes (the time, the board, Math.random), the cache returns lies.
2. The key must capture every input. readableDate(iso) is fine; a function that also depended on the language would need the language in the key.
3. The cache must have a limit or an invalidation. A Map growing indefinitely is a textbook memory leak (09-03). For bounded keys —200 dates— there is no problem; for unbounded keys you have to set a cap or use a WeakMap.

Memoizing readableDate satisfies all three. Memoizing summary() fails the first, and that is where the interesting case lies.

Board.summary(today) walks the tasks to compute total, open, total hours, open hours, overdue and effort. With 600 tasks it costs 1.4 ms. The view calls it three times per render (the summary bar, the sidebar and the exporter), and a live filtering of 23 keystrokes fires 23 renders: 1.4 × 3 × 23 = 96 ms thrown in the bin recomputing exactly the same thing.

summary() is not pure: it depends on the board's internal state. But it is deterministic as long as the board does not change, and that is exactly the condition that permits a cache with explicit invalidation.

The correct technique is a version counter: every mutation increments it, and the cache records which version it was computed with.

Five decisions in that code, and they are what separates a correct cache from a generator of subtle bugs:

• The key includes today. Without it, asking for the summary for a different date would return yesterday's. It is the most common invalidation failure: forgetting a parameter.
• #invalidate() is in every mutation, including changeStatus, which does not touch the array but the insides of a task. If one single mutation path forgets it, the cache lies and the bug will surface days later.
• The returned object is frozen. Since the cache always hands out the same reference, if somebody did r.overdue = 0 they would corrupt the state for every future reader. Object.freeze prevents it (and in strict mode, it throws).
• One pass instead of six. The previous version chained filter and reduce; walking once and accumulating everything lowers the cost even on cache misses.
• openHours leans on summary. A single source of truth and a single cache.

And the test, because a cache with no invalidation test is a time bomb (08-03):

Result for measurement 6 of the baseline:

The 96 ms above were only half the search box's problem. The other half is that there are 23 renders where there should be 2. No computation is as fast as the computation you never run.

You already used debounce in 06-07 and 07-01, and 06-07 warned you not to confuse it with throttle. Here is the full distinction.

• Debounce: postpones execution until N ms have passed without new events. If the user keeps typing, it keeps postponing. It runs once, at the end.
• Throttle: runs at most once every N ms, discarding the calls in between. It runs regularly, throughout.

And the complete implementation in util/time.js, extending the debounce you already had:

The trailing edge of the throttle is the detail most home-made implementations forget: without it, if the user stops scrolling right after a run, the final position is never processed and the interface is left out of date.

Applied to the controller from 06-04:

That { passive: true } is not decorative: it promises the browser that the handler will not call preventDefault(), so it can scroll without waiting for your code to finish. For scroll, touchstart and wheel it is practically mandatory.

Search box measurement with both optimizations (cache + debounce), typing "screen-printing" at normal speed:

INP now meets the ≤ 200 ms target. And notice the order of the columns: the cache alone was not enough, because the dominant problem was not the computation but the render (which 09-04 will fix). The debounce worked because it eliminates entire renders.

One last nuance about scroll: for work that affects what is visible, requestAnimationFrame is usually better than throttle with a fixed number of milliseconds, because it syncs with the screen's real rhythm. That is 09-04's material.

05-07 established it: JavaScript has a single thread for running your code and painting the interface; a heavy loop freezes it, and await does not fix that because it does not yield the thread if there is nothing genuinely asynchronous behind it. The solution announced there was chunking.

The pattern consists of splitting the work into batches and handing control back to the browser between batches, so it can service events and paint.

Three important details:

Yield by time, not by item count. if (i % 100 === 0) is what you see everywhere, and it is wrong: on a fast laptop it yields too much (and runs slowly from all the back-and-forth), and on a slow phone it yields too little (and blocks anyway). Measuring the budget adapts by itself.

setTimeout(0) does yield; await Promise.resolve() does not. It is exactly the macrotask/microtask distinction from 05-07: microtasks are drained before the browser paints, so yielding to a microtask lets nothing be painted. This is one of the most frequent mistakes when implementing chunking.

The 8 ms budget comes from section 2 of 09-01: under 10 ms of JavaScript per frame.

And the three ways of yielding, compared:

requestIdleCallback deserves an example, because it is the right tool for work that can wait:

Applying inBatches to rebuilding the board after loading 600 tasks:

Read the second row carefully: the total work has increased by 11%, because of the cost of going back and forth through the event loop. And it is still an enormous improvement, because perceived performance is not total time, but the time during which the user can do nothing. This is one of the most counterintuitive lessons of the module.

But chunking has a limit: if the work is 940 ms of pure computation, chunking spreads it out but still steals 940 ms from the thread that has to paint. For that you need another thread.

A Web Worker runs JavaScript on a thread separate from the main one. It is not a simulation or a scheduling trick: it is real parallelism, on another core if there is one.

In exchange, it lives in a world apart:

That last row is the key: worker and main thread do not share memory. They communicate by passing messages, and the messages are copied.

The minimal skeleton:

The per-message id is not a luxury: without it you cannot have two requests in flight and match each response with its promise. It is the same problem the id of an HTTP request solves.

The new URL(..., import.meta.url) is mandatory if you use a bundler (09-05): it is the pattern Vite and friends recognize in order to include the worker in the build. A plain string path would not work after bundling.

Here is the workers' trap, and why they sometimes do not pay off. When you call postMessage(data), the browser makes a structured clone of the data —the same algorithm as the structuredClone you saw in 04-08— and hands the copy to the other thread. Copying costs time, and that time is paid on the sending thread.

First, the comparison of copying mechanisms over the 600 tasks (about 182 kB of JSON):

structuredClone is faster and more faithful: it is the correct answer to "how do I deep-copy", and the JSON round trip from 04-08 is relegated to when you specifically need text (for localStorage or for the network).

One crucial limitation to keep in mind at all times: structured cloning does not preserve classes. A Task object arrives at the worker as a plain object, with no methods and no private fields:

Second, transferable objects. Some types —ArrayBuffer, MessagePort, ImageBitmap, OffscreenCanvas— can be transferred instead of copied: the memory changes owner, with no copy, in practically zero time. The price is that the sender loses access (the buffer becomes detached).

The complete operating rule for deciding whether a worker pays off:

A worker pays off when the computation time is far greater than the serialization time. If you are going to compute for 5 ms and serialize 3 ms out and 3 ms back, do not do it. If you are going to compute for 940 ms, do it without hesitation.

Taller Nómada's quarterly report groups the 600 tasks by assignee, week and tag, computes workload percentiles and searches for the best distribution of hours. It costs 940 ms on the main thread. While it computes, Marta sees a frozen screen: it does not respond to clicks, it does not scroll, it paints nothing. It is exactly the scenario from 05-07.

With the Planner from section 11:

Notice what has changed and what has not: the view code is practically identical to how it would be with an ordinary async function. Wrapping the worker in promises (05-06) means the complexity of message passing is locked inside Planner and does not spread.

Before-and-after measurement (CPU 4×, median of 9 runs, pressing the button and scrolling the list while it computes):

The counterintuitive pattern again: total work has increased and the experience has improved radically. Eighty milliseconds of messaging cost in exchange for 888 ms during which the application stops being dead. Plus a new capability that was previously impossible: cancelling, because terminate() genuinely kills the thread, something a loop on the main thread does not allow in any way whatsoever.

And the honest comparison with the module's alternatives, for the same problem:

The last row closes the discussion from 07-07: Wasm made the computation 2.5× faster, but it still blocked the main thread, because the problem was never raw speed but who occupies the thread that paints. A worker in ordinary JavaScript beats Wasm on the main thread. And if one day you needed the best of both, a Wasm module inside a worker is a perfectly normal combination.

A good part of what people repeat about "fast JavaScript" is folklore from fifteen years ago, when engines had no JIT. Here it is measured, on the reference laptop, over the 600 tasks, with bench() and 15 runs.

The practical conclusion is not "nothing matters": it is that the axis that matters moved. You no longer gain anything by choosing between for and forEach; you gain 48× by choosing between O(n²) and O(n), 130× by not repeating a computation, and all of the perceived performance by deciding who occupies the main thread.

Readability wins by default. Only a concrete measurement, over real data, justifies writing less clear code. And when you do, leave a comment with the number that justified it and the date, because in two years the engine will have changed.

• Micro-optimizing before looking at the complexity. Swapping forEach for for in a quadratic algorithm is painting a wall that is falling down.
• Not spotting the find inside the loop. It is the number one cause of slowness at volume, and it is visible at a glance once you know how to look for it.
• Memoizing an impure function. If it depends on the board, the clock or randomness, the cache returns lies and the bug will show up a long way from its cause.
• Forgetting an invalidation path. changeStatus does not touch the task array, but it changes the result of summary. If it does not invalidate, the cache lies.
• Leaving the cache key incomplete. Forgetting today in the summary key is a data bug, not a performance one, and one of the kind that takes weeks to discover.
• Caches with no limit. A Map that grows with every new key is a leak (09-03).
• Confusing debounce with throttle. Debounce on scroll leaves the interface frozen until the user stops; throttle on a search box fires requests halfway through a word.
• Setting a debounce that is too long. Above about 400 ms it is perceived as slowness. 250–300 ms is the usual range for a search box.
• Creating the debounced function inside the handler. An input with debounce(fn, 300) created on every event debounces nothing: each call has its own timer. Create it once, outside.
• Yielding with await Promise.resolve(). That is a microtask: it runs before painting. It yields nothing (05-07).
• Chunking by item count instead of by time. It does not adapt to different machines. Measure the budget.
• Putting a 5 ms computation in a worker. Serialization will cost more than the computation.
• Sending class instances through postMessage. They arrive as plain objects, with no methods. Use toJSON().
• Creating a worker for every operation. Starting one costs between 10 and 40 ms. Reuse one, or a small pool.
• Not calling terminate(). A live worker holds on to its thread and all its memory (09-03).
• Tip: before optimizing a computation, ask whether it needs doing at all. The fastest computation is the one that never runs: cache, debounce or load it on demand (09-05).
• Tip: write a test that pins the complexity. Checking that the time with 1,200 tasks is less than triple the time with 600 catches a regression back to quadratic.
• Tip: always wrap the worker in a promise API. Message passing is an implementation detail that must not contaminate the view.

Exercise 1 — Hunting the quadratic. This code computes, for each task, how many others share its assignee and priority. With 600 tasks it takes 214 ms.

State (a) the current complexity and how many comparisons it makes with 600 tasks, (b) an O(n) rewrite using Map, (c) what complexity the new version has, and (d) what improvement you would expect if the board grew to 6,000 tasks.

Exercise 2 — A cache invalidated per assignee. Board needs workloadOf(assignee), returning that person's open hours (the canonical ones: Iván 25 h, Lucía 14 h, Marta 6 h). It is called once per card during the render, that is, 600 times. Write a version with a properly invalidated cache, state what has to be part of the key, write the invalidation tests that guarantee it does not lie, and calculate the expected improvement knowing that one computation costs 0.9 ms.

Exercise 3 — Worker, batches or nothing? For each of these four pieces of Nómada Tasks work, choose between "directly on the main thread", "inBatches with yielding" and "Web Worker", justifying it with the criterion of serialization cost versus computation cost. Data: the serialized board is 182 kB, whose cloning costs 3.3 ms per trip.

1. Validating the new-task form (10 rules, 0.05 ms).
2. Rebuilding 600 Task instances from localStorage at startup (103 ms).
3. Computing the quarterly report (940 ms).
4. Recomputing the summary after every status change (0.9 ms).

Solution 1

(a) It is O(n²). The map walks the 600 tasks and, for each one, the filter walks all 600: 360,000 comparisons, each with three conditions. Hence the 214 ms.

(b) The key observation: the filter always looks for the same thing, the assignee + priority combination. You can count once how many tasks there are of each combination and then look it up in constant time.

The - 1 replaces the original's o.id !== t.id: each task has counted itself.

(c) O(n): two full passes and O(1) accesses to the Map. Measured: 214 ms → 4.2 ms, about 51× faster.

(d) With 6,000 tasks, the quadratic version would make 36 million comparisons: around 21 seconds (100× the 214 ms, because the work grows with the square). The linear one would make 12,000 operations: around 42 ms (10× the 4.2 ms). The improvement would go from 51× to about 500×. That is the essential point about complexity: the benefit of fixing it grows with the data, whereas the benefit of a micro-optimization stays where it is.

Solution 2

The key must include the assignee and today (because "open" does not depend on the date, but if tomorrow we wanted to filter by expiry it would; including it from the start avoids the classic bug), and the whole cache must be invalidated by the board's version counter.

Emptying the whole Map when the version changes is the right thing to do: a mutation can affect any assignee (a change of assignee affects two), so invalidating just one entry would leave stale data. And since the number of assignees is bounded, the Map does not grow without limit.

Expected improvement: the render calls workloadOf 600 times, but there are only three assignees. Without a cache: 600 × 0.9 ms = 540 ms. With a cache: 3 computations + 597 hits ≈ 2.7 ms. About 200× faster, and —what really matters— it goes from dominating the render to being invisible in it.

Solution 3

The general criterion, summed up in one sentence: if the computation does not comfortably exceed about 50 ms, do not leave the main thread; if it does exceed that but the result does not travel well, chunk it; if it exceeds that and travels well, use a worker. And notice that in two of the four cases the right answer is not "parallelize" but "do not compute": number 4 is solved by caching and number 1 is not solved because it is not a problem.

You have attacked the first front of the baseline and the numbers confirm it: the search box's INP has dropped from 480 ms to 96 ms, the 96 ms of recomputation are now 1.5 ms, groupByTag has gone from 148 ms to 3.1 ms, the long startup task from 1,180 ms to 41 ms through chunking, and the report that froze the screen for 940 ms now occupies the main thread for just 52 ms. All of it without touching a single line of DOM.

You know how the engine works —lazy parsing, bytecode that starts immediately, compilation of hot code, and deoptimization when an assumption fails— and you know about hidden shapes and the difference between monomorphic, polymorphic and megamorphic accesses. With that you have understood why class Task, designed in 05-02 with clarity in mind, turns out to be the fastest form too: every field in the constructor, in the same order, stable types. And you have received the warning that saves years of silliness: do not write strange code to help the JIT; write stable, readable code, which is the same thing.

You are crystal clear about the axis that really rules: complexity. You recognize the sign —a find, filter or includes inside a loop over the same collection— and you know how to turn O(n²) into O(n) with a Map index: 48× in groupByTag, 43× when applying a batch of 600 updates, with the improvement growing as the data grows. And you know the price of the index: memory and the obligation to keep it in sync on every mutation.

You know how to not repeat work: memoizing pure functions with the three conditions verified (purity, complete key, size limit), and putting in a cache invalidated by a version counter when the function is not pure but is deterministic between mutations —with today in the key, #invalidate() on every mutation path, the result frozen so nobody can corrupt it, and invalidation tests that stop the cache from lying. You know how to not run too often with debounce (waiting for the events to stop: search box, autosave) and throttle (running at intervals during the burst: scroll, pointermove), with its trailing edge and its { passive: true }.

And you know how to get off the main thread: chunking with inBatches, yielding on a time budget rather than an item count, distinguishing macrotasks that do yield from microtasks that do not (05-07), with requestIdleCallback for what can wait and scheduler.yield() where it is available; and, when that is not enough, a Web Worker wrapped in a promise API, with its per-message id, its error handling and its destroy(). You know the cost of the boundary: structured cloning is faster and more faithful than the JSON round trip from 04-08, but it does not preserve classes, and there are transferables that change owner instead of being copied. Hence the deciding rule: a worker pays off when the computation comfortably exceeds the serialization. That also closes the comparison from 07-07: WebAssembly sped up the computation but still blocked; the worker does not block, which was the real problem.

Finally, you have the table of myths dismantled with measurements: for versus forEach is 23 microseconds, ++i is identical to i++, concatenating strings is no longer slow, try/catch no longer prevents optimization and caching .length has been unnecessary for a decade. Readability wins by default, and only a concrete measurement over real data justifies otherwise.

Three fronts remain. And there is one that has been hinted at several times without being developed: talking about the index Map we said "if you forget the delete, you have a leak"; talking about memoization, "a cache with no limit is a leak"; talking about debounce, "you need .cancel() for cleanup"; and talking about the worker, "a live worker holds on to its thread and all its memory". Four warnings, one single subject. Row 8 of the baseline is still untouched: 37.7 MB retained after 200 filterings, memory the application reserves and never gives back, until the tab turns sluggish and eventually dies. That is a memory leak, and finding it requires understanding how the browser decides what to keep and what to throw away. That is the subject of Memory Management.