This is the fifth day of my participation in the August More text Challenge. For details, see:August is more challenging
What happens to the process of typing in the search?
Perhaps the most common use of Chrome is to enter a keyword in the address bar to search or to enter an address to navigate to a website. Let’s see how the browser sees this process.
We know that off-tab work is handled by the Browser Process, which further divides the work into different threads:
- UI Thread: controls buttons and input boxes on the browser;
- Network thread: Processing network requests and obtaining data from the network;
- Storage thread: controls access to files, etc.
- Process the input
The UI Thread needs to determine whether the user entered a URL or a query;
- Start navigation
When the user hits the Enter key, the UI Thread informs the network thread to get the page content and controls the spinner display on the TAB to indicate that it is loading.
The network Thread performs the DNS query and then establishes a TLS connection for the request
3. Read the response
When the response is returned, the network thread uses the Content-type and MIME Type sniffing to determine the format of the response
If the response content is in HTML format, the next step will be to pass the data to the Renderer process, and if it is a ZIP file or other file, to the download manager.
The Safe Browsing check is also triggered at this point, and Network Thread displays a warning page if the domain name or request content matches a known malicious site. In addition, CORB detection is triggered to ensure that sensitive data is not passed to the rendering process.
4. Find the rendering process
When all these checks are complete and the Network Thread is sure that the browser can navigate to the requested page, the Network Thread informs the UI Thread that the data is ready, and the UI Thread finds a renderer process to render the page.
Because it takes time to get a response to a network request, there is actually an acceleration solution. When a UI thread sends a URL request to a Network thread, the browser actually knows which site to navigate to. The UI Thread will find and start a rendering process in advance in parallel. If all is well, the rendering process will be ready when the Network Thread receives the data, but if there is a redirection, the prepared rendering process may not be available and a new rendering process needs to be restarted.
5. Confirm the navigation
Once the Browser Process has received the renderer Process’s render confirmation message, the Browser Process sends an IPC message to the Renderer Process to confirm the navigation. The navigation process ends and the page loading process begins.
At this point, the address bar will be updated to display the new page information. The History TAB will be updated and you can use the Back key to go back to the page from which you navigated. This information will be stored on the hard disk for easy recovery after closing the TAB or window.
6. Extra steps
Once the navigation is confirmed, the Renderer process will render the page using the relevant resources. We will focus on the rendering process in the following paragraphs. The renderer process sends an IPC signal to the Browser process when the renderer process finishes rendering (when the renderer process finishes rendering means that all pages within the page, including all iframes, have triggered onLoad). The UI thread stops showing the spinner in the TAB.
Of course, only the first frame of the page is rendered, after which the client can still download additional resources to render the new view.
The renderer Process controls all of the JS code, so most of the time there are no other processes involved while you’re browsing the web. But maybe you’ve listened for beforeUnload events, which again involve interacting with the Browser Process and renderer Process when the current page is closed (closing tabs, refreshing, etc.), The Browser Process needs to notify the Renderer Process to check and Process related events.
If the navigation is triggered by the Renderer process (for example, after the user clicks on a link, Or JS executes window.location = “[http://newsite.com](https://link.zhihu.com/?target=http%3A//newsite.com/)”) renderer process The beforeUnload event handler is first checked and the navigation request is passed from the Renderer process to the Browser process
If you navigate to a new site, a new Render process is enabled to handle the rendering of the new page, and the old process is left to handle events like unload.
For more information on the Lifecycle of a Page, see the Page Lifecycle API.
In addition to the above processes, some pages also have Service workers, which give developers more control over local caching and deciding when to retrieve information from the network. If the Service Worker is set to load data from the local cache, there is no need to fetch more data from the web.
It’s worth noting that the service worker is also JS code that runs in the rendering process, so the above process is slightly different for pages that have a service worker.
When a Service Worker is registered, the scope is saved. When there is a navigation, the network thread checks the domain name in the scope of the registered Service Worker. If the corresponding Service Worker exists, The UI thread will find a renderer process to process the code, and the Service Worker may load the data from the cache to terminate the network request, or it may request new data from the network.
More information about Service workers can be found at The Service Worker Lifecycle
If the Service Worker ultimately decides to fetch the data online, the Browser and renderer processes interact to actually delay the data request. Navigation Preload is a mechanism to speed up resource loading in parallel with the Service Worker. The server can recognize such requests through the request header and process them accordingly.