This is the 20th day of my participation in the November Gwen Challenge. Check out the details: The last Gwen Challenge 2021

The layout phase

Now, we have the DOM tree and the styles of the elements in the DOM tree, but that’s not enough to display the page because we don’t yet know the geometry of the DOM elements. The next step is to figure out the geometry of the visible elements in the DOM tree, a process we call layout.

Chrome performs two tasks in the layout phase: creating a layout tree and calculating the layout.

We developers use layout as a way of arranging elements on a page, including streaming layout, floating layout, Flex layout, Gride grid layout, etc., so that the boxes of elements on the page are deployed as we want them to be.

Chrom will lay out the content we develop in the browser.

Now it’s all layouttrees,

1. Create a layout tree

You may have noticed that the DOM tree also contains many invisible elements, such as the head tag and elements that use the display: None attribute. So, before displaying, we also build an additional layout tree with only visible elements.

Let’s look at the layout tree construction process with the following figure:

As you can see from the figure above, all invisible nodes in the DOM tree are not included in the layout tree. To build the layout tree, the browser basically does the following:

  • Iterate through all visible nodes in the DOM tree and add these nodes to the layout tree;
  • Invisible nodes are ignored by the layout tree, such as everything under the head tag, or the body.p.pan element, which is not included in the layout tree because its attribute contains dispaly: None.

2. Layout calculation

Now we have a complete layout tree. The next step is to calculate the coordinate positions of the nodes in the layout tree. The layout calculation process is very complicated, so we’ll skip it here.

When a layout operation is performed, the result of the layout operation is written back into the layout tree, so that the layout tree is both the input and the output. This is an unreasonable place in the layout phase, where the input and output are not clearly distinguished. To address this problem, the Chrome team is refactoring the layout code. The next generation of layout system, called LayoutNG, attempts to separate input and output more clearly, thus making the newly designed layout algorithm simpler

QA: QA: CSS file is blocked, will this prevent DOM tree synthesis? Does it block the display of the page?

CSS loading does not block DOM tree parsing, but it does block DOM tree rendering. Therefore, to avoid a long blank screen, you should improve the loading speed of CSS as soon as possible. 1. Use CDN; 2. Compression of CSS (using webpack, gulp and other packaging tools); 3. Use cache properly (set cache control, expression and e-tag); DOM parsing and CSS parsing are two parallel processes, so this explains why CSS loading does not block DOM parsing. But because the Render Tree relies on the DOM tree and the CSSOM tree, it must wait until the CSSOM tree is built, i.e. the CSS resources are loaded.

When the first data of the HTML page is received from the server, the DOM parser starts to work. During parsing, if a JS script is encountered, it looks like this:

<html>
    <body>
         geek
        <script>
        document.write("--foo")
        </script>
    </body>
</html>
Copy the code

The DOM parser then executes the JavaScript script, and when it’s done, continues parsing.

The second case is a bit more complicated, where we replace the inline script with a JS external file, as shown below:

<html>
    <body>
        geek
        <script type="text/javascript" src="foo.js"></script>
 </body>
</html>
Copy the code

In this case, when JavaScript is parsed, DOM parsing is paused and the foo.js file is downloaded. When the download is complete, the js file is executed and the DOM parsing continues. This is why JavaScript files block DOM rendering.

Summary: Real page rendering requires CSS, HTML is fully loaded and parsed to generate a layout tree, then the layout is calculated and drawn to the page, but the particularity of JS, JS will block DOM parsing, thus preventing page rendering. CSS loading and parsing is parallel to HTML loading and parsing. And it can be found through experiments that js execution needs to wait for the completion of CSS loading. Probably because the engine can’t tell if you’ve accessed the element’s style in the script, it blocks everything whenever the script appears

I think CSS indirectly blocks the building of the DOM tree by blocking the execution of JS. CSS does not block the building of the DOM tree when there are only CSS and HTML documents.