Browser architecture

A browser is more than one program

A browser is not one big program that does everything. It is split into several smaller programs. They run at the same time and send messages to each other. Two words help here:

• A process is one running program. It has its own private memory. Other processes can't read that memory.
• A thread is one line of work inside a process. One process can have several threads.

A browser uses both. This keeps a page quick to answer clicks. It keeps you safer from bad pages. And when one part crashes, the rest can keep going.

Keep the two sizes apart. Processes split the big jobs, and each one has its own memory. Threads split the work inside one process. Your page usually lives in one process, called the renderer. The browser also runs many other parts: the tabs and buttons around the page, the network, graphics, saved data, extensions, and more.

This lesson follows libuv & the thread pool. There you saw how Node hands slow jobs to helper threads. Here you will see how a browser keeps tabs and sites apart in separate processes. The next lesson, What happens when you navigate, follows a web address through these parts.

The browser's main parts

In Chrome, the browser process runs everything around the page: the address bar, the tabs, and the back button. It also decides which page to open, and it hands out jobs to the other processes.

A renderer process takes a page's HTML, CSS, and JavaScript. It turns them into the page you see inside a tab. Because the two are separate, page code can't take over the address bar. It also can't open any file it wants on your computer.

A page can show another small page inside it, like an embedded video. That small page is called an iframe. The code below counts how many renderers a page and its iframe need.

1const page = "shop.example";2const iframe = "video.example";3const siteIsolation = true;4 5const renderers = siteIsolation && iframe !== page ? 2 : 1;6console.log("renderers", renderers);

Line 1 names the site of the main page, shop.example. Line 2 names the site of an iframe on that page. Line 3 turns on a switch called siteIsolation; the next section explains it. Line 5 picks 2 renderers when the switch is on and the two sites are different. Otherwise it picks 1. Line 6 prints the count. Here the two sites are different, so it prints renderers 2.

Line 5 uses three small tools:

• !== means "is not equal to".
• && means "and": both sides must be true.
• ? : is a short if/else. If the part before ? is true, you get the value after it. If not, you get the value after :.

Chrome also has a GPU process. The GPU (graphics processing unit) is a chip that is good at drawing on the screen. The GPU process sends drawing work to it. Network work, like fetching files from the internet, runs in a separate network service. The browser process tells it what to fetch.

Don't learn a fixed number of processes. Chrome can add helper processes and extension processes. It can let two pages share one process. And it can change these details on different devices.

Why split the browser at all? A renderer handles messy input from the web: HTML, CSS, images, scripts, fonts, and your clicks. Any of these could come from a bad site. So Chrome gives the renderer its own process with fewer rights. If a renderer crashes, Chrome can often treat it as a problem in one tab only.

The operating system can also put the renderer in a sandbox. A sandbox is a set of rules that limits what a process may ask the computer to do, such as reading your files.

Splitting has a cost. Processes can't share memory, so they send messages to each other, and each message takes time. Each process also needs its own memory. Chrome weighs these costs against safety and stability. As a web developer, you don't choose how Chrome shares processes. But now you know why Chrome's Task Manager can show several rows for one tab.

The table below has one row for each main part. Read across: what the part does, then why Chrome keeps it apart.

Different sites get different renderers

Site Isolation is an extra safety wall in Chrome. It keeps pages from different sites in different renderer processes. On desktop Chrome, this includes iframes. If your page shows an iframe from another site, that iframe gets its own sandboxed renderer.

Why does this help? Say a bad site finds a bug that lets it take over its own renderer. With Site Isolation, that renderer holds only that site's data. So it is much harder for the bad site to read data from your other sites.

Two words describe an iframe's site:

• A cross-site iframe comes from a different site than the page.
• A same-site iframe comes from the same site as the page.

A site is not the same as a full web address. For this rule, Chrome looks at two parts of the address:

• The scheme, like https.
• The registered domain, the name you buy, like example.com.

It ignores the rest: the part before the domain, like help. in help.example.com, the port number, and the path. So https://help.example.com/faq and https://www.example.com are the same site. Keep the simple idea: a page and an iframe from a truly different site should not share one renderer's memory.

Site Isolation works together with the same-origin policy. That is a web rule about what a page's scripts may read or change in pages from other origins. An origin is the scheme, the full host name, and the port. Site Isolation does not replace that rule. It adds a second wall underneath it: a renderer for one site gets much less data from other sites in the first place. If one wall has a bug, the other one still helps. This idea is called defense in depth.

The wall has a cost. More renderers use more memory. A page with several cross-site iframes also needs its processes to send messages to each other. Chrome pays this cost on purpose, for safety.

Don't judge real safety or speed from a small count like the one in the playground below. The playground shows which way the choice goes. It does not show exactly what Chrome's Task Manager will list.

