The original linkDevelopers.google.com/web/updates…

What happens in navigation?

In the last article, we looked at how different processes and threads handle different parts of the browser. In this article, we delve into how each process and thread communicates to display a web site.

Let’s look at a simple Web browsing use case: You type a URL into a browser, and the browser retrieves data from the Internet and displays a page. In this article, we’ll focus on the part of the site that the user requests and the browser prepares to render the page — navigation.

Start with the browser process

As we explained in the previous article (CPU, GPU, memory, and multi-process architecture) : everything except tabs is handled by the browser process. Browser processes have threads, such as the UI thread that draws browser buttons and input fields, the network thread that receives data from the Internet, the storage thread that controls file access, and so on. When you type a URL in the address bar, your input is handled by the UI thread of the browser process.


figure 1 : The top is the browser U I Below is the browser process diagram, which contains U I , network, and storage threads \color{green} {Figure 1: Top is the browser UI, bottom is the browser process diagram, including the UI, network, and storage threads}

A simple navigation

1. Process input

When the user starts typing into the address bar, the first thing the UI thread asks is “Is this a search query or a URL?” . In Chrome, the address bar is also a search input field, so the UI thread needs to parse and decide whether to send what you type to the search engine or to the site you’re requesting.


figure 2 : U I The thread asks if the input is a search query or U R L \color{green} {Figure 2: THE UI thread asks if the input is a search query or a URL}

2. Start navigation

When the user presses enter, the UI thread makes a network call to retrieve the site content. Loading spinner is displayed in the corner of the TAB, and the network thread passes the appropriate protocol, such as DNS lookup and establishes TLS connections for the request.


figure 3 : U I The thread communicates with the network thread and navigates to m y s i t e . c o m \color{green} {Figure 3: UI thread communicating with network thread, navigate to mysite.com}

At this point, the network thread might receive a server redirect header, such as HTTP 301. In this case, the network thread communicates with the UI thread that the server is requesting for redirection. Then, another URL request will be made.

Read the response

Once the response body (payload) starts coming in, the network thread looks at the first few bytes of the stream if necessary. The content-Type header of the response says what Type of data it is, but because it can be lost or wrong, MIME Type sniffing is done here. As the source code comments, this is a “tricky business.” You can read the comments to see how different browsers handle content type/payload pairs.

MIME Type Sniffing: Media types (also known as multipurpose Internet Mail extensions or MIME types) are the standard that indicates the nature and format of a document, file, or byte classification. It is defined and standardized in RFC 6838 of IETF.


figure 4 : contains C o n t e n t – T y p e And actual data for the payload’s response header \color{green} {Figure 4: Response header for payload containing content-Type and actual data}

If the response is an HTML file, then the next step is to pass the data to the renderer process, but if it’s a ZIP file or some other file, then that means it’s a download request, so they need to pass the data to the download manager.


figure 5 The network thread asks if the response data is from a secure site H T M L \color{green} {Figure 5: The network thread asks if the response data is HTML from a secure site}

This is also where security browsing checks take place. If the domain and response data appear to match a known malicious site, the network thread pops up a warning box on the page. In addition, checks are made to prevent cross-source reads (CORBs) to ensure that sensitive cross-site data does not enter the renderer process.

4. Find the renderer process

Once all the checks are done and the network thread has determined the requested site that the browser needs to navigate to, the network thread tells the UI thread that the data is ready. The UI thread then finds a renderer process to render the page.


figure 6 : Indicates that the network thread tells U I The thread finds the renderer process \color{green} {Figure 6: The network thread tells the UI thread to find the renderer process}

Because network requests can take hundreds of milliseconds to get a response, optimizations are applied to speed up the process. In step 2, when the UI thread sends a URL request to the network thread, it already knows which site they want to navigate to. The UI thread attempts to actively find or start the renderer process in parallel with the network request. This way, if all goes as expected, the renderer process is already on standby when the network thread receives the data. If the navigation redirects across sites, this alternate process may not be used, in which case a different process may be required.

5. Submit navigation

Now that the data and renderer processes are ready, an IPC is sent from the browser process to the renderer process to submit the navigation. It also passes a data stream so that the renderer process can continue to receive HTML data. Once the browser process hears confirmation that a commit has occurred in the renderer process, the navigation is complete and the document loading phase begins.

At this point, the address bar has been updated, and the security indicator and site Settings UI reflect the site information on the new page. The session history of this TAB is updated, so the back/Forward buttons step through the site you just navigated to. To facilitate TAB/session recovery when you close a TAB or window, the session history is stored on disk.


