Moment For Technology

In-depth Reading of Modern Browsers iii

Posted on May 21, 2023, 7:20 a.m. by Dr. Allan Harris
Category: The front end Tag: javascript The front end

Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser Inside Look at Modern Web Browser

An overview of the

This article provides a general overview of what renderer Process does.

The HTML, CSS, and javascript content in the browser TAB is basically handled by the main thread of the Renderer Process, except that some JS code is placed in the Web worker or service worker. So the core job of the browser main thread is to parse the web's three musketeers and generate an interactive user interface.

Parsing stage

First of all, the renderer process main thread will parse the HTML text into DOM (Document Object Model), which is only translated into Chinese. Therefore, the text must be structured to continue processing. Not only browsers, but code must first go through the Parse phase.

For HTML link, IMG, script tags that need to load remote resources, the browser will call network Thread priority parallel processing, but the script tag must be stopped and priority execution, because js code may change any DOM object. This can cause the browser to reparse. So if your code doesn't have the side effect of modifying the DOM, you can add async tags, defer tags, or JS modules in a way that the browser doesn't have to wait for JS to execute.

Style calculation

The DOM alone is not enough. The style declared by the style tag needs to be applied to the DOM, so based on the DOM, the browser generates a CSSOM that determines the node to be applied based on the CSS selectors.


With DOM, CSSOM is still not enough to draw a web page because we only know the structure and style, but not the location of the elements, so we need to generate a LayoutTree to describe the structure of the layout.

LayoutTree is similar to THE DOM structure, but elements like display: None do not appear in LayoutTree, so LayoutTree only considers rendering structure, whereas DOM is a composite description structure, which is not suitable for direct rendering.

One of the biggest technical challenges with LayoutTree is typography, which Chrome has a whole team working on. Why is typography so difficult? Can realize the tip of the iceberg from these few examples: collision between the box model, open the font content to wrap, trigger a larger area to typesetting, a box model open squeeze another box model, but after another box of model size change content layout changes, cause the box model to change again, this change leads to the changes on the layout of the external other box model.

The hardest part about layout is that you have to deal with all the weird patterns as reasonably as possible, and many times the rules of layout patterns conflict. And that's without taking into account the risk that changes to the layout engine could cause unknown bugs on hundreds of millions of web pages.


Is DOM, CSSOM, and LayoutTree enough? No, there's still a final PaintRecord missing, which is a drawing record that records the hierarchy of elements to determine the order in which they are drawn. Because LayoutTree only determines the physical structure, it does not determine the upper and lower spatial structure of the elements.

With DOM, CSSOM, LayoutTree, and PaintRecord, you can finally draw. However, when THE HTML changes, the cost of redrawing is huge, because the calculation result of any step above depends on the previous step, when the HTML changes, DOM, CSSOM, LayoutTree, PaintRecord recalculation.

Most of the time the browser can do it in 16ms, keeping the FPS around 60, but when the page structure is too complex, the calculations themselves exceed 16ms, or the JS code is blocked, the user will feel stuck. Of course, for JS lag problem, we can use requestAnimationFrame to distribute the logical operation in each frame when it is idle, and we can also separate it into the Web worker.


The process of drawing is called rasterizing. When Chrome was first released, a simpler rasterization scheme was used, rendering only the pixels in the region and then adding the pixels in the current scrolling position as they were rolled. Doing so causes rendering to lag behind scrolling forever.

Compositing is now a well-established technique of layering and rendering rendered content, which can greatly improve performance and can be manually declared as a new layer with the CSS attribute will-change (don't abuse it).

The browser will analyze the LayoutTree to get a LayerTree and render it layer by layer.

The compositing layer splits the drawing content into multiple grids and delivers them to the GPU for rendering, so performance is very good.

Intensive reading

Performance optimization in terms of rendering layering

This article discusses the five important aspects of browser rendering: parsing, styling, layout, drawing, and composition. They are the most physical parts of the browser in the front-end developer's daily work, and the part where optimization takes place the most.

In fact, from the point of view of performance optimization, parsing link can be replaced by JS link, because modern JS framework often has no HTML template content to parse, almost all JS operation DOM, so it can be regarded as five new links: JS, style, layout, drawing, composition.

It is worth noting that almost every layer of computation depends on the results of the upper layer, but not every layer is necessarily double-counted, and we need to pay particular attention to the following situations:

  1. Modifying element geometry attributes (position, width and height) triggers a recalculation of all layers, as this is a very heavyweight change.
  2. Changing an element's drawing attributes (such as color and background color) without affecting position skips the layout layer.
  3. Modifying properties such as transform skips the layout and drawing layers, which seems incredible.

For the third point, since the content of transform will be promoted to the composition layer and rendered by GPU, it will not be processed together with the layout and drawing of the main thread of the browser, so visually this element does produce displacement, but it is fundamentally different from modifying the displacement of left and top in implementation.

From a browser developer's point of view, it's easy to understand why this optimization isn't a clever trick, because the browser implementation itself separates the behavior of the layout, drawing and composition layers, and the performance of each code layer will be different depending on the underlying scheme. You can use csStriggers to see which layers of recomputation are caused by different CSS properties.

Of course, it's fair to wonder why browsers can't "automatically mask the implementation details of left Top and Transform and automatically layer them properly", but if browser manufacturers can't do this, developers should take the initiative to understand how the implementation works.

Implicit composition layer, layer explosion, layer automatic merge

In addition to the transform and will-change properties, there are a number of cases where elements can be promoted to the composition layer, such as video, canvas, iframe, or fixed elements, but these are explicitly defined and therefore display composition.

Implicit composition refers to the situation in which elements are not specially marked, but are also promoted to the composition layer. This situation usually occurs when z-index elements overlap, and the element below is declared to be promoted to the composition layer, so the browser will implicitly promote the upper element to the composition layer in order to ensure the z-index coverage relationship.

The cause of the blast is refers to the implicit synthesis, when there is some complex behavior of CSS (path animation, for example), the browser can't real-time capture which elements are located above the current element, so I had to put all the elements to composite layer, while the number of composite layer too much, the main thread and GPU may become the bottleneck of communication, but impact performance.

Browsers also support automatic layer merges, such as implicit promotion to the composition layer, where multiple elements are automatically merged into a composition layer. This approach doesn't always work, however, as automated processing can't guess the developer's intentions, so the best way to optimize is for the developer to intervene.

We just pay attention to all ascending to synthesis of layer element in z - the top of the index, so that the browser have judgment, will no longer scared this element suddenly moved to the position of an element, lead to pressure the elements, and he had to give implicit to this element synthesis layer to ensure the correctness of the order between them, Because this element is already on top of everything else.


After reading this article, I hope you can summarize more code-level performance optimization lessons based on how the browser implements the rendering process.

Finally want to ridicule, browser specification being iterative step by step, so seemingly in describing the location of the CSS properties actually behind the realization principle is different, although the rules on the W3C specification, but if only the property name is very hard to come out to the horizon, so I want to be best performance optimization, you must understand the browser implementation principle.

The discussion address is: close reading "In-depth Understanding of modern Browsers iii" · Issue #379 · dT-fe /weekly

If you'd like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading - Helps you filter the right content.

Copyright Notice: Freely reproduced - Non-commercial - Non-derivative - Remain signed (Creative Commons 3.0 License)

About (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.