How web browsers use process & Threads

Mohanatheesan Theiventhiram
4 min readJul 17, 2020

A process is an instance of program execution. A thread is the one that lives inside of process and executes any part of its process’s program. When we start an application, a process is created. The program might create threads to help it do work, but that’s optional. The Operating System gives the process a slice of memory to work with and all application state is kept in that private memory space. When we close the application, the process will be also finished and the Operating System frees up the memory.

Web browsers use process and thread to built them. It could be one process with many different threads or many different processes with a few threads communicating over Inter Process Communication (IPC). In the initial times, web browsers supported single process at a time while browsing. There was no concept of multiple tabs in a browser. There will be only one page in the browser and the user had to roam through that page for the desired web pages. With the development of processes and threads, web browsers took a new dimensions. It means, multi-process browsers were built.

Multi-process architecture in Chrome & Firefox

In the Chrome’s architecture, On top of all the processes, there will be a main process called browser process. Browser process will be divided into Render Process, Utility Process, GPU (Graphics Processing Unit) Process, and Plugin Process. Render Process will be divided into more processes and each process will be opened in separate tabs.

Chrome’s multi-process architecture

Browser process 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 process controls anything inside of the tab where a website is displayed.Plugin process controls any plugins used by the website, for example, flash. GPU processes handles GPU tasks in isolation from other processes. It is separated into different process because GPU handles requests from multiple apps and draw them in the same surface.

Different processes pointing to different parts of browser UI

The main advantage of multi-process architecture is that, when one process becomes unresponsive, it will not affect other processes. Chrome uses multiple renderer process. When Chrome is running on a powerful hardware, the multi-process architecture allows it to split the process into many, and it will make efficient use of main memory, without consuming over.

Chrome browser also uses multi-threads inside processes. Each process contain a main thread. There will be an IO thread in each process. In renderer processes, IO thread is responsible for Inter-Process Communication. It handles the network requests in browser process. Other than these two main threads, there are few more special threads and a pool of general purpose threads.

When we consider about Firefox, It was a single process browser in the beginning. It easily freezes the UI, and it might not be optimal from a security point of view. Then Mozilla introduced the multi-process architecture in the Firefox web browser. Firefox started to use multiple processes and all browser tabs run within the same process and the browser UI runs in its own individual process.

Mozilla has completed its transition to a multi-threaded web browser. Chrome and Firefox now both support multi-threading, but they do it in different ways. In Chrome, each and every tab we open gets its own content process. If 10 tabs are opened, then there will be 10 processes running. This will maximize the performance, but it will take a heavy memory consumption and, when the number of processes get increased. Firefox doesn’t take this approach to the problem, but instead spins up to four content process threads by default.

In Firefox, if 4 tabs are are opened, there will be 4 process running. If an additional tab is opened, it will run using threads within the existing processes. Multiple tabs within a process share the browser engine that already exists in memory, instead of each creating their own. This will reduce the memory consumption, as more memory needed if number of processes increased.