JavaScript

The problem

A 200 KB image and a 200 KB script take the same time to download. After that they part ways. The image is decoded and drawn, largely off to the side. The script has to be parsed, compiled and executed, and all of that happens on the main thread: the one thread that also handles taps, typing, scrolling and drawing the page.

So “JavaScript is expensive” is not mainly about bytes. It’s about how long the page is too busy to respond. The two experiments below let you watch that happen.

What happens to a script

Download

Bytes over the network. Depends on compressed size. Gzip or Brotli typically shrinks JavaScript by around three to four times, which is why this bar stays short even for big bundles.

Parse and compile

The engine reads the uncompressed source and turns it into something it can run. Compression doesn’t help here: a 450 KB download is well over a megabyte of code to process. Engines do some of this work on background threads and cache results, so treat the numbers here as illustrative.

Execute

Your code runs: building state, creating components, attaching listeners, hydrating server-rendered HTML. This is usually where a framework app spends its startup time.

Main thread

Everything above competes with input handling, style, layout and painting. While the main thread is busy, the page can’t respond. That is the red hatched lane.

The three techniques in the widget

• Remove unused code. Tree-shaking, dropping dead dependencies, importing one function instead of a whole library. Chrome DevTools’ Coverage tab shows how much of a bundle never ran. It typically shows a lot.
• Split by route. Ship the code this page needs now and load the rest on demand. Beware splitting too finely: more chunks mean more requests, and a waterfall of dependent loads can undo the gain.
• Load third parties late. Analytics, chat widgets and tag managers are often a large share of main-thread time. Running them when the page is idle doesn’t make them free. It moves their cost out of the moment the user is trying to interact.

async and defer stop a script from blocking HTML parsing. They don’t make the script cheaper to run, which brings us to the misconception below.

Long tasks and responsiveness

• A long task is any task that holds the main thread for more than 50 ms. The browser can’t interrupt it, so any tap, keypress or scroll that arrives meanwhile waits.
• Total Blocking Time adds up the time beyond 50 ms in every long task. It’s a lab measure of how much a page blocks while loading.
• Interaction to Next Paint (INP) is the field measure: the time from a user’s interaction to the next frame being drawn. The thresholds used for Core Web Vitals are good at 200 ms or less and poor above 500 ms.

How to break up work

• Yield to the main thread between slices. Use scheduler.yield() where it’s supported, otherwise setTimeout(…, 0). The demo above does this.
• Move work off the main thread to a Web Worker when it doesn’t need the DOM.
• Do less. The cheapest work is the work you don’t do: smaller bundles, less hydration, less rendering.

A motion lesson hiding in the demo. The CSS spinner kept turning while the JavaScript-driven one froze. Animations of transform and opacity can run on the compositor, away from the main thread. It’s one reason this site only animates those two properties.

Common misconceptions

See it on a real page

1. Open DevTools, then Performance. Set CPU throttling to 4× or 6× slowdown, record a page load, and look at the Main track. Tasks over 50 ms are marked with a red corner.
2. Open Coverage (Command menu, “Show Coverage”), reload, and see how much of each script ran.
3. Or watch from the page:

   new PerformanceObserver((list) => {
     for (const e of list.getEntries()) console.log('long task', Math.round(e.duration), 'ms');
   }).observe({ type: 'longtask', buffered: true });

4. For real users, collect INP with Google’s web-vitals library, because a lab run only shows what you tested.

Model assumptions