Animation: How does a browser work?

For most of the front-end developers interviewed, their understanding of browsers is only half-baked, because at the beginning we thought that we usually use browsers to display and debug pages during development, and we would not involve too much knowledge about the working principles of browsers.

You are totally wrong. Although the browser works silently for us, the working principle of the browser is not only the top priority in your front-end job interview, but also occupies a large proportion in front-end optimization. As a front-end developer, if you don’t understand the working principle of the browser, you can only stay at the level of a front-end "picture cutter".

PS: A few days ago, a reader told Xiaolu that he had seen this mind map posted on Xiaolu’s WeChat Moments before, but he didn’t take it seriously at the time. However, he was asked about it during the interview the next day.

The purpose of learning how browsers work is to be able to apply them to actual projects, such as front-end performance optimization and error troubleshooting, which will involve browser-related knowledge, so mastering the working principles of browsers is essential. I believe that after you have learned it, your personal abilities and knowledge will be greatly improved.

There are many important knowledge points involved in the browser. There may be deficiencies and errors in the article. You are welcome to point them out!

Mind Map

1. Browser's Responsibilities

We will learn how browsers work from the simplest to the most complex. First, we need to know what a thing is and what kind of things it accomplishes, that is, what kind of responsibilities it has.

For the browser, on the surface, we enter the URL, and then wait for a few seconds for the browser to display the content of the URL we want to visit. Yes, that's the responsibility of the browser. This is just on the surface. If you want to know more about what happens in the browser at this stage? We need to further explore how the browser works.

So, whether in an interview or in actual work, browsers are always with us. So let's start from entering the URL in the browser until the browser finally displays the website content. What does the browser do in this process and how does it work?

We will divide it into the following modules for systematic explanation:

• DNS resolution
• TCP Connection
• HTTP Request
• Building the DOM Tree
• Building the CSSOM tree
• Generate render tree
• Synthesis, rendering

Some of these parts have been shared in our previous articles, so we will not repeat them here. We will consolidate them when the time comes. Our focus will be on the rendering principles of the browser, which will also be the focus of our future study of front-end optimization.

2. DNS resolution

In the previous article TCP three-way handshake, it is mentioned that in order to obtain the MAC address of the recipient, it is necessary to obtain it through the other party's IP address, and the other party's IP needs to be resolved through DNS.

1. Why do we need DNS resolution?

The so-called DNS resolution is to convert the URL we enter in the address bar of the web page into an IP address through DNS. DNS is the process of converting domain names into IP addresses. So what happens in this process? Let's explore it in depth with Xiaolu.

2. System cache query

First, the browser will call a library function to detect the local hosts file (which can be considered as an address mapping file on the local computer) and check whether there is an IP address corresponding to the domain name in the file. This process is to find out whether there is an IP address corresponding to the domain name in the system cache.

For example, enter Xiaolu's blog URL (www.xiaolu.com) in the address bar of the browser and press Enter. The browser will then use the domain name to query a file called hosts on the local computer to see if there is an IP address corresponding to the domain name. If so, it will be returned to the browser. If not, we will continue.

3. Router cache, ISP cache

If the system cache does not have it, it will send a request to the DNS server. Network services generally go through the router and the network service provider (telecom) first, so it will query the router cache first, and then query the ISP's DNS cache.

PS: ISP cache is a technology used by broadband access providers to accelerate batch access to web pages. The ISP will put the web pages with the largest number of visits into the cache of the ISP server. When a new user requests the same content, the relevant information can be sent directly from the cache without having to visit the real website every time. This speeds up the access of different users to the same content and also saves the cost of network traffic settlement.

4. DNS recursive query

If the router cache and ISP's DNS cache still do not have the address, we will perform a recursive DNS query, starting with the root domain name server, then the top-level domain name server, and finally the primary domain name server.

But there are two query methods here, not only recursive query, but also iterative query. What is the difference between the two query methods?

Iterative query: When DNS receives a request, instead of returning the query result directly, it tells the client the address of another DNS server. The client then submits a request to this DNS server, and the cycle continues.

Recursive query: When a DNS server receives a request, it checks the DNS cache. If not found, it queries other servers and returns the query results to the client.

Our front-end will use DNS-related knowledge in performance optimization. Let's briefly mention how to optimize DNS.

DNS query goes through many steps and is very slow. After the browser obtains the IP address, it is generally added to the browser cache. The local DNS cache server can also record it.

