Introduction to how browsers work

First, the main structure of the browser

1. User interface-includes address bar, back/forward button, bookmark directory, etc., which is what you see in addition to the main window used to display the page you requested.

2. Browser engine-the interface used to query and manipulate the rendering engine.

3. Rendering engine-used to display the requested content, for example, if the requested content is HTML, it is responsible for parsing the HTML and CSS, and displaying the parsed results.

4. Network-Used to complete network calls, such as HTTP requests, which have platform-independent interfaces that can work on different platforms.

5. UI backend-used to draw basic components such as combo box and dialog, with a generic interface that is not specific to a platform, and uses the operating system's user interface at the bottom.

6. JS interpreter-Used to interpret the execution of JS code.

7. Data storage-belongs to the persistence layer, the browser needs to save a variety of data like cookies on the hard disk, HTML5 defines the Web database technology, which is a lightweight and complete client storage technology

Second, rendering engine

The browser--firefox, Chrome, and Safari discussed in this article are built on two rendering engines, and Firefox uses Geoko--mozilla's self-developed rendering engine, which both Safari and chrome use WebKit.

WebKit is an open-source rendering engine, originally developed for the Linux platform, and later ported from Apple to Mac and Windows, please refer to http://webkit.org for more information.

The rendering engine first obtains the content of the requested document over the network, usually in the form of a 8K block.

Here is the basic flow of the rendering engine after it obtains the content:

Parse HTML to build a DOM tree, build a render tree, layout render tree, draw a render tree

The rendering engine begins parsing the HTML and translates the tags into DOM nodes in the content tree. Next, it parses the style information from the external CSS file and style tag. These style information, as well as the visibility directives in HTML, will be used to build another tree--render tree.

The render tree consists of a number of rectangles that contain attributes such as color and size, which are displayed to the screen in the correct order.

When the render tree is built, the layout process is performed, which determines the exact coordinates of each node on the screen. The next step is to draw, which is to traverse the render tree and draw each node using the UI back-end layer.

It is important to note that this process is done incrementally, for a better user experience, the rendering engine will render the content to the screen as early as possible, and will not wait until all the HTML is resolved before building and laying out the render tree. It shows part of the content as part of parsing, and may also be downloading the rest of the content over the network.

Webkit:

Gecko:

Figure 4:mozilla the Geoko rendering engine main process

As can be seen from figures 3 and 4, although WebKit and gecko use a slightly different terminology, their main process is essentially the same. Gecko calls the visible formatting elements of the tree as a frame tree, and each element is a frame,webkit that uses the noun of the render tree to name the tree that is composed of the rendered object. The positioning of elements in WebKit is called layout, while Gecko is called reflow. WebKit says the process of using DOM nodes and style information to build a render tree adds a layer of Attachment,gecko between the HTML and Dom trees, a layer called a content receiver, a factory that makes DOM elements quite a lot.

Third, Dom parsing

The DOM tree of HTML is parsed as follows:

The above HTML will parse into this:
Here's another case with an SVG tag.
Four, CSS parsing
Webkit CSS Parser (Webkit CSS parser)
WebKit uses the flex and Bison parsing generators to automatically generate parsers from CSS grammar files. Recall the parser introduction, bison create a bottom-up parser, Firefox uses a top-down parser. They all parse each CSS file into a style sheet object, each containing CSS rules, CSS rule objects that contain selectors and declarative objects, and other objects that conform to CSS syntax.
Order of processing scripts and style sheets (the order of processing scripts and style sheets) script
The web's pattern is synchronous, and the developer wants to parse the script as soon as it resolves to a script tag and block parsing of the document until the script finishes executing. if the script is out of the way, the network must first request to this resource-the process is also synchronous, blocking the parsing of the document until the resource is requested . This pattern has been maintained for many years and is specifically specified in HTML4 and HTML5. The developer can identify the script as defer so that it does not block document parsing and executes after the document resolves. HTML5 adds the option to mark the script as asynchronous so that the parsing of the script is performed using another thread.
Pre-parsing (speculative parsing)
Both WebKit and Firefox do this optimization, and when the script is executed, another thread parses the rest of the document and loads the resources that need to be loaded over the network later. This approach allows resources to be loaded in parallel to make the overall speed faster. It is important to note that pre-parsing does not change the DOM tree, which leaves this work to the main parsing process and only parses references to external resources, such as external scripts, stylesheets, and pictures, which means that the external script does not manipulate the DOM tree. 
Stylesheet (style sheets)
Style sheets take another different pattern. Theoretically, since the stylesheet does not change the DOM tree, there is no need to stop parsing the document waiting for them, however, there is a problem, the script may request the style information during the parsing of the document, if the style has not been loaded and parsed, the script will get the wrong value, obviously this will cause a lot of problems, which seems to be an edge , but it is very common indeed. Firefox blocks all scripts while the stylesheet is still loaded and parsed, and chrome blocks the scripts only when the script tries to access certain style properties that might be affected by the non-loaded style sheet.
Introduction to how browsers work