Enter the URL from the page to display the complete flow diagram of the page

As you can see, the process requires coordination between processes, so before we start the formal process, let’s quickly review the main responsibilities of the browser process, renderer process, and web process.

  • Browser processes are responsible for user interaction, child process management, and file storage.
  • Web processes are web downloads for renderers and browser processes.
  • The rendering process is mainly responsible for parsing HTML, JavaScript, CSS, images and other resources downloaded from the Web into pages that can be displayed and interacted with. Because all the contents of the renderer process are obtained through the network, there will be some malicious code to exploit browser vulnerabilities to attack the system, so the code running in the renderer process is not trusted. This is why Chrome makes the rendering process run in a security sandbox, just to keep the system safe.

After reviewing the browser process architecture, let’s look at the complete process in the figure above. As you can see, there are many steps involved in the process, and I’ve highlighted some of the core nodes on a blue background. The process can be roughly described as follows.

  • First, the browser process receives the URL request entered by the user, and the browser process forwards the URL to the network process.
  • The actual URL request is then made in the network process.
  • The network process then receives the response header data, parses it, and forwards it to the browser process.
  • After receiving the response header data from the network process, the browser process sends a “CommitNavigation” message to the renderer process.
  • After receiving the “submit navigation” message, the renderer process is ready to receive THE HTML data by directly establishing a data pipeline with the network process.
  • Finally, the renderer process “confirms submission” to the browser process, which tells the browser process that it is ready to accept and parse the page data.
  • When the browser process receives a “submit document” message from the renderer, it removes the old document and updates the page state in the browser process.

From entering URL to page display

1. User input

  • When a user enters a query keyword in the address bar, the address bar determines whether the entered keyword is the search content or the requested URl.
  • When the user enters the keyword and enters Enter, it means that the current page is about to be replaced with a new page, but before the process continues, the browser also gives the current page the opportunity to perform a beforeUnload event, which allows the page to perform some data cleaning before exiting. Users can also be asked if they want to leave the current page, for example if the current page may have unfinished forms, so users can unnavigate by using the beforeUnload event without the browser doing any subsequent work.

2. URL request process

  • Next, you enter the page resource request process. In this case, the browser process sends the URL request to the network process through interprocess communication (IPC). After receiving the URL request, the network process initiates the actual URL request process here. So what’s the process?
  • First, the network process looks up whether the local cache has cached the resource. If there is a cached resource, it is returned directly to the browser process. If the resource is not found in the cache, the network request flows directly. The first step before the request is to perform a DNS resolution to get the server IP address for the requested domain name. If the request protocol is HTTPS, you also need to establish a TLS connection.
  • The next step is to establish a TCP connection with the server using the IP address. After the connection is established, the browser side will construct the request line, request information, etc., and attach the data related to the domain name, such as cookies, to the request header, and then send the constructed request information to the server.
  • After receiving the request information, the server generates response data (including response line, response header, and response body) based on the request information and sends it to the network process. After the network process receives the response line and header, it parses the contents of the header. (For the sake of illustration, I refer to the response headers and response rows returned by the server as response headers below.)

(1) Redirect

(2) Response data type processing

3. Prepare the rendering process

By default, Chrome assigns a render process to each page, meaning that a new render process is created for each new page opened. However, there are some exceptions, in some cases the browser will allow multiple pages to run directly in the same render process.

For example, I opened up another page from geek Time’s home page, Algorithmic Boot Camp. Let’s take a look at Chrome’s task Manager screenshot below:

Multiple pages run in a render process

As you can see from the figure, the three open pages are all running in the same render process with the process ID 23601.

To summarize, the rendering process strategy used to open a new page is:

  • Typically, a separate rendering process is used to open a new page;
  • If so, then B page reuse A page render process; If otherwise, the browser process creates a new renderer for B.

Once the renderer process is ready, it cannot immediately enter the document parsing state because the document data is still in the network process and has not been submitted to the renderer process, so the next step is to submit the document.

4. Submit documents

Submitting a document means that the browser process submits the HTML data received by the web process to the renderer process. The process looks like this:

  • First, when the browser process receives the response header data from the network process, it sends a “submit document” message to the renderer process.
  • After receiving the “submit document” message, the renderer process establishes a “pipeline” with the network process to transfer data.
  • After the document data transfer is complete, the renderer process returns a “confirm submit” message to the browser process.
  • After receiving the “confirm submission” message, the browser process updates the browser interface status, including the security status, the URL of the address bar, the historical status of forward and backward, and the Web page.

This explains why, when you type an address into your browser’s address bar, the previous page doesn’t disappear immediately, but instead takes a while to load before the page is updated.

5. Rendering phase

Once the document is submitted, the renderer process begins page parsing and child resource loading. Once the page is generated, the renderer process sends a message to the browser process, which stops the loading animation on the TAB icon after receiving the message.