What happened to the navigation bar?
This is the second part of a blog series about Chrome’s internal work. In the last blog, we learned that different processes and threads deal with different parts of the browser. In this article, we go deep into how each process and thread communicate in order to show a web page.
Let’s look at a simple example of a web browser: when you enter a URL in the browser, the browser gets data from the network and displays a page. In this article, we will focus on the user requesting the site and the browser to prepare to render a page (also known as navigation).
Start from browser process
As we introduced the CPU, GPU and multi process architecture in the first part, everything outside the tab is handled by the browser process. The browser process has threads, such as UI threads for drawing buttons and input parts, network threads for processing network stacks and obtaining data from the network, and storage threads for controlling access to files. Enter the URL in the address bar, and your input will be processed by the UI thread of the browser process.
Step 1: process input
When a user starts typing in the address bar, the UI thread first asks, “is this a search or a URL?”. In chrome, the address bar is also a search input area, so the UI thread needs to parse and decide whether to send the content to the search engine or the website you requested.
Step 2: start navigation
When the user presses the Enter key, the UI thread will start calling the network request to obtain the site content. The loading rotation is displayed in the corner of the tab. The network thread establishes a TLS connection for the request through the corresponding protocol, such as DNS lookup.
At this point, the network thread may receive a redirection header from the server, such as HTTP 301. In this case, the network thread starts to communicate with the UI thread and the server requests redirection. Then, another URL request is initiated.
Step 3: read the response
Once the response body starts to come back, the network process will look at the first few bytes of the stream when necessary. The content type header of the response will indicate which data type it is, but it may be lost or wrong. MIME type sniffing will be completed here. As described in the source code, this is a “tricky business”. You can read the comments to see how different browsers handle content type / payload pairs.
MIME type sniffing MDN interpretation:
When the MIME type is missing or the client thinks that the file has the wrong MIME type set, the browser may perform mime sniffing by viewing resources. Each browser will perform different operations under different circumstances. Because this operation will have some security problems. Some MIME types represent executable content and some are non executable content. The browser can use the request header
X-Content-Type-OptionsTo prevent mime sniffing.
If the response is an HTML file, you need to transfer the data to the rendering process in the next step, but if it is a zip file or other file, it means that this is a download request, so you need to transfer the data to the download manager.
It is also here for security browsing inspection. If the domain name and response data match the known malicious site, the network process will pop up a warning to display a warning page. In addition, cross origin read blocking (CORB) is triggered to ensure that sensitive site data is not passed to the rendering process.
On Google’s official website, it is explained as follows:
Cross-Origin Read Blocking (CORB) is an algorithm that can identify and block dubious cross-origin resource loads in web browsers before they reach the web page. CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages. In most browsers, it keeps such data out of untrusted script execution contexts. In browsers with Site Isolation, it can keep such data out of untrusted renderer processes entirely, helping even against side channel attacks like Spectre.
Step 4: find the rendering process
When all the checks are completed and the network thread confirms to navigate to the requested site, the network thread will notify the UI thread that the data is ready. The UI thread will find a rendering process responsible for rendering the web page.
Because network demands take hundreds of milliseconds to respond, there is an optimization to speed up this process. When the UI thread sends a URL request to the network thread in step 2, it knows which site to navigate to. The UI thread actively tries to find and starts a rendering process in parallel with the network request. In this way, if everything meets expectations, when a network process receives data, the rendering process is ready. If the navigation redirects across sites, the prepared process cannot be used, in which case another process may be required.
Step 5: submit navigation
Now that the data and rendering process are ready, send an IPC from the browser process to the rendering process for submission navigation. It also passes the data stream, so the rendering process can continuously receive HTML data. Once the browser process receives the confirmation, the submission occurs in the rendering process, the navigation is completed and the document loading phase begins.
At this time, the address bar will be updated, and the security instruction and site setting UI will reflect the site information of the new page. The session history of the tab will be engine, so the forward / backward button will step through the site you just navigated. To facilitate recovery, you close a tab or window, and the session history will be stored on the hard disk.
Additional steps: initialization logging completed
After the navigation is committed, the rendering process will continue to load resources and render the page. We will detail what happened at this stage in the next article. When the rendering process “completes” rendering, it will send an IPC back to the browser process (here, when the onload event of all frames on the page is triggered and the execution is completed). At this point, the UI process will stop loading rotation on the tab.
I say “done” because at this point, the client javscript can continue to load additional resources and render a new view.
Navigate to another site
Simple navigation is complete! But what happens if a user enters another URL in the address bar again? Of course, the browser process takes the same steps to navigate to another site. But before that, it needs to check the currently rendered sites if they have beforeunload related events.
⚠️ Warning: do not add unconditionalbeforeunload handle. Because the handler needs to be executed before navigation, because more delays are created. This event handling is only added when needed, for example, to warn users that they may lose the data they enter on the page.
When you navigate to a different site from the current rendering, an independent rendering process will be called to process the new navigation, and the current rendering process will continue to process the imageunload Something like that. More information can be viewedPage lifecycle overview, and how to use itPage lifecycle API 。
In the case of service worker
A recent update to this navigation process is the introduction ofService Worker。 Service worker is a way to write network agents in your application; Allows web developers to better control local cached data and when to get new data from the network. If the service worker is set to read pages from the cache, there is no need to request data from the network.
When a service worker is registered, the scope of the service worker will retain a reference (you canService worker lifecycleFor more information). When the navigation starts, the network thread checks whether the domain name has registered a service worker. If a service worker is registered for a URL, the UI process will find the rendering process to execute the service worker code. Service workers can load data from the cache without requesting data from the network, or they can request new resources from the network.
If the service worker finally decides to request data from the network, you can see that the round trip between the browser process and the rendering process will cause delay.Navigation preloadIt is a mechanism to speed up this process by loading resources in parallel while service worker starts. It uses tag headers to mark these requests, enabling the server to send different content for these requests, for example, to update only the data rather than the entire document.