How a Browser Actually Works

• The main thread runs your scripts, the rendering event loop, the document lifecycle (style, layout, paint), hit testing, event dispatch and HTML parsing.
• The compositor thread processes input, performs scrolling and animations, decides how the page is split into layers, and coordinates raster work. There is one per renderer.
• Raster work turns drawing instructions into GPU texture tiles. The compositor coordinates it and the GPU process executes it.
• Worker threads run web workers and service workers.

The crucial fact: your JavaScript, style, layout and paint share one main thread, which does one task at a time. While it is busy it cannot run your next handler or produce the next animation frame.

Figure 3. Who does what between the click and the screen

How to read this: input lands on the compositor thread first. Anything that needs your code goes down to the main thread, and the results are committed back up. The compositor can still produce frames for work it handles itself, such as scrolling, without waiting for the main thread.

Where each stage runs, per the same documentation:

Why compositor-friendly animation matters

The main thread produces paint records (ordered drawing instructions). The compositor splits the page into layers and tiles, raster turns tiles into bitmaps in GPU memory, and the compositor gathers them into a compositor frame.

If an effect can skip layout and paint, it can run entirely on the compositor thread without the main thread (RenderingNG). web.dev puts it practically: the only two properties that avoid both are transform and opacity, and the element needs its own layer, which will-change can request. Each layer costs memory and GPU bandwidth, so promote only what you animate (web.dev).

For the carousel, compare two ways to slide the images:

/* Layout-triggering: changes geometry, so the main thread
   re-runs layout and paint on every frame. */
.track-slow {
  position: relative;
  left: 0;
  transition: left 300ms ease;
}
.track-slow.next { left: -100%; }

/* Compositor-friendly: transform changes need no layout or paint,
   so the compositor can move the layer by itself. */
.track-fast {
  will-change: transform;
  transition: transform 300ms ease;
}
.track-fast.next { transform: translateX(-100%); }

Both look the same, but only the second can keep moving while the main thread is busy. Confirm in the DevTools Performance panel on a throttled device; thread assignment can differ by browser and version.

Figure 4. Where does this visual change run?

How to read this: the further left and up you stay, the less main-thread work you create. Layout-affecting changes cost the most because each later stage depends on the previous one.

From click to handler, and the frozen page

Now the search box. A user taps it and types. What happens?

Figure 5. A click travels from the OS to your handler

How to read this: the browser process only knows the position of a gesture. The renderer finds what is under it and runs your listeners, and that step is on the main thread.

Chrome's part 4 explains the details that matter:

• The browser process sends the event's type (for example touchstart) and coordinates to the renderer, which finds the target and runs the listeners.
• The compositor marks regions with event handlers as the non-fast scrollable region. Input outside it can be handled without waiting for the main thread; input inside it goes to the main thread first.
• One listener on document.body (event delegation) marks the whole page non-fast scrollable. { passive: true } tells the browser the listener will not block scrolling.
• Continuous events (wheel, mousemove, pointermove, touchmove) are coalesced and dispatched just before the next requestAnimationFrame; discrete events (keydown, mousedown, touchstart) are dispatched immediately.

// Passive: the compositor can keep scrolling the carousel while this runs.
carousel.addEventListener("touchmove", onDrag, { passive: true });

// Delegation is fine for clicks. Avoid one listener on document.body
// for scroll-blocking events such as touchmove or wheel.
carousel.addEventListener("click", (event) => {
  const dot = event.target.closest("[data-slide]");
  if (dot) showSlide(Number(dot.dataset.slide));
});

Why a busy main thread feels like a frozen page

The compositor can scroll, but a click, a keystroke or a JavaScript-driven animation needs the main thread, and a long task makes them wait. web.dev defines a long task as one running longer than 50 milliseconds and notes the browser cannot respond to interactions while a task runs (Optimize long tasks). The delay before the handler starts is input delay, one component of Interaction to Next Paint (INP), covered in the Loading Performance and Core Web Vitals lesson.

Here is a deliberately bad search handler and a way to see the problem:

const input = document.querySelector("#search");

input.addEventListener("input", () => {
  const start = performance.now();
  while (performance.now() - start < 300) {
    // simulates 300 ms of synchronous work (illustrative)
  }
});

// Chromium-based browsers can report tasks of 50 ms or more.
// Check MDN's compatibility table before relying on it.
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(`long task: ${Math.round(entry.duration)} ms`);
  }
}).observe({ type: "longtask", buffered: true });

Each keystroke starts a task of about 300 ms, so the observer logs a long task of roughly that length per keystroke. Meanwhile the typed letter does not appear, a JavaScript-driven animation stalls and a click on a carousel dot waits, while a CSS transform transition on a promoted layer can continue. A large JSON parse, a big list render or a heavy third-party script has the same effect.

