How web browsers use process & Threads

Browser tabs to use separate processes to protect the overall application from bugs and glitches in the rendering engine. We also restrict access from each rendering engine process to others and to the rest of the system.

The main process that runs the UI and manages tab and plugin processes as the “browser process” or “browser.” Likewise, the tab-specific processes are called “render processes” or “renderers.” The renderers use the Blink open-source layout engine for interpreting and laying out HTML.

Managing render processes

Each render process has a global RenderProccess object that manages communication with the parent browser process and maintains a global state. The browser maintains a corresponding RenderProccessHost for each render process, which manages browser state and communication for the renderer. The browser and the renderers communicate using Chromium's IPC system.

Managing views

Each render process has one or more RenderView objects, managed by the, which correspond to tabs of content. The corresponding RenderProccessHost maintains a RenderViewHost corresponding to each view in the renderer. Each view is given a view ID that is used to differentiate multiple views in the same renderer. These IDs are unique inside one renderer but not within the browser, so identifying a view requires a RenderProccessHost and a view ID. Communication from the browser to a specific tab of content is done through these RenderViewHost objects, which know how to send messages through their RenderViewHost to the RenderProccess and on to the RenderView.

Components and interfaces

In the render process:

• The RenderProccess handles IPC with the corresponding RenderProccessHost in the browser. There is exactly one RenderProccess object per render process. This is how all browser ↔ renderer communication happens.
• The RenderView object communicates with its corresponding RenderViewHost in the browser process (via the RenderProcess), and WebKit embedding layer. This object represents the contents of one web page in a tab or popup window

In the browser process:

• The Browser object represents a top-level browser window.
• The RenderProccessHost object represents the browser side of a single browser ↔ renderer IPC connection. There is one RenderProccessHost in the browser process for each render process.
• The RenderViewHost object encapsulates communication with the remote RenderView, and RenderWidgetHost handles the input and painting for RenderWidget in the browser.

Sharing the render process

In general, each new window or tab opens in a new process. The browser will spawn a new process and instruct it to create a single RenderView.

Sometimes it is necessary or desirable to share the render process between tabs or windows. A web application opens a new window that it expects to communicate synchronously, for example, using window.open in JavaScript. In this case, when we create a new window or tab, we need to reuse the process that the window was opened with. We also have strategies to assign new tabs to exist processes if the total number of processes is too large, or if the user already has a process open navigated to that domain.

Detecting crashed or misbehaving renderers

Each IPC connection to a browser process watches the process handles. If these handles are signaled, the render process has crashed and the tabs are notified of the crash. For now, we show a “sad tab” screen that notifies the user that the renderer has crashed. The page can be reloaded by pressing the reload button or by starting new navigation. When this happens, we notice that there is no process and create a new one.

Which process controls what?

The following table describes each Chrome process and what it controls:

Process and What it controls

Browser:- Controls “chrome” part of the application including address bar, bookmarks, back, and forward buttons. Also handles the invisible, privileged parts of a web browser such as network requests and file access.

Renderer: - Controls anything inside of the tab where a website is displayed.

Plugin:- Controls any plugins used by the website, for example, flash.

GPU:- Handles GPU tasks in isolation from other processes. It is separated into a different process because GPUs handle requests from multiple apps and draw them on the same surface.

Different processes pointing to different parts of browser UI

Mozilla FireFox Browser

In older versions of Firefox for desktop computers, the entire browser ran under a single operating system process. In particular, JavaScript that ran the browser user interface (also known as “chrome code”) and JavaScript that ran on web pages (also known as “content” or “web content”) were not separated.

Currently, the latest versions of Firefox launch the browser user interface and web content in separate processes. In the current iteration of this architecture, all browser tabs run in the same process, and the browser UI is launched in a separate process. Future iterations of Firefox will have more than one process designed solely for processing web content. The internal name of this project is called Electrolysis, sometimes abbreviated to e10s.

The good news is that regular web pages and their developers are unaffected by this move to multiprocessing Firefox. Unfortunately, people developing add-ons for Firefox or Firefox will be affected if their code relies on the ability to directly access web content as the way that data is accessed will change.

Google Chrome Browser

Chrome has a multi-process architecture and each process is heavily multi-threaded. The main goal is to keep the main thread (“UI” thread in the browser process) and IO thread (each process’ thread for handling IPC) responsive. This means offloading any blocking I/O or other expensive operations to other threads. Chrome has a multi-process architecture and each process is heavily multi-threaded. The main goal is to keep the main thread (“UI” thread in the browser process) and IO thread (each process’ thread for handling IPC) responsive. This means offloading any blocking I/O or other expensive operations to other threads.

Comparing Mozilla Firefox and Google Chrome Browsers

These two browsers are used multithreading. But you can see according to the browser architecture image, they use multithreading in different ways.

Let’s say you have 3 tabs open and each tab is run by an independent renderer process in chrome browser. if you open 10 tabs it uses 10 renderer processors. Because of that If one tab becomes unresponsive, then you can close the unresponsive tab and move on while keeping other tabs alive.

In Firefox, the first 4 tabs each use those 4 processes, and additional tabs run using threads within those processes. If many tabs are running on one process, when one tab becomes unresponsive, those tabs are unresponsive. That is a disadvantage.

If we consider memory usage of these two browsers in chrome, Each process has its own memory — with their own instance of the browser’s engine. One open tab in Chrome typically consumes hundreds of megabytes of RAM. Chrome’s liberal approach to creating processes can lead to very high memory usage. On the other hand, Firefox’s more conservative approach to using processes often results in Firefox using less memory than Chrome.because of that chrome gets too hot, but firefox does not.

Firefox uses less memory than other browsers.