WebKit rendering mechanism

Recently saw the < WebKit Technology Insider, although not fully understood, but the browser rendering mechanism is also a relatively complete understanding.

We enter the URL from the browser address bar from the beginning to the Web page is fully presented in front of, probably through a process: the URL is resolved by DNS to IP address--TCP connection via IP address, send HTTP request, server processing request and return response, The browser resolves the render page and disconnects the TCP connection

But how does the browser parse the rendered page? This involves the browser's kernel, which is the browser's rendering engine (which should be strictly the rendering engine + JavaScript engine), and the rendering of the page is done by the rendering engine. Note that the browser and browser kernel is a different concept, the browser refers to Chrome, Firefox, and so on, while the browser kernel is Blink, Gecko, etc., the browser kernel is only responsible for rendering, GUI and network connection and other cross-platform work is browser implementation. The main rendering engines include Trident, Gecko, Webkit, respectively, ie, Firefox, and Chrome (in 2013, Google announced the Blink kernel, which was actually copied from Webkit). The general rendering engine mainly includes the HTML interpreter, CSS interpreter, JavaScript engine, layout, drawing and other modules. Of course, these modules also rely on many other basic modules.

Let's start with a brief look at the work done by the main modules of the rendering engine (all of the following are described in WebKit)

HTML interpreter: The work of the HTML interpreter is to interpret the HTML pages and resources obtained by the network or local disk from the byte stream into the structure of the DOM tree (first, the byte stream, after decoding is the character stream, and then through the lexical analyzer will be interpreted as a word (TOKENS), The parser is built into a node, and finally these nodes are set up as a DOM tree.

CSS interpreter: The CSS string is processed by the CSS interpreter and becomes the internal rule representation of the rendering engine. (after the style rule is established, WebKit saves the result of the rule, and when the DOM node is established, WebKit chooses the appropriate style information for the visual node, which is the style rule match)

JavaScript engine: To process and execute JavaScript code, a JavaScript engine can include the following sections

The main work of the compiler is to compile the source code into an abstract syntax tree, and in some engines include the conversion of the abstract syntax tree to bytecode (JavaScriptCore engine).

Interpreter-In some engines, the interpreter mainly receives the bytecode, interprets the execution bytecode, and relies on the garbage collection mechanism.

JIT tool, convert bytecode or abstract syntax tree to local code (V8 engine)

Garbage collector and analysis tools

Layout: Calculate the position, size, and other information of the RenderObject object

Drawing: Drawing a built-in rendering internal presentation model using a graphics library

The final rendering of the page is the result of the integrated processing of the above modules. Depending on the flow of data, the rendering process can be divided into three stages, the first phase is from the URL of the Web page to the completion of the DOM tree, the second stage is from the DOM tree to the completion of the WebKit drawing context, the third stage from the drawing context to the final image generation.

Describing the Web page URL to the entire process of building the DOM tree, the numbers represent the basic order, but are not strictly consistent because the process may be duplicated or crossed.

The specific process is as follows:

1 when the user enters the URL of the Web page, the WebKit invokes the resource loader to load the corresponding Web page.

The 2 loader relies on the network module to establish a connection, requests occur, and responses are received.

3 WebKit receives data from various web pages or resources, some of which may be obtained synchronously or asynchronously.

4 pages are presented to the HTML interpreter as a series of words (tokens)

The 5 interpreter constructs a DOM tree based on the Word construction node.

6 If the node is JavaScript code, call the JavaScript engine to interpret the execution.

7 JavaScript code may modify the structure of the DOM tree.

8 If there are nodes that need to rely on other resources, such as slices, CSS, videos, etc., call the resource loader to load them, but this process is asynchronous and does not hinder the continuation of the current DOM tree. If it is a JavaScript resource URL (not marked asynchronously), you need to stop building the current DOM tree until the JavaScript resource is loaded and interpreted by the JavaScript engine to continue creating the DOM tree.

In the above process, the page in the loading and rendering completed the process will be issued "Domcontent" event and "onload" event, respectively, the DOM tree is built and the DOM tree and all its dependent resources are loaded. In general, the "Domcontent" event occurs before the "onload" event.

The next step is to webkit the RenderObject tree to the drawing context with CSS and dom trees.

1 CSS files are interpreted as internal representation results by the CSS interpreter

2 after the CSS interpreter finishes working, append the interpreted style information to the DOM tree, which is the RenderObject tree

3 RenderObject When a node is created, WebKit creates a renderlayer tree based on the hierarchy of the page, creating a virtual drawing context.

The creation of the RenderObject tree does not cause the DOM tree to be destroyed, and the above four internal representations of the structure persist until the page is destroyed.

Finally, the final image is generated based on the drawing context, which relies primarily on the 2D and 3D graphics libraries.

A simple description of the build process is as follows:

This is the end of the entire rendering process, from the entire process of rendering we can also find that the original CSS, pictures, video and other resources loaded is asynchronous, and the construction of the DOM tree is concurrent, and Javascript resources loading and execution is synchronous, this process will block the construction of the DOM tree, It will also hinder the download of subsequent resources (compared to slices), because at this time WebKit is ignorant of what resources are needed, which leads to a serious performance problem where resources cannot be downloaded concurrently. (In fact, WebKit takes a resource pre-scan and pre-load mechanism to implement concurrent downloads of resources without being hindered by Javascript execution, but still avoids this, because not all rendering engines have taken this into account). So from here we can also get some hints about rendering optimization:

1 It is best to place the script file at the end of the HTML file so that it does not block the construction of the DOM tree and concurrent downloads of resources

2 If you want to place the script file in front of the HTML file, add the "async" attribute or the "defer" attribute to the scripts tag. The former indicates that this is a piece of JavaScript code that can be executed asynchronously, and the latter indicates that the code is deferred until the DOM tree is ready after the JavaScript is loaded. If you add "async" and "defer" at the same time, "async" Overrides "defer" in browsers that support both properties. It is important to note that if the script file that is currently adding the "Async" attribute is dependent on other script files, the script file that adds the "async" attribute may result in scripts that are executed before the dependent script, even if the script file that relies on the script to add the "async" attribute is defined.

WebKit rendering mechanism