In the last post, we know a web browser is made of all kinds of processes. It was a static view of a web browser architecture.
However, a browser is not static. It is proactively response to user interactions. When we interact with a browser, different processes start working together as a team and, finally, display a web page in front of us.
In this post, we will see how processes work together in navigation.
The navigation is the next black box we will dive in. The input is a URL, and the output is a web page.
A high-level view of 5 steps
Briefly, the 5 steps are:
- Handling user input
- Sending a URL request
- Preparing a renderer process
- Committing navigation
- Rendering page
In these steps, three processes in the browser are involved:
- The browser process handles user input (step 1). Also, it manages the other processes (step 3).
- A network process takes care of the URL request (step 2).
- A renderer process focuses on rendering a page (step 4 and 5).
Navigation starts from step 2 to step 4.
More specifically, it starts when sending the URL request and ends when the browser starts rendering the page.
Step 1: Handling user input
Before navigation starts, a browser process parses the user input. More specifically, it is a UI thread in the browser process that does the job.
Two possibilities exist when a user enters something in the address bar:
- a search query, or
- A URL
If the browser process believes the user input is a search query, it parses the keywords, composes a URL with the search query, then initials a URL request.
If it is a URL, for example, medium.com, the address bar attaches the protocol (HTTP or HTTPS) to it depending on the rules. With the protocol, the address bar now has a completed URL https://medium.com.
When the user hits the return, the browser process reads the URL from the address bar. It sends the URL request to a network process through inter-process communication (IPC).
At this moment, a “beforeunload” event is fired. The tab icon changes to a loading spinner. The web page remains the same.
Step 2: Sending a URL request
Now, a network process receives the command from the browser process to handle the URL request.
Before connecting to the internet, the network process first takes a look at the browser cache and see if the requested resource has been saved locally. If so, the network process returns the cached resource to the browser process.
If not, it starts connecting to the internet, initials a DNS lookup, receives the IP address, and establishes a TLS (Transport Layer Security) connection based on the IP address.
Finally, it sends the URL request to the server.
When receiving the request, the server generates a response based on the request, including response headers, response body, and other information. Finally, the server sends its response to the network process in our browser.
Now the network process starts parsing the response headers.
Safe Browsing and CORB
At this moment, Chrome checks the domain and response data, trying to match them with its malicious site database.
If there is a match, the network process alerts to the browser and displays a warning page.
Meanwhile, a Cross Origin Read Blocking (CORB) check happens to prevent side-channel attacks.
At this point, the network process may encounter different cases.
Case 1 — redirection
Depending on different status codes, the network process makes different choices. One of them is redirection.
If the network process sees 301 or 302 status codes in the response headers, it will initiate another URL request based on the correct address. The exact address is in the Location in the response headers.
The step will be repeated and starts with the DNS lookup again.
Case 2 — Content-Type is not text/html
Content-Type exists in the response headers, telling the network process the data type of the data in its response body.
The network process will decide how to react to the response body.
If the Content-Type is text/html, it tells the network process that the data is HTML.
If the Content-Type is application/octet-stream, it says the data is byte stream. Usually, the browser treats it as a download request, submits it to its download manager.
The navigation ends.
Case 3 — status code is 200 and the Content-Type is text/html
The network process continues navigation.
It tells the browser process that everything goes well, and it will start downloading the document data.
After receiving this message, the browser process moves to the next step and starts preparing a renderer process.
Step 3: Preparing a renderer process
The browser process creates a renderer process, waiting for the ready signal from the renderer process.
Meanwhile, the network process is continuously downloading the document for the renderer process.
When the renderer process is in the standby position, the next step starts.
Step 4: Committing navigation
The browser process and the renderer process starts working together to replacing the old document with the new one.
More specifically, it has the following steps.
- When the render process is ready, it sends a “committing navigation” message to the browser process. The message notifies the browser process that the renderer process is prepared to parse document data.
- After receiving the message, the browser process starts clearing the old document.
- Then, a confirmation is sent from the browser process to the renderer process, letting it know that the commit has been completed.
- Meanwhile, the browser process updates its UI status.
- The renderer process receives confirmation and starts receiving the document from the network process.
- The renderer process confirms with the browser process that the document is committed.
- The navigation completes.
Regarding the status update in the browser process, it includes:
- safety status (the lock icon next to the URL)
- address bar URL
- history status (the forward and back buttons)
- web page (the old page is gone and turns white)
- store the session history on disk to facilitate the tab restore
That’s why the previous page content stays for a bit when we enter a URL in the address bar. Until this point, the last page is removed.
When the renderer process receives the commit, it starts parsing data, requests downloading sub-resources, and other tasks. The navigation completes, and the page rendering phase begins.
Step 5: Rendering page
The renderer process receives confirmation. It carries on parsing the document data steamed from the network process and displays a page in front of you.
At the end of the rendering, the renderer process tells the browser process that the rendering is done.
The UI thread replaces the loading spinner in its tab with the favicon of the website. A `unload` event is fired.
Network and storage threads are not relevant in 2019
In a Google post, the network and storage threads were running in the browser process in 2018.
Based on the Chromium documentation, both have been separated and run as processes now.
Only when the environment doesn’t have enough resources, the browser gracefully degrades to previous architecture, in which the network and storage work as threads.
What is the takeaway?
There are five steps to display a page:
- The browser process **handles user input**, compose a URL request.
- The networking process **sends a URL request**. The navigation starts.
- The browser process **creates a renderer process** after receiving a server response. The renderer process is in the standby position, and the network process received the document.
- The browser process **commits the navigation**. The network process starts sending document data to the renderer process. The navigation ends.
- The renderer process renders the document.