The fix is to split the work and yield so input is handled between pieces:

// scheduler.yield() is available in Chrome and Edge 129+ and Firefox 142+
// at the time of writing; not in Safari. Fall back to a timer.
function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function filterSuggestions(items, query) {
  const results = [];
  let last = performance.now();
  for (const item of items) {
    if (item.name.toLowerCase().includes(query)) results.push(item);
    if (performance.now() - last > 50) { // yield about every 50 ms
      await yieldToMain();
      last = performance.now();
    }
  }
  return results;
}

The Event Loop and the Main Thread lesson covers tasks, microtasks and workers. The architectural principle: everything on the main thread competes with the user's input.

What the same-origin policy and site isolation protect

Two protections sit on top of the process layout, and they are different things.

The same-origin policy is a rule of the web platform. An origin is the combination of scheme, host and port, so https://shop.example and https://chat.example are different origins. MDN summarises the policy: cross-origin writes (links, form posts) are typically allowed, embedding (images, scripts, iframes) is typically allowed, and reads are typically disallowed (MDN: Same-origin policy). For a cross-origin iframe, the parent gets only a very small set of window properties and methods, among them postMessage. The parent cannot read the iframe's DOM, and the iframe cannot read the parent's.

Site isolation is Chromium's defence in depth for that policy. A site is the scheme plus the registered domain (so https://a.shop.example:8080 is in the site https://shop.example). Site isolation puts pages from different sites in different processes, including cross-site iframes ("out-of-process iframes"). The reason is that Chrome assumes an attacker might compromise a renderer, or read its memory with a side-channel attack such as Spectre. If another site's data is not in that process, there is less to steal (Chromium: Site Isolation).

Details worth remembering:

• Process boundaries follow sites, not origins. shop.example and chat.shop.example are the same site and can share a process, so a widget on a subdomain of your site is not isolated from your page.
• It was enabled by default on desktop from Chrome 67. The Chromium page reports roughly 10 to 13 percent more memory use on desktop (Chrome 67, many tabs) and 3 to 5 percent on Android (Chrome 77): figures for those versions, not a general rule.
• It is not available everywhere (see the platform list above). The same-origin policy and server-side controls remain the base layer.

Figure 6. Should this third-party code run in my page or in a frame?

How to read this: embedding by script gives the vendor everything your own code has, and shares your main thread. An iframe on another site gets its own origin, usually its own process on desktop, and only the access you grant.

Here is the chat widget embedded as a cross-site, sandboxed iframe, with a safe message exchange:

<iframe
  src="https://chat.vendor.example/widget"
  title="Customer chat"
  sandbox="allow-scripts allow-forms allow-popups"
  loading="lazy"
  width="360"
  height="480"
></iframe>

const chat = document.querySelector('iframe[title="Customer chat"]');

// Parent to widget: name the exact target origin.
chat.contentWindow.postMessage(
  { type: "set-product", sku: "A-100" },
  "https://chat.vendor.example"
);

// Widget to parent: always check who sent it.
window.addEventListener("message", (event) => {
  if (event.origin !== "https://chat.vendor.example") return;
  if (event.data?.type === "unread") updateBadge(event.data.count);
});

Notes on this snippet, from MDN's iframe reference: an empty sandbox applies all restrictions and each token lifts one. Without allow-same-origin the frame is treated as a special origin that fails the same-origin check, which can block the frame's access to its own cookies and storage. If your widget needs its own storage, add allow-same-origin, which is safe here only because the frame's origin differs from yours. MDN strongly discourages combining allow-scripts and allow-same-origin for a same-origin embed, because the frame can then remove its own sandbox. loading="lazy" defers the frame until it nears the viewport. Add an allow attribute only for features the widget needs; it sets a Permissions Policy on top of any header.

For deeper treatment of identity, cookies and defences on the server, see System Design: Security.

What this means for design decisions

In practice: a product page whose chat widget slows search

The situation

A retail product page has an image carousel, a search box with live suggestions and a third-party chat widget. The vendor's guide says to paste a <script> tag that injects an iframe. A small front-end team records long tasks and INP with real-user monitoring. After a vendor update, tickets say "the page freezes when I start typing", mostly from budget Android phones.

Starting architecture

Figure 7. The product page with its trust boundary

How to read this: the iframe is isolated, but the loader script is not. It sits inside your zone and shares the main thread with your search box and carousel logic. The red dashed edge marks that shared thread as the weak point.

Options considered

The decision

Rollout and verification

1. Record a baseline of long tasks per page view and INP by device class (see observability and SLOs for alerting on such measures).
2. Ship the facade behind a flag to a small share of visitors, then widen it.
3. Compare long-task attribution (entries identify the frame behind a task) and INP between flag groups, by device class, not only on average.
4. Test on a throttled profile in DevTools and on a real low-end phone.

