Navigation flow: What happens between entering the URL and presenting the page?

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.

As soon as the browser starts loading an address, the icon on the TAB becomes loaded. You need to wait for the document submission stage before the page content is replaced.

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

Upon receiving the response header from the server, the network process begins to parse the response header. If the status code returned is 301 or 302, the server needs the browser to redirect to another URL. The network process reads the redirected address from the Location field in the response header, then initiates a new HTTP or HTTPS request and starts all over again.

(2) Response data type processing

The Content-Type is a very important field in the HTTP header that tells the browser what Type of response body data the server is returning. The browser then uses the value of the Content-Type to decide how to display the response body Content.

The value of the Content-Type field is text/ HTML, which tells the browser that the server is returning data in HTML format.

The content-type value is application/octet-stream, and the display data is byte stream. Normally, the browser will handle the request according to the download Type.

If the value of the Content-Type field is determined by the browser to be a download Type, the request is submitted to the browser’s download manager and the navigation of the URL request ends. But if it’s HTML, the browser will continue with the navigation process.

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.

We define “same site” as the root domain name (for example, geekbang.org) plus the protocol (for example, https:// or http://), plus all subdomain names and different ports under the root domain name, all belonging to the same site.

Chrome’s default strategy is one render process per TAB. However, if a new page is opened from one page and belongs to the same site as the current page, the new page will reuse the parent page’s rendering process. Officially, this default policy is called process-per-site-instance.

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.

5. Rendering phase

Once the document is submitted, the rendering process begins page parsing and subresource loading, which I’ll cover in the next article. The only thing you need to know here is that once the page is generated, the renderer will send a message to the browser process, which will stop the loading animation on the TAB icon when it receives the message.