Intensive reading "In-depth understanding of modern browsers II"

Inside look at modern web browser is a series of articles that introduces the principle of browser implementation. There are 4 articles in total. This intensive reading introduces the second article.

Overview

This article focuses on what after the 161ad7cc223309 browser route jumps to . The next article will introduce how the browser's rendering process renders web pages, which are interlocking.

In the previous article, the browser process includes UI thread, network thread, and storage thread. When we enter the URL in the browser menu bar and press Enter, this set of actions are all responded to by the UI thread of the browser process.

Next, according to several different routing jump scenarios, the internal processes are introduced respectively.

Normal jump

In the first step, the UI thread responds to the input and determines whether it is a legal URL. Of course, the input may also be a search protocol, which will lead to distribution to another service for processing.

In the second step, if the input in the first step is a legal URL, the UI thread will notify the network thread to obtain the content of the web page, and the network thread will find a suitable protocol to process the network request. Generally, it will be addressed through the DNS protocol , and through the TLS protocol establishes a secure link. If the server returns such as 301 redirect information, the network thread will notify the UI thread of this information, and then start the second step again.

The third step is to read the response content. In this step, the network thread first reads some bytes in the header, which is what we often call the response header, which contains Content-Type tell what the returned content is. If the returned content is HTML, the network thread will transmit the data to the renderer process. This step will also check the security, such as CORB or cross-site problem.

The fourth step is to look for the renderer process. Once all checks are completed, the network thread will notify the UI thread that it is ready to jump (note that all data has not been loaded at this time, and the third step is just checking the first byte), and the UI thread will notify the powerful renderer process to perform rendering . In order to improve performance, the UI thread notifies the network thread at the same time it will implement a renderer process and wait. Once the network thread is completed, it can enter the rendering stage immediately. If the check fails, the pre-instantiated renderer process will be discarded.

The fifth step is to confirm the navigation. After the fourth step, the browser process transmits stream ( intensive reading "web streams" ) data to the renderer process through IPC. At this time, the navigation will be confirmed, and the various statuses of the browser (such as navigation status, forward and backward history) will be modified. At the same time, in order to facilitate quick recovery after the tab is closed, the session record will be stored on the hard disk.

Additional steps, loading is complete. When the renderer process is loaded (what you did in the next article will be explained), the browser process onLoad event will be notified. At this time, the browser has finished the final loading state, the loading circle will disappear, and various onLoad callbacks will be triggered. Note that js may continue to load remote resources at this time, but this is all after the loading state is completed.

Jump to another website

When you are ready to jump to another website, before performing the normal jump process, you will also respond to the beforeunload event. This event is registered in the renderer process, so the browser process needs to check whether the renderer process has registered this response. Registering beforeunload will slow down the tab closing speed anyway, so please do not register if it is not necessary.

If the jump is issued by js, then the execution jump is triggered by the renderer process, and the browser process is executed, and the subsequent process is a normal jump process. It should be noted that when the redirect is executed, events such as unload page life cycle ) will be triggered, so this is responded by the old renderer process, and the new website will create a new renderer process for processing. When all are closed, the old renderer process will be destroyed.

In other words, even if there is only one tab, there may be multiple renderer processes in a short period of time when jumping.

Service Worker

Service Worker can execute some logic before the page loads, and even change the content of the web page, but the browser still implements the Service Worker in the renderer process.

When the Service Worker is registered, it will be thrown into a scope. When the UI thread is executed, it will check whether the scope is registered with the Service Worker. If so, the network thread will create a renderer process to execute the Service Worker (because it is js Code). Then the network response will be taken over by the Service Worker.

But this will be a step slower, so the UI thread will often tell the network thread to send the request while registering the Service Worker. This is the Navigation Preload mechanism.

This article introduces the steps that occur when a webpage jumps, involving the collaboration of browser process, UI thread, network thread, and renderer process.

intensive reading

You may have questions, why is the renderer process instead of the renderer thread? Because compared to process (process) and thread (thread), the data between them is isolated by the operating system, so that the data cannot be read from each other between web pages (mysite.com reads the account password you are typing in baidu.com), browse The browser must create an independent process for each tab, and even each iframe must be an independent process.

After reading the second chapter, you should be able to feel more deeply the importance of a reasonable division of labor between modules.

UI thread handles the display of the browser UI and user interaction, such as current loading state changes, history forward and backward, browser address bar input, verification and monitoring of Enter press events, but does not involve such events as sending requests and parsing web pages Content, rendering, etc.

The network thread also only deals with network-related matters. It is mainly concerned with communication protocols and security protocols. The goal is to quickly and accurately find the website server and read its content. The network thread will read the content header to make some pre-judgments. There is a certain overlap between the content read and the things done by the renderer process, but the network thread reads the content header only to determine the content type, so that it can be passed to the rendering engine or the download manager (For example, a zip file), so in order to prevent the rendering engine from knowing the existence of the download manager, the content header must be read by a network thread.

The communication with the renderer process is also done by the browser process, that is, once UI threads and network threads are created or communicate with the renderer process, they will be handled by the browser process where they are located.

The renderer process only processes the rendering logic. It does not care where it comes from, such as the network request or the modification after the Service Worker intercepts it. It does not care what the current browser state is. It just follows the agreed interface specification. The specified node throws a callback, and other modules concerned are responsible for modifying the application state. For example onLoad callback is triggered, the browser process processing the state of the browser is an example.

Another example is that a new jump link is clicked in the renderer process. This event occurs in the renderer process, but it will be handled by the browser process. Because each module is completely decoupled, any complex work can be found to respond to it. This module only needs to handle part of this complex work, and the rest is handed over to other modules. This is the secret of large-scale application maintenance.

Therefore, in the browser operating cycle, there are very clear logical links. These modules must be planned and designed in advance. It is difficult to imagine that the division of labor of these modules is gradually formed during development.

Finally, when it comes to speeding up optimization, Chrome’s idiomatic trick is to trade resources for time. That is, I would rather waste potential resources, but also make things as concurrent as possible, which can be seen from the creation of the renderer process in advance and the initiation of the network process in advance.

Summarize

In-depth understanding of modern browsers II introduces how the browser process and the renderer process work together when a web page jumps.

Maybe this article can help you answer "Let’s talk about what happened after typing www.baidu.com in the browser address bar and pressing Enter!"

The discussion address is: Intensive Reading "Understanding Modern Browsers II" · Issue #375 · dt-fe/weekly

If you want to participate in the discussion, please click here , a new theme every week, weekend or Monday. Front-end intensive reading-to help you filter reliable content.

Follow front-end intensive reading WeChat public

<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">

Copyright notice: Freely reproduced-non-commercial-non-derivative-keep the signature ( Creative Commons 3.0 License )