Hello, everyone. Last time I introduced you to some of the rearrangements and redraws that I didn’t cover in detail in my previous blog post. Today we are going to talk about the entire rendering process of the browser.

First of all, we know that a page usually consists of three parts: JS, CSS, and HTML. The browser takes these three files and renders them to the user through a series of steps, which we’ll explain in detail.

The DOM tree to build

From the moment you enter the url to the moment you get the data back from the server, the first step is to parse the HTML into a DOM tree. Why do we have this step? Since the browser cannot recognize the content of an HTML file, it needs to be converted into a DOM tree that the browser can understand. It is equivalent to you communicating with an Englishman, but he does not understand Chinese, and you need to translate Chinese into English for the Englishman to understand. Here the HTML file is Chinese and the DOM tree is English.

Enter Document in the Chrome console and see what a DOM tree is

Construction of the CSSOM tree

There are three main sources of CSS

  • External style sheets
  • Internal style sheet
  • Inline style

In Chrom, we can view this structure in Document. styleSheets

Generate render tree

Now that we have DOM Tree and CSSOM, we also need to combine the two to generate a render Tree. What’s the difference between rendering trees and these? Let’s use a picture to see what happens

Generate layer tree

After rendering the RENDER TREE, browsers can’t directly RENDER it, why? For those of you familiar with the front end, there is a concept of a cascading context in front end development. So browsers also need to layer their rendering, eventually stacking many layers together to create the final page we see. So, how do browsers layer?

First, elements that have a cascading context are promoted to a separate layer, called a rendering layer, for the purpose of cascading context. The browser will later overlay the rendering layer from the inside out to the user.

The render layer is singled out because there is also a composition layer. This is related to the content we mentioned in the rearrange redraw article about how to jump directly to the composition stage, and is also what we usually say about CSS3 hardware acceleration. For more details, see the article wireless Performance optimization: Composite, shared by the Amoy front-end team.

Draw list generation

Now the browser can finally get down to business. It will divide the drawing of each layer into many small drawing instructions and store them in a list. In Chrome, you can click on a composition layer on Layers and then click Paint Profiler to see the list of drawings.

rasterizer

Rasterization, also known as Rasterization, is used to execute drawing instructions to generate color values for pixels. Instead of rasterizing the entire layer directly, the browser rasterizes the layer in blocks and rasterizes it in blocks.

Composition and display

Once all the tiles have been rasterized, the composition thread generates a command to draw the tiles — “DrawQuad” — and submits the command to the browser process.

The browser process has a component called viz that receives DrawQuad commands from the compositing thread, draws its page contents into memory, and displays them on the screen.

At this point, the browser’s entire rendering process has been explained. Let’s summarize these steps:

  • Generate a DOM TREE
  • Generate CSSOM
  • Generate the RENDER TREE
  • Generate a layer tree, which includes a render layer and a composition layer
  • Draw list generation
  • Block rasterization
  • Composition and display

Now that we’ve looked at the process, let’s take a closer look at the browser rendering process with a few common trivia questions.

Why are JS files recommended to be placed last in the body and CSS files recommended to be placed first?

This is a question I’m sure many of you know how to answer: JS blocks parsing of the DOM tree, so put it last, and CSS files load early, so put them first.

That’s fine, but let’s combine that with the browser rendering process we just described:

DOM TREE -> CSSOM -> RENDER TREE

Since the DOM has to be parsed to generate the final RENDER TREE, does it make a difference to put it at the beginning and at the end?

First ask yes, then why. Is the RENDER TREE really generated after the DOM is parsed? Well, it’s not. Let’s look at a simple example.


      
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="Width = device - width, initial - scale = 1.0">
  <title>Document</title>
  <! - < link rel = "stylesheet" href = "http://127.0.0.1:5500/big.css" > -- >
</head>
<body>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <script src="./index.js"></script>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
</body>
</html>
Copy the code
//index.js
console.log("hello world");
Copy the code

After setting up a local server, set the online option of Network in Chrome to Fast 3G

Once the JS file is loaded, the browser continues to parse the rest of the content and then fires the DOMContentLoaded event

JS will block the creation of the DOM tree, but the parse DOM tree will be rendered to the user in advance, reducing the white screen time and bringing forward the First Paint.

However, for DOMContentLoaded events, it doesn’t matter where JS is located, because DOMContentLoaded events are triggered only after the DOM has been parsed.

Why CSS is best at the beginning is explained in our next question.

Do CSS files block rendering?

In chrome’s official documentation, it explicitly states that CSS files block browser rendering. Loading CSS, however, does not normally block parsing of the DOM tree. In general, as mentioned in the documentation, if the CSSOM is not generated at JS load time, the browser will delay script execution and DOM building until the CSSOM is downloaded and built. Why do you do that? Since JS also has the ability to manipulate CSS, we can’t run the JS file until the CSSOM is built, otherwise we will probably do a lot of repetitive work, which is not good for performance.

Let’s do a simple demo to verify that.


      
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="Width = device - width, initial - scale = 1.0">
  <title>Document</title>
  <link rel="stylesheet" href="./big.css">
</head>
<body>
  <div class="demo" id="hello">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <div class="demo">The upper part</div>
  <script src="./index.js"></script>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
  <div class="demo">The second part of</div>
</body>
</html>
Copy the code

First, adjust online to Fast 3G. And write a very large CSS file, which I’m not going to show you, because it’s a lot of lines, so you can just create your own. Using the Performance tool, we can see that although the JS file has been loaded, the rest of the DOM has not been rendered

So CSS files will definitely block browser rendering, but not necessarily DOM tree parsing.

At the same time, we return to the original question, why is the CSS file good at the beginning? Because the sooner CSS files are downloaded, the sooner you can build the CSSOM tree, the faster you can render the content.

conclusion

This is all the content of this blog today, I hope you look and move your hands to give a thumbs-up and attention ~ there are mistakes can also be pointed out in the comments section of everyone to discuss.