Browser architecture
How are processes and threads organized in the browser? It can be a single-process structure containing multiple threads, or it can be a multi-thread structure, and each thread can contain multiple threads, and the process communicates with each other through IPC. As shown below:
There is no uniform standard for browser architecture, and different browsers may have completely different architectures. This article discusses the latest Chrome browser. Its architecture is shown in the figure below:
The top-level Browser Process is responsible for coordinating processes with different tasks. The Renderer Process is created for each TAB page in the browser and is created for each new TAB page opened. The biggest advantage of this is that the unexpected crash of one TAB will not affect the normal operation of other tabs. More recently, Chrome has experimented with assigning a process, including iframe, to each site. Here, we summarize the responsibilities of each process through a table:
| process | Duties and responsibilities |
|---|---|
| Browser | Controls address bar, bookmarks, back and forward buttons, Web requests, file access, etc |
| Renderer | Control everything in the tabs responsible for displaying the content of the site |
| Plugin | Control all plug-ins used by the site, such as Flash |
| GPU | Processing GPU tasks, GPU processes are completely isolated from other processes because they have to process requests from different applications |
In addition to these four processes, there may also be extension processes and utility processes. You can view all process information, including memory usage, CPU, network, and process ID, by clicking the menu button in the upper right corner of the browser – More Tools – Task Manager. As shown below:
The benefits of the browser’s multi-process architecture include security and sandbox mechanisms in addition to the previously mentioned TAB crashes. Since a process has a separate memory space, its memory consumption is significantly higher than that of multithreaded memory sharing within the same process. To save memory, Chrome limits the number of processes depending on your device’s memory and CPU configuration. When the number of processes reaches the maximum, multiple tabs from the same site are processed in the same process.
Chrome is pushing forward with an architectural update to the browser that attempts to run parts of the browser as a service, making it easy to split the browser into different processes or consolidate it into a single process.
The idea is that when Chrome runs on devices with powerful hardware resources, it will separate services into separate processes, providing greater stability. But when Chrome runs on devices with limited hardware resources, it consolidates services into a single process to save memory space.
Site isolation is a recently introduced feature in Chrome, where each cross-site IFrame runs in a separate rendering process. All we’ve talked about before is running one process per TAB, which allows cross-site processes to run in a single renderer, with different sites sharing the same memory space. There seems to be no problem running a.com and b.com in the same render process.
The same origin policy is the core security model of the Web, which ensures that a website cannot access data of other websites without permission. Bypassing the same origin policy is the main target of security attacks. Process isolation is one of the most effective ways to separate sites. Desktop Chrome has enabled site isolation since version 67, and each cross-site IFrame in a TAB gets a separate rendering process.
It all starts with the browser address bar
In the previous section we introduced the concept of processes and threads in the browser and the roles they play. In this section we’ll delve into the efforts of processes and threads to present web content.
Everything outside the TAB page is handled by the browser process. Browser processes include UI threads that draw browser buttons and input fields, Network threads that process network data, and storage threads that control the acquisition of information such as files. The URL entered by the user in the address bar is processed by the browser’s UI thread.
From entering the URL to rendering the final web content, there are several steps:
- Process the input
When the user enters the address bar, the UI thread first determines whether the input is a search field or a URL. The browser’s address bar doubles as a “search bar,” so the UI thread has to parse the input and hand it over to the search engine if it’s a search field or visit the corresponding website if it’s a URL.
- Start navigation
When the user types in the address bar and presses Enter, the UI thread initiates a network request to retrieve the web content, and the network thread finds the request and establishes a TLS connection using the appropriate protocol (such as DNS).
During this process, the network thread may receive a service redirect (such as HTTP 301), in which case the network thread notifts the UI thread that a redirect has occurred and then initiates another URL request.
- Read the response
Once the response body starts coming in, the network thread looks at the first few bytes of the stream information as necessary. The content-Type header of the response tells us what Type of response data is.
If the response is an HTML file, the data will then be sent to the renderer. If the response is a compressed file or some other type of file, it means it is a download request, so the response data will be sent to the download manager.
At this stage, the browser also performs a security check, and if the domain name and response data match a suspected malicious site, the network thread will display a warning message. In addition, CORB checks ensure that cross-site sensitive information does not enter the rendering process.
- Finding the render process
Once all the checks are done and the network thread confirms that the browser needs to navigate to the requested site, the network thread notifies the UI thread that the data is ready, and the UI thread then looks for the renderer process to render the page.
- Complete the navigation
Now that both the data and the renderer are ready, the browser process tells the renderer to submit the navigation. Once the browser process receives a message from the renderer confirming the submission of the navigation, it means that the navigation is complete and the document load phase begins.
During this process, the browser updates the relevant UI (such as address bar information, site security symbols, site ICONS, etc.) and records navigation history.
- Initial loading completed
Once the navigation is submitted, the renderer process loads the resources and renders the page. We’ll discuss in detail what happens at this stage in the next section. Once the renderer process “finishes” rendering, it sends an IPC to the browser process (this is after the onload event for all frames in the page has been fired and executed). The completion is quoted here because the client-side JavaScript can still load additional resources and render a new view later.
The above is just a simple navigation process, we will not discuss the case of navigation from one site to another.
How is the page rendered
The previous section mentioned that pages are rendered by a rendering process, so what exactly happens during page rendering? This is what this section is about.
The page rendering process involves many aspects of Web performance, and because of the complexity of the rendering process, this section is only an overview.
The renderer is responsible for everything that happens inside the TAB. In the render process, the main thread handles most of the code, and if you are using a Web worker or service worker, some of the JavaScript code is handled in the worker thread. Compositor and Raster threads are used for efficient and smooth rendering of pages.
The core job of the rendering process is to transform HTML, CSS, and JavaScript into a web page that users can interact with.
parsing
To turn your code into a web page, you first need to parse the HTML, CSS, and Javascript.
Build the DOM
When the renderer process starts to receive HTML data, the main thread parses the HTML and converts it into a DOM (Document Object Model). The DOM is the browser’s internal representation of the page, and it provides the data structure of the page and JavaScript apis for manipulating the DOM to front-end developers. The HTML specification defines rules for parsing HTML.
Resource to load
Websites often use external resources such as images, CSS, and JavaScript. These files need to be loaded from the network or cache. The main thread can request them one by one as it parses the build DOM, but for speed, a preload scanner is performed at the same time as the build DOM is parsed. If a tag such as
JavaScript blocks parsing
During HTML parsing, if a
How does the browser load the resource
To better load resources and avoid blocking HTML parsing, there are several common ways to specify how a browser loads resources.
<script>The tag properties async and defer load resources asynchronously, and the difference between the two is when the JavaScript code executes- JavaScript modules, also known as “ES modules” or “ECMAScript modules,” are native to the browser, and modular scripts automatically load lazily, similar to the effect of the defer property
<link rel="preload">Preloading, which indicates which resources are needed immediately after the page is loaded, allows resources to be loaded and available earlier
Style calculation
DOM is not enough to know what a page looks like. A page without CSS is just plain old, and it’s hard to look at. The main thread parses the CSS and calculates computed style (computed Style) for each DOM node, which represents style information applied to each element based on CSS selectors, You can see all the Computed styles in the Elements panel of the browser developer tools in the Computed section.
Even if you don’t provide any CSS, each DOM node will have a default computed style. The < H1 > tag content is larger than the < H2 > tag content, and both have margins. This is because browsers have default stylesheets. To see Chrome’s default CSS, click here.
layout
Now the rendering engine knows the structure of the page and the style of each node, but not enough to render the page. Imagine describing a painting to your friend via voice mail, “with a big red circle and a small blue rectangle.” Your friend would be stunned.
Layout is the process of finding the geometric dimensions of elements. The main thread processes the DOM and evaluates the style and creates a layout tree that contains information about x and Y coordinates and the size of the border box. A layout tree is similar to a DOM tree, except that it contains only visible elements. Elements whose display: None style is applied do not appear in the layout tree, while visibility: Hidden does. In addition, content created through pseudo classes is included in the layout tree even though it does not exist in the DOM.
Page layout is a complex task. Even simple block-level streams like those arranged from top to bottom need to take into account the size of the font and where the line breaks, as these can affect the size and shape of paragraphs and thus the position of subsequent paragraphs. Click to view animation
Layouts are often referred to as backflow, and backflow occurs when we scroll, scale, or manipulate DOM elements. Here is a list of events that trigger element backflow.
draw
With DOM, there is still no way to draw a page with style and layout. Suppose you want to copy a painting. You know the size, shape and position of the elements, but you still need to judge the order in which to draw them.
For example, you might have a Z-index set for some elements, in which case the page is actually drawn in a different order than it would be in HTML.
At the draw step, the main thread traverses the layout tree to create a draw record, which is a record of the drawing process, such as “background first, text then rectangle”. If you’ve ever used JavaScript to draw a
synthetic
How to draw a page
Now that the browser knows the structure of the document, the style of each element, the geometry of the page, and the order in which it is drawn, how do you draw the page? The process of converting this information into pixels on the screen is called grilling.
The simplest way to do this is to grille the contents of the view. If the page scrolls, move the grated frames and grille the rest of the frame to fill in the white space caused by the page scrolling. Click to view animation
What is composition
Compositing is a technique for splitting pages into layers, rasterizing them separately, and compositing the pages in a separate compositing thread. All it has to do is compose a new frame. Animation can be done in the same way, moving layers and compositing a new frame.
In the Browser developer tools menu, More Tools-Layers, you can see how a web page divides Layers.
Split into layers
To figure out which elements need to be on which layer, the main thread iterates through the layout tree to create a layer tree.
You might want to assign a layer to each element, but composing too many layers can be slower than grilling a small portion of the page in each frame, so it’s important to consider your application’s rendering performance.
Grille and composition off the main thread
Once the layer tree is created and the drawing order determined, the main thread submits this information to the composition thread, which grilles each layer. A layer can be as large as the length of the entire page, so the composition thread will break them into tiles and send each tile to the raster thread. The grid thread rasterizes each tile and stores them in GPU memory.
At this point, the entire rendering process of the page is concluded with an image.
reference
- Developers.google.com/web/updates…
- Developers.google.com/web/updates…
- Developers.google.com/web/updates…
- Medium.com/jspoint/how…