The 2 a.m. failure

At 02:00 the vendor releases a loader build that does heavy initialisation on load, while your facade flag covers only a small share of visitors. The alert is a rise in page views with long tasks, then in INP for the low-end mobile bucket. First checks: does the rise start at the vendor's release time, which long tasks are attributed to the loader or chat frame, and how do flag groups compare. Mitigation: raise the facade flag to 100 percent or use the tag manager's kill switch. Follow-ups: pin the vendor's script version where allowed, add a canary page that fails on long tasks from any third-party script, and send the vendor the long-task evidence.

Architect's notes

• Draw the thread map before the component map. What runs on the main thread, in a worker, in an iframe and on the server finds most performance and security problems early.
• Decide trust boundaries early. Which third parties get a frame and which a script is hard to change once other teams depend on them.
• Budget the main thread. Treat long tasks as a metric with an owner.
• Do not design to one engine's internals. Chromium's process counts and thread layout change between versions; the shared main thread does not.
• Defer layer tuning. Use transform and opacity by default; add will-change only when a profile shows a need.
• Measure on real low-end devices, where memory pressure and missing site isolation are worst.

Common mistakes

• Saying "one process per tab". In Chromium the count depends on memory, platform and site isolation, and one tab can use several processes.
• Believing an iframe protects your main thread. It protects data. A loader script in your page still runs on your thread.
• Animating layout properties. Sliding a carousel with left or width forces layout and paint every frame.
• One big scroll-blocking listener on document.body. The whole page waits for the main thread.
• Trusting postMessage without checking event.origin. Any window can message yours.
• Hosting a widget on your own subdomain and calling it isolated. Site isolation works on sites, so it can share your page's process.

Key takeaways

• A browser is a set of cooperating processes. The browser process coordinates; sandboxed renderer processes run web pages; the GPU process draws; a network service fetches.
• Process layouts are an implementation choice. This lesson describes Chromium; WebKit and Gecko share the broad shape but differ in detail, and counts vary by platform and device memory.
• Navigation is a hand-off. The browser process fetches, picks a renderer, commits the navigation, and the renderer parses and renders.
• One main thread runs your scripts, style, layout, paint and event handling. A task longer than 50 ms makes input wait.
• The compositor thread can scroll and animate on its own. transform and opacity on a promoted layer are the compositor-friendly properties.
• The same-origin policy is a rule; site isolation is a process boundary behind it. Both work on different units: origins and sites.
• Treat third parties as separate trust zones. Prefer a cross-site, sandboxed iframe, postMessage with origin checks, and a measured, late-loaded script.
• Measure long tasks and INP in the field, by device class.

Practice exercises

Exercise 1 — Starter (30 min): Open a page you work on, record a trace in the DevTools Performance panel, and find the main thread's longest task. Write down what ran in it and which of the stages (script, style, layout, paint) dominated.

Exercise 2 — Intermediate (1 hour): Build a small page with the two carousel CSS variants from this lesson. Add a button that blocks the main thread for 300 ms (illustrative). Click it while each slide animation is running and record what keeps moving. Explain the result using Figure 3.

Exercise 3 — Intermediate (1 hour): Draw the trust map of a page you own: which iframes are cross-site, which scripts are third-party, and what each can read.

Exercise 4 — Advanced (2 hours): Embed a cross-origin iframe on a local test page using two hostnames. Write the postMessage exchange with origin checks, then try to read the iframe's DOM from the parent and record the error.

Related reading

In this course:

• The Critical Rendering Path — how bytes become pixels, and what blocks what.
• The Event Loop and the Main Thread — how work is scheduled on the one main thread.
• Rendering Strategies: CSR, SSR, SSG, ISR and Streaming — where and when HTML is produced.

Elsewhere on the site:

• System Design: The Request Lifecycle — DNS, TCP, TLS and HTTP in detail, the part of navigation this lesson skips.
• System Design: Security — authentication, cookies and defences on the server side.
• System Design: Observability and SLOs — turning long-task and INP measurements into alerts.

Official documentation

• Inside look at modern web browser, part 1 (parts 2 to 4 follow it) — Chrome's walkthrough of processes, navigation, rendering and input.
• RenderingNG architecture — processes, threads and pipeline stages in Chromium's rendering.
• Chromium: Process Model and Site Isolation — process models by platform and limits.
• Chromium: Site Isolation — what it protects and where it is available.
• MDN: Same-origin policy — origins, cross-origin writes, embeds and reads.
• web.dev: Stick to compositor-only properties — which properties avoid layout and paint, and the cost of layers.