In addition, we use DNS load balancing. Usually, our websites apply various cloud services. The DNS system provides efficient and fast DNS resolution services based on the load of each machine, geographical location restrictions, etc.

TCP Connection

After we query the IP address through DNS, we start to plan to establish a connection with the server and prepare for the subsequent data transmission. This part is written in great detail in the previous article, so be sure to read it.

Animation: Use animation to explain the TCP three-way handshake process to the interviewer

IV. HTTP Request

After our client and server establish a connection through TCP's three-way handshake, the client begins to actively initiate requests to the server.

PS: For the HTTP protocol, we will take out a separate article later to introduce its development history in detail. Here we only involve the content related to HTTP requests.

When the server receives the information sent by the client, it returns the response information and files. How does the client determine whether the server has returned successfully? It needs the following status codes to identify it. Similarly, the front-end also uses the status code to determine the current response status.

(1) 1XX (informational status code): The server is processing the request.

(2) 2XX (Successful status code): The request has been processed.

(3) 3XX (Redirection status code): Additional action is required to complete the request.

• 301: Permanent Redirect. This status code indicates that the requested resource has been assigned a new URI. When you use the resource in the future, use the current URI.
• 302: Temporary redirection. This means that a new URI has been assigned to this status code, and users are expected to use the new URI to access the page this time.
• 304: The server resources have not changed, and the client's non-expired cache can be used directly.

(4) 4XX (Client Error Status Code): The server cannot process the request.

• 400: There is a syntax error in the request message.
• 403: No permission to access the resource.
• 404: Resource not found.

(5) 5XX (Server Error Status Code): The server encountered an error while processing the request.

• 500: Server error
• 503: The server is overloaded or under maintenance.

The remote server finds the resource and returns it using an HTTP response with an HTTP response status of 200 indicating a good response.

5. Browser rendering principle

1. Constructing the DOM

The server converts HTML, CSS, and JS files into 0,1 byte data and transmits it to the browser over the network. The browser starts to receive and parse the files by judging the status code, which begins to apply the browser's rendering principle.

The first thing the browser needs to do is to obtain the HTML text in the string (character stream) in the body of the HTTP Request, parse it and build a DOM tree.

After converting the character stream into a string, the browser starts lexical analysis. Although we are not familiar with this term, we should know that an HTML string must be split to build a DOM tree. Lexical analysis is the process of splitting a string into tokens. The token is the smallest unit of code, which is the result of the split. This process is called tokenization.

After we decompose the string, we convert these tags into Node nodes, and the browser starts to build a DOM tree based on different nodes. This is the entire DOM tree construction process, which also involves many details, such as how lexical analysis is a process (state machine). Interested friends can check the English document in detail at the bottom of the article.

2. Constructing the CSSOM tree

The browser has converted the HTML file into a DOM tree. Next, the CSS style file is parsed and constructed into a CSSOM tree. This process is somewhat similar to the above process of constructing a DOM tree, but the construction of the CSSOM tree is more time-consuming. Let's take a look at how time-consuming it is.

The browser sets the style for the node by recursively searching the DOM tree, first finding the specific tag, then recursively finding the parent tag that is set, and finally determining the style of the selected tag selected by the selector.

For example, in the following example, how does the browser determine the style of the node?

   < div >  
 < span >  
 < p > Learn programming with Xiaolu Animation, one animation a day to feed you! </ p >  
 </ span >  
 < p > Hello, little deer! </ p >  
 </ div >   
 
 
 div span p{
 color: red;
 font-size: 12px;
 }
 div {
 background:red;
 }

First, find the p tag in HTML, there are two places in total, and then continue to recursively find the p with a parent node according to the style. We have to filter out the second p, and then continue to look for the parent node div upwards. If the match is successful, then set the style to the node.

From the animation above, we can understand why it is very time-consuming to build the CSSOM tree. We can make optimizations when writing code, so we should avoid writing overly specific CSS selectors and adding fewer meaningless HTML tags, which will help improve the performance of the learning page.

3. Constructing the render tree

We merge the DOM and CSSOM trees generated above to generate our rendering tree. However, when merging, it is not a simple combination of the two, because some nodes do not need to be displayed. Remember there is a display:none attribute? If the style of a node has this attribute, it will not appear in the rendering tree.

4. Synthesis and rendering

When the browser generates a render tree, it will layout it according to the render tree, call the GPU for drawing, then synthesize the layers, and finally display them on the screen.