1const page = "shop.example";2const iframe = "video.example";3const siteIsolation = true;4 5const renderers = siteIsolation && iframe !== page ? 2 : 1;6console.log("renderers", renderers);

Press Same-site iframe first. The model shows one renderer. Then press Cross-site iframe, with Site Isolation still on. The model adds a second renderer. Turning Site Isolation off only shows the difference in the model. It is not advice to turn it off in a real browser.

The renderer's main thread

Inside a renderer, one thread does most of the page's work. It is called the main thread. It does these jobs:

• It reads the HTML. This is called parsing.
• It runs your JavaScript.
• It works out which CSS styles apply to each element.
• It works out the size and place of every box on the page. This is called layout.
• It writes down what to draw, and in what order.
• It runs event listeners, like a click handler.

A web worker can run some JavaScript on another thread. But a normal <script> tag and a normal click listener both run on the main thread.

1const user = "Asha";2console.log("Hello", user);

Line 1 stores a name in user. Line 2 prints Hello Asha. Both lines run on the main thread, one after the other. JavaScript does not start a new thread for each line. The whole script is one turn on the main thread. One such turn is called a task.

While the main thread is busy, it can't do anything else. It can't run a click handler, read more HTML, or work out the next layout. That is why the name says main: it is the one shared line of work for everything your page needs right now.

Think of someone typing into a search box. Each key press needs a turn on the main thread. Your listener might update some data and change the page. Then the browser must work out styles and layout again before it can show the next picture on the screen. One such picture is called a frame.

Each of these steps is normal work. But if a long calculation sits in the middle, every step after it is late. The browser can't stop a running loop halfway to run your listener.

This doesn't mean every page needs workers. Short, simple code that runs straight through is usually the easiest to keep working. Change it only when users feel the delay. If the work grows with the amount of data, runs for many milliseconds, or makes typing feel late, you have three choices:

• Split it into smaller pieces.
• Run it later, when it is less urgent.
• Move heavy calculations to a worker.

Measure the page before you add any of these.

Why a slow script freezes a tab

Code that runs from start to end without stopping is called synchronous. A synchronous loop keeps the main thread until the loop ends. While it runs, the main thread can't start a click handler.

The browser still notices your click. But the page code that answers the click must wait until the current task ends.

1const start = Date.now();2while (Date.now() - start < 50) {}3console.log("done after about 50 ms");

Date.now() gives the current time as a number of milliseconds. Line 1 saves that time in start. Line 2 checks the time again and again until 50 milliseconds have passed. Its body, {}, is empty, so the loop only waits. Line 3 prints done after about 50 ms. During those 50 milliseconds, the page can't answer a click, because the main thread is still on line 2.

The exact time depends on the device, so don't use this code to measure speed. The part that is always true is the order: synchronous JavaScript finishes before a later click handler on the same main thread can run. That is why one slow script can make one tab feel frozen. Other tabs and the browser's own buttons still work.

The step-through below shows the same order with a small list of two tasks: a long script, then a click handler.

1const tasks = ["long script", "click handler"];Run2let finished = "";3 4function runNext() {5  finished = tasks.shift() ?? "";6  return finished;7}8 9console.log(runNext());10console.log(runNext());

Split long work so clicks can run

Some big jobs can be cut into parts. For example: going through a long list, building a report, or updating many items on the screen. Each part is called a chunk.

Instead of one long task, run one small chunk. Then yield: give the main thread back to the browser for a moment. The browser can now run a click handler, draw the screen, or do other waiting work. Then the next chunk runs.

1const chunks = ["chunk 1", "click handler", "chunk 2"];2const completed = [];3 4for (const task of chunks) {5  completed.push(task);6}7 8console.log(completed.join(", "));

Line 1 lists the work in the order it runs: a chunk, then the click, then another chunk. Line 2 starts an empty list called completed. Lines 4 and 5 go through the work and add each item to completed as it finishes. Line 8 joins the list with commas and prints chunk 1, click handler, chunk 2.

This code only shows the order. In a real browser, the browser picks what runs next, and no browser feature promises this exact order.

Some heavy calculations stay big even when you split them. For those, use web workers. A worker runs JavaScript on its own thread, apart from the main thread. But sending data to a worker takes time. So first measure whether splitting or moving the work really makes the page answer faster.

1const chunks = ["chunk 1", "click handler", "chunk 2"];Run2const completed = [];3 4for (const task of chunks) {5  completed.push(task);6}7 8console.log(completed.join(", "));

Compositor and raster threads draw the page

After the main thread decides how the page looks, Chrome splits the page into layers. A layer is a flat sheet with part of the page drawn on it, like a list that scrolls. Two more kinds of threads take over:

• Raster threads turn each layer's drawing into pixels. They often work in small squares called tiles.
• The compositor thread stacks the layers into one finished picture: a frame.

