Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser

An overview of the

This article focuses on what happens after the browser route jumps, and the next one will look at how the browser’s rendering process renders the page, one after the other.

As described in the previous article, the Browser process includes UI threads, Network threads, and storage threads. When we enter the URL in the browser menu bar and hit Enter, These actions are responded to by the UI Thread of the Browser Process.

Next, the internal process is introduced according to several different routing jump scenarios.

Normal jump

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

In the second step, if the legal WEBSITE is entered in the first step, THE UI Thread will notify the Network thread to obtain the web content, and the Network thread will search for an appropriate protocol to process the network request. Generally, DNS protocol will be used to address and TLS protocol will be used to establish a secure link. If the server returns, for example, a 301 redirection message, the Network Thread informs the UI thread of this message and initiates step 2 again.

The third step is to read the Content of the response. In this step, the Network Thread will first read the first few bytes, commonly known as the response header, which contains the Content-Type to tell us what the returned Content is. If the returned content is HTML, the Network Thread passes the data to the Renderer process. This step also verifies security, such as CORB or cross-site problems.

The fourth step is to find the Renderer process. Once all checks are complete, the Network Thread notifies the UI thread that it is ready to jump (note that not all data has been loaded; step 3 only checks the first byte), and the UI Thread notifies the power Renderer process to render. In order to improve performance, UI threads will activate a renderer process while notifying network threads. Once network threads are completed, they can immediately enter the rendering stage. If the check fails, the pre-instantiated Renderer process is discarded.

Step 5, confirm the navigation. After the fourth step, the Browser Process sends a stream of data to the Renderer Process via IPC. The navigation is confirmed, various browser states (such as navigation state, forward and backward history) are modified, and session records are stored on the hard disk for quick recovery after the TAB is closed.

Additional steps, loading complete. When the Renderer Process is loaded, the Browser process onLoad event is notified, the browser is finished loading, the loading circle disappears, and various onLoad callbacks are triggered. Note that the JS may continue to load the remote resource at this point, but only after the loading state is complete.

Jump to another site

When you are ready to jump to another site, you also respond to the beforeUnload event registered with the Renderer process before performing the normal jump process. So browser process needs to check if the Renderer process has registered the response. Register beforeUnload will slow down closing a TAB anyway, so do not register if necessary.

If the jump is issued by JS, then the renderer process triggers the jump, the Browser Process executes it, and the subsequent flow is a normal jump flow. Note that when a jump is performed, events such as an unload for the original site (page life cycle) are triggered, so this is handled by the old Renderer Process, and the new site creates a new Renderer process. When the old page is all closed, The old Renderer process is destroyed.

That is, even if there is only one TAB, multiple Renderer processes can exist for a short period of time when jumping.

Service Worker

The Service Worker can perform some logic before the page loads and even change the content of the page, but the browser still implements the Service Worker in the Renderer process.

When a Service Worker is registered, it will be thrown into a scope. When the UI Thread executes, it will check whether the scope is registered with the Service Worker. If so, The Network thread creates a Renderer process to execute the Service Worker (because it’s JS code). The network response is then taken over by the Service Worker.

However, this is a step slower, so UI threads usually register the Service Worker and tell the network thread to send the request. This is called Navigation Preload mechanism.

This article introduces the steps that occur when a web page jumps, involving the cooperation of Browser Process, UI Thread, Network Thread and Renderer Process.

Intensive reading

You might wonder, why renderer Process and not Renderer Thread? The browser must create a separate process for each TAB in order that web pages cannot read each other’s data (mysite.com reads the password your baidu.com is entering). Even each iframe must be a separate process.

After reading the second chapter, we should be able to feel the importance of reasonable division of labor among modules.

UI Thread processes the display and user interaction of the browser UI, such as the change of the current loading state, the history forward and backward, the browser address bar input, verification, and listening events such as press Enter, but does not involve the sending of requests, parsing web content, rendering and other contents.

Network Thread only deals with network-related matters. It is mainly concerned with communication protocol and security protocol. Its goal is to quickly and accurately find the website server and read its content. Network threads read content headers to make some prejudgment. There is some overlap between what they read and what the Renderer process does. However, network threads only read content headers to determine the type of content. In order to pass it to the rendering engine or the download manager (such as a ZIP file), the network Thread must read the content headers in order to keep the rendering engine unaware of the download manager’s existence.

Communication with the Renderer process is also handled by the Browser Process, i.e., UI threads and network threads. Once they create or communicate with the Renderer process, All are processed by the Browser process they are in.

The Renderer process only deals with the rendering logic. It doesn’t care where it came from, such as a network request, or a Service Worker intercept, or what the current browser state is. It just throws callbacks at the specified node according to the convention interface specification. Modifying the application state is the responsibility of other concerned modules, such as the Browser process handling the state of the browser after the onLoad callback is triggered.

If a new jump link is clicked in the Renderer Process, this happens in the Renderer process, but is handled by the Browser Process. Because each module is completely decoupled, any complex task can be found with a module that responds to it. This module handles only part of the complex work, leaving the rest to other modules, which is the secret of maintaining large applications.

So in the browser lifecycle, there is a very clear logical link, and these modules have to be planned and designed in advance, and it’s hard to imagine that these modules are developed over time.

Finally, when it comes to accelerated optimization, Chrome’s favorite trick is to trade resources for time. It is better to waste potential resources and make things as concurrent as possible, as can be seen from creating renderer processes and launching network processes ahead of time.

conclusion

An in-depth look at modern browsers ii introduces how the Browser process and renderer process work together when web hops occur.

Maybe this article will help you answer the question “Tell me about what happens when you type www.baidu.com into your browser’s address bar and press Enter!”

The discussion address is: close reading “In-depth Understanding of modern Browsers ii” · Issue #375 · dt-fe/weekly

If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.

Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)