Another Browser Rendering Nitty Gritty

I did a post before on how browser rendering works previously though, but I feel it was not enough.

There are certainly gaps in my head I wanted to fill, and I came across this conference talk which I find really informative. Not the best presentation but it's decent.

Check your self right here:

There are several key points I'd like to make about this video if you prefer not to watch it.

  • When HTML parser reaches <script> tag, it will halt parsing, fetch the script and execute it before continuing to parse.

  • When a <script> tag is found and parsing is halted, the browser will create a new thread in a new process with the browser to search for external images and CSS to fetch in parallel. It probably will also look for another <script> tag to download, but I'm not sure about executing it.

  • On initial render, it needs all the Parse Tree to finished before it proceeds to making a DOM, and it needs all DOM nodes and CSSOM to be completed before being combined into a Render Tree, and so on.

  • JavaScript can interfere with the DOM and CSSOM on initial render.

  • For subsequent rendering, it will set at a regular interval when it will reflow and repaint. Every time we mutate the DOM, it will still be immediately alter the Render Tree, but then it will not immediately proceed to the next stage (layout). Altered nodes in Render Tree will be marked dirty, the batch will traverse the tree and find all dirty trees at a regular interval, so multiple dirty nodes can be reflow and repaint on a single flow.

  • Immediate reflow occur on several actions, such as doing a font size change, resizing the browser, and accessing several properties like node.offsetHeight!

Some Performance Insights
  • Do all reading in one go, writing in one go.

How Browser Rendering Works

I guess it’s pretty important to figure how the browser actually works behind the scene.

We all know how to write HTML, CSS, and JavaScript. But how do browser actually use those languages to actually produce something useful to the user?

I didn’t know the answer profoundly though, but I discover several interesting sources you may want to checkout!

Reflow & Repaint is a useful concept the browser implements whenever changes occur. It is important for you to consider because it affects your web performance.

This is my conclusion for the preceding articles.

Big Picture:

DOM + CSSOM –> Render Tree –> Layout –> Paint

HTML parsed to a DOM (Document Object Model). I believe it contains information like type of the node and attributes (so it include inline style, and mutable using the

CSS parsed to a CSSOM (CSS Object Model).

Together, DOM and CSSOM blends into Render Tree.

The browser layout each node of the Render Tree, then paints them to the page.

Repaint is a concept where the browser repaints your node to the page.

Reflow is when the browser relayout your node, and then repaints it back, so it’s considered more expensive.

I believe changes occur because we mutate the DOM, not the Render Tree (I mean, changes to the DOM reflects to the Render Tree, but we can not directly change the Render Tree).

What expensive for the browser:

  • Multiple pass

  • Multiple node needed to reflow & repaint during each pass

And by mean pass is the rendering flow.

So multiple pass means multiple rendering flow.

One of the article mention that the browser is smart enough to cache changes before actually do an actual rendering.

So if you update a single node using several statement in JavaScript, the browser will cache the changes first, then when all your statement ends the browser will implement all the changes in a single pass.

Important to note is if you’re reading a DOM node, it will force a reflow, and your cache will directly be implemented.