Initially I planned to write only about DOM and even wrote the first article. But I came to the conclusion that in order to fully understand some of the concepts, I need to touch a little bit on how the browser works. Then I decided - Why "a little"? Maybe no? That's what I've decided.
Now my article about DOM is this second article in the series. It's just like in Star Wars :)
In this article I will consider those basic things of browser work, which are most important for web developers.
I'm not going to go into that, but to understand the context, I'll tell you a little bit about it. In the mid-90s, there were so-called "browser wars". Each company, in addition to its HTML, had its own versions of
browser engines until W3C obliged all companies to standardize technology. A common standard has not yet been achieved, which is why we have to create cross-browser versions of web applications.
Browser engine != Browser.
Often, the browser engine is equated with the browser. But that's not really true. All the engine does is parset and display the content. The browser, on the other hand, performs much more, more complex tasks. However, it is the different engine that makes us support all sites.
While it's running, the browser runs several processes.
The computer program itself is just a passive sequence of instructions. While the process is the direct execution of these instructions. The process can generate other processes as well as threads that share the resources of the parent process.
Since in this article we consider the browser in the context of web development, we are interested only in one process -
Maybe in the future, I'll take a closer look at the browser work.
For each tab, the browser launches this process. Moreover, modern browsers also run the
rendering process for each
iframe. This is done in order to isolate each tab and
iframe. And if any child process fails, kill it, not the main process. It's called
rendering process runs threads. We will only consider the main thread. Almost all the work in the
rendering process is done by browser engines.
The main engines at the moment are:
During development, you should also consider
EdgeHTML, but soon
Microsoftwill completely abandon it.
Now let's take a look at what happens when drawing a page.
First of all, resources (
CSS) are parsed and converted to object trees. They are combined and another tree is constructed based on them - the
render tree. This tree contains only those elements that will be drawn on the screen.
An element with the style
display: none- will not be contained in this tree. Because the element does not have its own visual representation.
After that, a walk through this tree to calculate their size and location on the screen. This process is called
flow in Firefox).
Then, all calculated elements are drawn onto the screen.
Let us dwell on each point.
Many parsers are based on
context free grammar, which allows them to work very efficiently. But the main problem with parsing
HTML is that it cannot be defined using
context free grammar. This is because the browser needs to keep track of how
HTML is written. If the tag is not closed somewhere, then the browser will close it and so on. Even if you do not make mistakes, this feature slows down parsing very much.
Another important feature of
HTML parsing is how it reacts when it encounters the
<script>tag. Parsing stops until the script is executed and only after that continues to work. This is why you should place scripts before the
</body> tag or use
defer - allow loading scripts in parallel with parsing.
deferdiffers in that it guarantees the execution order.
It should be noted that if there are very large scripts, the browser starts to allocate separate streams and tries to optimize the download.
A similar situation occurs when the parser encounters
CSS. Style loading blocks parsing.
CSS parsing is free of such problems as when parsing HTML and, in principle, is no different.
At this point, the render tree` begins to be constructed.
render tree is formed, the position and geometric dimensions of the elements of this tree are calculated.
The speed of
layout directly depends on the quality of the
CSS you wrote.
What does it mean?
This means that each
CSS rule needs to be applied to a separate
DOM node. This is achieved by recursively traversing the
HTML tree, another tree - the
CSS tree. And the more difficult it is to write
CSS, the longer it will take.
CSS - selectors are not equal in performance.
The most productive are:
.(Class) Slightly less productive -
type(for ex. - h1)
Combinations of attributes are not productive, and the most not productive are
There are various
css methodologieswhich are based on productive selectors.
Here the image is constructed and sent to the
GPU to draw it onto the screen.
In browsers, in devtools you can enable a mode that will show the rendering of elements.
We examined the main points of the browser. In some of the following articles, we will touch upon a few more interesting points.
Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