How web browser works step by step [Latest]— high-level architecture (part 1)

8 min readNov 10, 2019

TLDR;

If you have already know the concept of process and thread, feel free to jump directly to the navigation and the rendering.

To me, a browser was a black box. It eats my HTML, CSS, and JavaScript files, and displays a page. Somehow, it works.

Until one day, I decided to sit down and find out why.

When searching online, I cannot find much information. Tali Garsiel has put together a well-written one in 2011. Since then, the browser architecture has changed. Chrome has taken over about 65% of market share with its Blink engine, forking from WebKit in 2013. In the next 6 years, Chrome had evolved into a different architecture.

However, the essential part of browsers has not changed much. They are all based on processes and threads.

Open a website with Chrome, and take a look at its task manager. You can see a list of processes currently running.

Why it has so many processes with merely one tab open? That’s the question to decipher the black box.

Processes and threads

Threads are living in a process, along with data, codes, and files.

In a single-threaded process, well, there is only one thread. It is also the main thread of the process. A thread is a queue, processing tasks one by one. The next task has to wait until the earlier ones finish.

What is the risk? If one task has a problem and crashes, the whole thread stops, and it leads to the termination of the entire process.

In a multi-threaded process, the tasks can process faster in multiple threads simultaneously. All threads share the data in the memory.

If one of the threads stops, the process is terminated and exists.

Browser in early age

Before modern browsers exist, we used the single-process browser. IE6 was the most popular one.

There were no tabs in IE6. Each web page was allocated with a window because of the single-process limitation.

In a single-process browser, the process needs to take care of everything, including page rendering, JavaScript execution, and more.

This architecture brings three problems: instability, low performance, and insecurity.

Instability

When a thread crashes, the process stops, and the whole browser freezes.

JavaScript and Flash plugin is famous for crashing page thread. When it happens, forcing the browser to exit is the only solution. That’s what happened to our IE6 experience.

Low performance

Some JavaScript takes a while to finish. While executing the script, it blocks the page render thread. The browser has to wait until the script finishes execution and then proceed to display a page. The worst case is the infinite loop in JavaScript.

Moreover, the memory leak can lead to the performance issue. The browser kernel is complex. The garbage collection sometimes doesn’t work correctly. The longer you use the browser, the more memory is taken from your system, you feel the browser has an increasingly longer response time.

Insecurity

Evil plugins can easily gain access to your operating system with admin permission through the single-process browser. Besides, JavaScript can read sensitive information when you interact with the browser, like reading the input when you enter a password.

What are the solutions? Developers made multiprocess browsers, also known as modern browsers.

Multiprocess browser

In a multiprocess browser, well, we have multiple processes. Between processes, they communicate with Inter-process communication (IPC). Each process runs various threads.

Nowadays, we have the following processes running in a browser:
- Browser process
- Renderer process
- Plugin process
- GPU process
- Network process
- Device process
- Video process (one of the utility processes)
- Audio process (one of the utility processes)

It seems a lot, but let’s take a look at three essential ones: browser process, renderer process, and plugin process.

Here is an illustration of the processes and their “territory” on a browser.

There are two significant changes in the multiprocess architecture.
- Separating the renderer and plugin process from the browser process.
- Placing renderer and plugin processes in sandboxes.

Let’s see how these changes solve the problems in a single-process browser.

Fight against the instability

Modern browsers put renderer and plugin processes separate from the browser process.

The renderer process takes care of the page rendering and JavaScript execution. When it crashes, only the corresponding browser tab stops. You can still browse other tabs because the browser process remains intact.

This separation treatment applies to the plugins as well. Each plugin has a separate process. For example, if the Flash plugin crashes, it doesn’t affect your browsing experience anymore.

Improve the low performance

Each tab has a separate renderer process. When we open multiple tabs, the browser creates multiple renderer processes.

JavaScript from different pages are running in their own renderer process. If one of the pages has a JavaScript issue blocking its process, the problem does block page rendering in other tabs. Multiple plugin processes help in the same way.

How about the memory leak? Closing a tab triggers the garbage collection. All memory was taken will be released by the system.

Security with sandboxing

All high-risk components are moved to the renderer process and running in a sandbox, including HTML parsing, JavaScript virtual machine, and Document Object Model (DOM).

Meanwhile, system functionality is placed in the browser process, including persistence storage, user interaction, and networking.

Vicious codes in renderer and plugin processes are difficult to touch your operating system.

For example, a renderer process or plugin process cannot request resources from the network and file system directly in a sandbox. The browser process will take care of the request, and makes sure to proceed in a secure method.

Here is a full list of what renderer process and browser process doing from The Security Architecture of the Chromium Browser.

The renderer process takes care of
- HTML parsing
- CSS parsing
- Image decoding
- JavaScript interpreter
- Regular expressions
- Layout
- Document Object Model
- Rendering
- SVG
- XML parsing
- XSLT

The browser process takes care of
- Cookie database
- History database
- Password database
- Window management
- Location bar
- Safe Browsing blacklist
- Network stack
- SSL/TLS
- Disk cache
- Download manager
- Clipboard

Latest improvements on the browser architecture

Site isolation

In 2018, Chrome released [site isolation](https://www.chromium.org/Home/chromium-security/site-isolation) feature to protect the users from security bugs.

A cross-site iframe used to share the same renderer process on the page, meaning it has access to the same memory space. With Meltdown and Spectre, cross-site iframes could bypass the Same Origin Policy.

Since Chrome 67, all cross-site iframes get a stand-along renderer process. In 2019, Firefox starts Project Fission, a project related to integrating the site isolation feature.

Same-site shares the renderer process

Multiple renderer processes require more resources from your computer because each renderer process holds a copy of shared infrastructure in memory.

In a way, these copies are redundant in memory. At the same time, they are the trade-off of security and performance. When you open 1,000 tabs in your browser, 1,000 renderer processes could cause performance issues.

To minimize the performance impact, the browser tries to reuse an existing renderer process when you visit websites with the same domain.

For example, when you visit the Medium website, your browser creates a renderer process for it. Then you click a link on the site which opens a new tab, the browser will reuse the same renderer process.

This rule doesn’t apply when you manually open a new tab and entering a URL from the same domain. In this case, the browser creates a new renderer process for it.

Architecture in 2021 and the future

Chrome now has more processes running separately.

Besides the browser, renderer, and plugin processes, the team has separated the GPU, networking, and utility processes from the browser process. That’s the reason we see many processes are running with merely opening one tab.

By decoupling the processes, we made a faster and safer browser. The Chrome team decides to go further on this path.

Service-Oriented Architecture was initialized by the Chrome team, introducing the Chrome Foundation Service in the architecture. It is a modular architecture.

We have more processes in this architecture with sandboxes apply to most of them. More renderer processes mean taking more resources from your computer. The team also introduces graceful degradation when the laptop doesn’t have enough resources.

SOA is a bold move and will take the team years to complete the change. Currently, the team is progressively improving the browser toward the SOA.

What is the takeaway?

A browser is made of processes and threads. The complex browser mechanism is built on top of them.

Join Medium

Join Medium with my referral link - Carson

As a Medium member, a portion of your membership fee goes to writers you read, and you get full access to every story…

cabulous.medium.com

Purchasing Medium Membership through the above link means that I can get income through the referral link. This does not mean that you have to buy from the link, nor does I deny or oppose other channels. It is your right to know.