Then the GPU helps show that frame on the screen.

1const mainThreadBusy = true;2const layerIsReady = true;3 4const canScroll = layerIsReady;5console.log(canScroll ? "compositor can move layer" : "main thread work needed");

Line 1 says the main thread is busy. Line 2 says a layer is already drawn and ready. Line 4 copies that answer into canScroll. Whether the main thread is busy doesn't matter here. Line 5 prints compositor can move layer.

This shows an important exception. Scrolling, and some animations, can keep going without waiting for JavaScript on the main thread.

The compositor can't do everything. If a change needs new styles, new layout, or a new drawing, the main thread must do that work first. Read the rendering pipeline for every step from HTML and CSS to layers and pixels. Read rendering performance to learn how to measure it.

A layer helps when the browser can reuse pixels it already drew. It then only moves the layer, or changes how see-through it is. Scrolling is the everyday example: the compositor makes a new frame from pixels that were drawn earlier. Some animations of transform and opacity can work the same way. Each browser decides which animations can do this, so test it. CSS does not promise it.

Turning drawings into pixels is still real work. Large images, text, shadows, and other heavy effects can need many pixels. The compositor picks what to do first and stacks the results. But it can't show a layer that hasn't been drawn yet. So a fast page usually needs both: short work on the main thread, and changes that need little new layout or drawing.

What to do when a page feels slow

Start with what the user notices. A click that answers late usually means the main thread is busy. It rarely means you need another renderer. A slow scroll can have several causes:

• scroll listeners that run on the main thread,
• new drawing work,
• or a layer that the compositor can't move by itself.

Knowing the browser's parts helps you ask good questions. A performance trace tells you which answer is true. A trace is a recording, made with the browser's developer tools, of what each thread did and when.

• Keep input handlers short. Run work that isn't urgent later.
• Split long calculations into small chunks when it is safe to pause between them.
• Use a web worker for long, heavy calculations that don't need to touch the page.
• Record a trace with the browser's performance tools before you blame a process or a thread.
• Animate transform and opacity when you can, but measure the whole drawing work first.

A slow renderer usually hurts only its own tab or site. In a browser with just one process, it could slow down everything. But that is about safety, not speed. Your page still has one main thread with limited time. A page can be kept apart from other sites and still be slow for its own users.

Read a trace like a story, not just a score. Find the click or key press that was answered late. Then look at the task that was running just before it:

• If that task is JavaScript, check how much data it handles. Then decide whether to shrink the work, split it into chunks, or move it to a worker.
• If the task is styles, layout, or drawing, check which change to the page caused it.

A drawing of the browser's parts can't replace this evidence.

Record a new trace after each change. A fix only counts when the same user action gets faster.

Be careful with quick fixes. Moving every calculation to a worker means copying data back and forth, and the code gets harder to follow. Adding layers everywhere uses more memory and more drawing work. Extra work on another thread doesn't make a stuck click handler on the main thread finish sooner. The goal is not "use more threads". The goal is "answer the user's next action soon enough".

Common misconceptions

• "One tab means one process." Chrome can use several processes for one tab. This happens most often when the tab has cross-site iframes.
• "Site Isolation gives every origin its own process." It usually splits by site, not by every origin or full web address. Pages on help.example.com and www.example.com are the same site, so they can share a renderer.
• "The compositor runs my JavaScript." It only stacks layers that are already drawn. Your normal page JavaScript runs on the main thread.
• "A long script freezes the whole browser." It usually freezes only the page work in its own renderer. Other processes, like other tabs and the address bar, keep working.
• "The GPU fixes every slow page." New styles, new layout, and new drawing still need the main thread.

These four words are easy to mix up. Each row says what one word means and gives an example from this lesson.

Practice exercises

console.log(1 + 1);

const order = ["script", "click"];
console.log(order.join(", "));

const mainThreadBusy = true;
const layerIsReady = true;
console.log(mainThreadBusy && layerIsReady ? "scroll" : "wait");

Check your understanding

Remember two things. Processes keep work apart and safe. But inside one renderer, one main thread still decides when page JavaScript and most drawing work can run.

Key takeaways

• In Chrome, the work is split into processes: the browser process, renderers, a network service, and a GPU process.
• Site Isolation in Chrome puts pages and iframes from different sites in separate sandboxed renderers.
• A renderer's main thread runs normal JavaScript, event listeners, styles, and layout.
• One long synchronous script makes a later click wait on that main thread.
• Raster threads turn layers into pixels, and the compositor thread stacks them into frames. They don't do the main thread's jobs: JavaScript, styles, layout, or deciding what to draw.
• Measure a slow click or key press before you choose chunks, workers, or drawing changes.

Coming next: What happens when you navigate.