does CSSOM and DOM construction happens on parallel threads?

Question

I was looking online for this answer for long time . But got no concrete answers to this question . I want to know how each process works in rendering (i.e. using multiple threads or single threads)

Answer 1

In order to render the page the browser has to do multiple complex steps, in generality these steps are : parsing/loading, style calculation, creating layout tree, paint, and then finally Rasterisation ( in this step the browser takes the results that was generated from all the previous steps, and turn that info into colored pixels that are drawn on your screen).

In short, in the parsing/loading step, the main thread starts parsing the html, and creating the dom tree, and when it reach - or even peak about - external resources it starts loading these resources in a background network thread(s). unless you defer loading these resources, the browser still needs to parse/execute them before going to next step.

In the style calculation step, the browser determines styles for each node, this also happens in the main thread, and needs to happen after dom has been created. styles can not be calculated in parallel with dom parsing, because styles need to be calculated based on css selectors, and css selectors are meaningless without the dom tree being completely structured and ready to be read - up till the point where that style declaration appears.

After styles are calculated, browsers start creating layout tree - you could think of the layout tree as a huge rectangular grid created of smaller rectangles, where the browser knows where every element is positioned and in which small rectangle in the whole grid, along with x,y coordinates, and bounding boxes size. This step also happens in the main thread, and can not be parallel with style calculation, because it needs dom and cssom as inputs in order to produce its output.

After that painting comes, also happens in main thread, and again needs the previous results as its input, and so can not be parallel with layout creation, in this step the browser creates painting structures for the whole layout tree.

From here the browser commit all this information to the Compositor thread, this is where things in parallel start to happen, the compositor thread knows how to take the layout tree, and composite that into frames that you see. The compositor thread is extremely smart, it knows how to prioritise and parallelize workload, it sends its workload to different rasterisation threads, and these are responsible for giving you the colored pixels that are drawn in your screen.

The Compositor thread is not only used for the initial render, but also used anytime the main thread wants to render stuff. In fact when you are scrolling, you are scrolling on the compositor thread, and recently chromium has been moving a lot of stuff to the compositor thread, so that even if the main thread gets blocked then ui still behaves smoothly. If you want to learn more about the compositor thread you can also see this link (along with the one i previously shared)