How web browsers use Process & Threads

6 min readJul 17, 2020

How web browsers use Process and Threads

What is a web browser and its functionality?

A web browser is an application software that allows users to explore and view information on the web. We can explore them by simply entering the URL in the address bar of the browser. The main functionality of a web browser is to render web resources requested by the users by requesting from the server and displaying it in the browser window. Normally these resources are HTML documents, PDFs, images, videos, etc. The location of the resources is specified by the user using a URI (Uniform Resource Identifier). In the earlier stage browsers are based on text but now browsers are also available with graphics and voice. Some major browsers use in the present are Chrome, Firefox (both of them are open-source), Internet Explorer, Opera, Safari (partly open-source).

What are threads and processes?

When a user requests web resources from the browser, the browser will render them. But the sequence of process is running behind that. The essential part of this process is based on processes and threads. A thread is a path of execution within a process or sequence of programmed instructions that can be managed independently by a scheduler. A process is a program in execution that is done by one or many threads. It contains the program code and its activity. Thread is also known as a lightweight process. The main difference between these two is that processes run in separate memory spaces but threads run within the same process in shared memory space.

Single-threaded process and Multi-threaded process

There are two kinds of process types. Single-threaded processes are the execution of instructions in a single sequence, which means one thread is processed at a time. Multi-threaded processes are the execution of multiple functions of a program at the same time, which means more threads are available within the process.

The Architecture of Web Browsers

As I mentioned previously, there are many browsers in our usage. There implementation different from one to another. But three main components are available in all browsers.

Controller/ Dispatcher — Works as a control unit in a CPU and works on inputs it receives.

Interpreter — Get instructions from the controller and execute them line by line.

Client Programs — Uses specific protocols to access particular services.

Earlier web browsers are made on a single-process. In that, the single process needs to take care of all the activities. Because of that, this architecture made more problems like low performance. After a certain period, we are now using multi-process browsers. In these, processes communicate with each other through Inter Process Communication (IPC). Inside each process, different threads are running.

Browser Architecture of Chrome Browser

Among processes happen in the browser, the Browser process, Render process, and Plugin process are important. The browser process is in the top coordinating with other processes of the application. It controls address bar, bookmarks, back and forward buttons, and 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. The plugin process controls any plugins used by the website like Flash. GPU process handles GPU tasks in isolation from other processes. This is separated into a different process because GPU handles requests from multiple applications and draws them on the same surface.

When we consider threads used in the Chrome process,

· Main thread - In the browser process it updates the UI and in the renderer processes it runs most of Blink
· IO thread - In the browser process it handles IPCs and network requests and in the renderer processes it handles IPCs
· Few more special-purpose threads
· The pool of general-purpose threads

Most of these threads have a loop that gives tasks from a queue and this queue can be shared between multiple threads.

Browser Architecture of Firefox Browser

Below you can see the architecture view of the Firefox browser. This follows the layered architecture and we can see the dependencies on how functions work. The top layer consists of the user interface which depends upon the rest of the system to render the browser. The second layer, which is the UI layer is rendering resources and data processing. This layer consists of the Gecko and the Necko subsystems. The final layer is displaying backend. This provides proper GUI formatting information to Gecko. Because of that, pages can be rendered information properly in any platform according to the platform’s specifications.

In Firefox’s current architecture it includes

· One main process
· One GPU process
· One extension process
· Up to 4 content (tab) processes

The current default of 4 content processes might be changed in future versions of Firefox.

Browser Architecture of Internet Explorer Browser

In IE8, its multi-process architecture was introduced and it makes use of two types of processes.

One mainframe process
Zero or multiple tab processes

According to the configuration, IE can be limited to one process. “IE add-ons are binary Win32 DLLs that are loaded into the tab process(es). A crash in an add-on also crashes the tab process(es) that hosts it. The number of tab processes is auto-managed depending on the amount of RAM.”

Browser architecture of Internet Explorer

Chrome vs Firefox

As we all know Chrome and Firefox both using multi-threading in architecture. But they support it in different ways. In Chrome, when we open up a new tab, a new content process is opened. This approach makes high performance but problems in memory consumption and battery life. In Firefox, it spins up to four content process threads by default. If additional tabs are opened, they are run using threads within those processes. These multiple tabs within a process share the browser engine in the memory without creating their process contents. When considering the memory usage, Firefox is better than Chrome because it uses less memory for their process contents. Also, Firefox became faster than Chrome because you can do multiple works with other applications run in your computer or laptop while using the browser without stuck.

Browser Architecture of Chrome UI and Firefox UI

I hope you enjoyed this article and get some idea of how web browsers use processes and threads to render users’ requests. You can learn more through the below links.