How Web Browsers Work

The browser’s main purpose is present resources according the our requests. by requesting it from the server and displaying it on the browser window. Browsers functionality can be classified into four major sections and these include.

· Fetch

· Process

· Storage

· Display

This blog I mainly focused Process side. This step involves accepting data from the network layer and feed the display subsystems. Render engine, JS engine and UI backend subsystems are part of the process.

· The browser engine: marshals actions between the UI and the rendering engine.

· The rendering engine : responsible for displaying requested content.

· Networking: for network calls such as HTTP requests, using different implementations for different platform behind a platform-independent interface.

· UI Backend: used for drawing basic widgets like combo boxes and windows. This backend exposes a generic interface that is not platform specific. Underneath it uses operating system user interface methods.

· JavaScript interpreter. Used to parse and execute JavaScript code.

Single Processor Browser

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.

Multiple Processors

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

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

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.

Process-level: from the main to off-main thread

The main thread in the renderer process is always a handful.

It takes responsibility for all heavy-lifting tasks from DOM parsing and layout calculation to page events and user inputs. Its goal is delivering an updated bitmap on our display in a timely fashion.

To achieve a better performance, engineers start moving tasks used to run in the main thread to off-main threads.

The idea here is to free up the main thread as much as possible. With more tasks managed outside of the main thread, the browser can achieve more by doing less.

The off-main-thread idea is not new. Firefox team implemented off-main-thread paint in 2017. Instead of using the compositor thread, a new paint thread is added to run the painting phase. Chromium is probably to follow in 2020.

The any browser’s started first script part is running after that stylesheet is running. model of the web is synchronous. The parsing of the document halts until the script was executed. In Firefox While executing scripts, another thread parses the rest of the document and finds out what other resources need to be loaded from the network and loads them. but webkit doesnot have this feature. Next scripts asking for style information during the document parsing stage if not loaded yet Firefox will be blocks all scripts when there is a style sheet that is still being loaded and parsed. Webkit requests scripts before images even when the scripts appear later in the source code. Firefox calls the elements in the render tree “frames”.

Differences Between firefox & chrome

Firefox

Multi process architecture

RAM consumption is less then chrome

Safe lower then chrome

Good privacy

Crypto mining protection

Chrome

Multi process architecture and each process is multi-threated

RAM consumption is incredibly high

Saffer then firefox

Privacy lower then firefox

No crypto mining protection