WebKit Browser Rendering Impact factor analysis

Introduction: Browser rendering has a great impact on performance, especially in the mobile page, on the macro, we can refer to Yahoo that 20 of the military to operate, but at the micro-rendering level, there is not a set of relative molding theory as the basis.

This article is just a tip, take everyone into the micro-optimization field, the actual rendering optimization of this piece, there are many techniques and methods need to dig. This article is also more messy, hope to forgive!!

Let's take a look at a diagram on the Chrome Timeline tool:

On the timeline, we see columns of 6 colors, these 6 types of pillars build the entire WebKit browser rendering process.

Simple classification: Blue for loading, yellow for script execution, purple for calculation style and layout, green for paint composition, white for idle time, Gray for other time. The main view here is the front three.

Such as:

The blue loading contains a variety of resource loads that can be seen in the Blue section during the page initialization loading phase, because resources are being loaded (loading HTML, CSS, JS, img, flash, MP3, etc.). ）

The actual meaning of the various rendering sections on Chrome: Parse Html:

Sends an HTTP request, gets the requested content, and then parses the HTML process.

Recalculate Style:

Recalculate the style, it calculates a style, and the layout does something completely different. Layout calculates the absolute position and size of an element, or "Compute layout".

The thing to do when the recalculate is triggered is to handle the style that JavaScript sets for the element. The recalculate style calculates the render tree (render tree) and then starts the page rendering from the root node, attaching the CSS to the DOM process.

any attempt to change the style of an element will trigger recalculate. As with layout, it is triggered only after JavaScript execution is complete.

Layout:

Calculates the layout on the page, that is, the position and size of the element in the document. As mentioned above, layout calculates location information. Any style that is likely to change the position or size of an element will trigger this layout event, such as width, height

Rasterizer:

Rasterization, the general Android phone will be rasterized, the grating is mainly for the graphics of a grid process. Low-end phones in this part of the time is quite a lot.

Paint:

any changes to the contents of the page will trigger the paint. Include drag scroll bar, mouse selected text, and so on without changing the style, only change the display results of the action will trigger paint.

The job of paint is to show the user the part of the document that is visible to the user. Paint is drawing the results of layout and recalculate calculations directly on the browser form, which does not implement specific element calculations.

Image Decode:

Image decoding, the process of parsing a picture into a browser.

Image Resize:

Image size settings, image loading analysis, if you find that the size of the image is not the actual size (CSS changed the width of the height), you need to resize. The larger the resize, the longer it takes, so try to output the original size of the picture.

Composite Layers:

Finally, merge the layers and output the page to the screen. The browser draws some special-style dom structures to other layers during the rendering process, somewhat similar to the Photoshop layer concept. A picture is composed of multiple layers in Photoshop, and the page that the browser eventually displays is actually composed of multiple layers.

What causes the new layer to be created:

1. CSS properties for 3D or perspective transformations
2. <video> elements using hardware accelerated video decoding
3. <canvas> elements of 2D context with 3D (WebGL) context or hardware acceleration
4. Combination plug-in (i.e. Flash)
5, with CSS transparency animation or using animated WebKit transform elements
6. Elements of CSS filters with hardware acceleration

In CSS, different attributes will trigger different layout or paint, so you should take these aspects into account when changing CSS properties via JS. Such as:

Then refer to another diagram to see what the CSS different properties trigger:

A rendering problem with CSS properties can be seen in the table below, FQ view: https://docs.google.com/spreadsheet/pub?key= 0ark1uipy0sbddhvlc1oztflja1dhb25qnghjmxn5mxc&single=true&gid=0&output=html

How to optimize rendering time

1, in order to ensure the flow of the page, it is necessary to ensure that no 2 render tree updates occur within 60fps. For example, only a few of the following actions in 16ms are normal and correct :

2, the page scrolling, you need to avoid unnecessary rendering and long-time rendering.

Unnecessary rendering includes:

1) position:fixed

Fixed positioning will not stop rendering when scrolling, especially if there is a fiexd at the top of the page, there is a fixed at the bottom of the page similar to the top, then the entire page will be rendered when scrolling, which is very inefficient. Can add transform: translatez (0); Solve.

2) Overflow:scroll

3) Hover effects

Some: hover pseudo-class will be accidentally triggered when the page scrolls, such as the hover effect has a shadow, rounded corners and other time-consuming properties, the proposed page scrolling, first cancel the hover effect, scrolling stop after adding hover effect. This can be controlled by adding a class name in the outer layer.

4) Touch Listeners

Long-time rendering includes:

1) Complex CSS

2) Image decodes

Here in particular the images of image decodes and Images Resize these 2 processes on the mobile side are very time-consuming, such as:

3) Large empty layers (large empty layer, DIV)

Reference: Https://speakerdeck.com/addyosmani/velocityconf-rendering-performance-case-studies

WebKit Browser Rendering Impact factor analysis