figure 7 : between the browser and the renderer process I P C , requesting a rendering of the page \color{green} {Figure 7: IPC between browser and renderer process, request page rendering}

Additional step: Initial loading is complete

After the navigation is submitted, the renderer process continues to load the resources and render the page. We’ll detail what happens at this stage in our next article. When the renderer process “finishes” rendering, it sends IPC back to the browser process (this is after all onload events have been triggered on all frames in the page and execution has completed). At this point, the UI thread stops the loader on the TAB.

This “done” is not “done”, after which the client-side JavaScript can still load additional resources and render a new view.


figure 8 : I P C Notification from renderer to browser process that the page is “loaded” \color{green} {Figure 8: IPC process from renderer to browser notifying that the page is “loaded”}

Navigate to other sites

Simple navigation is done! But what happens if the user puts a different URL into the address bar again? Well, the browser process navigates to different sites through the same steps. But before doing that, it needs to check whether the currently rendered site cares about the beforeUnload event.

Beforeunload can create “Leave this site?” The Alert popup to raise an alert when you try to leave or close tabs. Everything inside the TAB, including your JavaScript code, is handled by the renderer process, so the browser process must check the current renderer process when a new navigation request comes in.

Note: Do not add unconditional beforeUnload handlers. It creates more latency because the handler needs to be executed before the navigation begins. Add this event handler only when you need to, for example, warn the user that data entered on the page may be lost.


figure 9 From the browser process to the renderer process I P C Tell it to navigate to a different site \color{green} {Figure 9: IPC from the browser process to the renderer process tells it to navigate to a different site}

If the navigation is started from the renderer process (for example, the user clicks a link or the client JavaScript runs window.location = “https://newsite.com”), the renderer process first checks the beforeUnload handler. It then goes through the same process as the browser process starts navigation. The only difference is that the navigation request starts from the renderer process to the browser process.

When the new navigation arrives at a different site than the currently rendered site, a separate renderer process is called to handle the new navigation, while the current rendering process is retained to handle events such as UNLOAD. For more information, See Page Lifecycle States and how to use Page Lifecycle States API events.


figure 10 From the browser process to the new renderer process I P C Notify the render page and notify the old renderer process to uninstall \color{green} {Figure 10: IPC notifying render page from browser process to new renderer process and notifying uninstall old renderer process}

Service Worker

A recent change to this navigation process is the introduction of the Service Worker. A Service Worker is a way to write network agents in application code; Web developers have more control over what is cached locally and when new data is fetched from the network. If the Service Worker is set to load pages from the cache, there is no need to request data from the network.

The important part to remember is that a Service Worker is JavaScript code running in a renderer process. But how does the browser process know that the site has a Service Worker when a navigation request comes in?

After a Service Worker is registered, The scope of The Service Worker is retained for reference (you can read more about scope in The Service Worker Lifecycle article). When navigation occurs, the network thread checks the domain against the range of registered Service workers, and if the Service Worker is registered for the URL, the UI thread looks for the renderer process to execute the Service Worker code. The Service Worker may load data from the cache without having to request data from the network, or it may request new resources from the network.


figure 11 : Network thread lookup in the browser process S e r v i c e W o r k e r The domain \color{green} {Figure 11: Network thread in browser process looking for Service Worker domain}

Figure 12: The UI thread in the browser process starts the renderer process to process the Worker thread in the Service Worker renderer process and then requests data from the network

Navigation preloading

As you can see, this round-trip between the browser process and the renderer process can cause delays if the Service Worker finally decides to request data from the network. Navigation Preload is a mechanism to speed up the process by loading resources at the same time the Service Worker starts. It marks these requests with headers, for which the server can send different content; For example, just update the data instead of the entire document.


figure 13 : is in the browser process U I The thread starts the renderer process to process S e r v i c e W o r k e r , and starts the network request in parallel \color{green} {Figure 13: The UI thread in the browser process starts the renderer process to handle the Service Worker and starts the network request in parallel}

conclusion

In this article, we looked at what happens during navigation and how your Web application code, such as response headers and client-side JavaScript, interacts with the browser. Understanding the steps a browser takes to get data from the web makes it easier to understand why apis such as navigation preloading were developed. In the next article, we’ll delve into how browsers evaluate our HTML/CSS/JavaScript to render the page.

Do you know how to add dynamic JPG pictures in the nuggets