In-depth analysis of page rendering_html/css_WEB-ITnose

Basic rendering process

After the resources requested by the user reach the rendering engine through the browser's network layer, the rendering work begins. Each rendering document usually does not exceed 8K data blocks. The basic rendering process is as shown below: DOM tree;

Step 2: Next, the CSS styles introduced whether inline, external or embedded will also be parsed and another tree used to render the DOM tree will be rendered - rendering Tree (render tree), the rendering tree contains rectangles with display attributes such as color, size, etc. The order of these rectangles is consistent with the display order;

The third step: Then lay out each node of the rendering tree Process and determine its display position on the screen;

Step 4: Traverse the rendering tree and draw each node using the UI backend layer mentioned in the previous chapter.

The above steps are a gradual process. In order to improve the user experience, the rendering engine tries to display the results to the end user as quickly as possible. It does not wait until all HTML has been parsed before creating and laying out the render tree. It will display the received partial content first while obtaining the document content from the network layer.

Different rendering engines have different rendering processes

The above only introduces the general processing flow of rendering engines. The specific steps may be different for different rendering engines. Take the common webkit and gecko Let’s talk.

First is the detailed rendering process of webkit:

The gecko rendering process of browsers such as Firefox:

From the above two It can be seen from the picture that although the two use different "professional terms", it can be seen from the picture that the rendering processes of the two are similar. It is precisely because of this that we can separate the specific processes.

So how to write efficient css code? Before this question, let’s first take a look at the inefficient way of writing code:

a. Use wildcards

b. Use tags as key selectors

body * {...}hide-scrollbars * {...}

c. Superfluous writing

ul li a {...} #footer h3 {...} * html #atticPromo ul li a {...}

d. Add the :hover pseudo-class to the non-connection tag. This will cause problems for pages using strict doctype under IE7 and IE8. slow.

ul#top_blue_nav {...} form#UserLogin {...}

Why not be efficient?

First understand the process of browser parsing HTML code: building a dom tree, and each element to be displayed on the page will be created into this dom tree. Whenever a new element is added to the DOM tree, the browser will search the CSS style sheet through the CSS engine to find the style rules that match the element and apply them to the element. The css engine searches the style sheet and matches each rule from right to left.

h3:hover {...} .foo:hover {...} #foo:hover {...} div.faa :hover {...}

After understanding the process, we can see that we can optimize our css code from two aspects:

1. The fewer the number of defined css style rules, the better, so quickly delete the css file Unnecessary style definitions;

2. Optimize the writing method of selectors for each rule, and try to let the CSS engine know at a glance whether this rule needs to be applied to the current element, so that the engine can avoid unnecessary mistakes. detour.

Optimization suggestions:

a, avoid using wildcards; b, let the css engine quickly identify whether the rule applies to the current element: use multiple ids or class selector, use less tag selectors;

c, don’t add id and class or tag and class, etc. in succession;

d, try to avoid using descendant selectors, remove For unnecessary ancestor elements, you can consider using the class selector to replace the descendant selector;

e, avoid adding :hover pseudo-classes to non-connected tags.

Then there are the following things that need to be paid attention to:

/*给无序和有序的li定义不同颜色，你可能会这样写：*/ ul li {color: blue;} ol li {color: red;} /*给li添加class，这样定义效率会更高：*/ .unordered-list-item {color: blue;} .ordered-list-item {color: red;}

1. Avoid using css expressions

css expressions only work in IE browser, Microsoft It is not recommended after IE8 because it will seriously affect page performance: any time, no matter any event is triggered, such as the resize event of the window, mouse movement, etc., the css expression will be recalculated.

Second, place the css file at the top of the page

Putting external or inline style sheets in the body part will affect the speed of page rendering, because the browser can only complete downloading of all style sheets. Then the other content of the page will be downloaded. In addition, inline style sheets (styles placed within c9ccee2e6ea535a969eb3f532ad9fe89) may cause the page to re-render or display or hide certain elements in the page. It is recommended not to use inline style sheets.

3. Specify the size of the page image

Specify the page image size, which must conform to the actual size of the image (do not scale the image by specifying the size), which can avoid page structure effects caused by size changes. changes, so it is beneficial to speed up page rendering.

4. The document encoding is indicated on the header of the page

HTML documents are transmitted across networks in a data stream containing document encoding information. The encoding information of the page is usually specified in the header information of the HTTP response or in the HTML markup within the document. The client browser can only render the page correctly after determining the page encoding. Therefore, most browsers (except ie6, ie7, and ie8) will buffer a certain number of bytes of data before drawing the page or executing any javascript code. Find encoding information from it. The number of bytes pre-buffered in different browsers is different. If the browser has not found the encoding information of the page after receiving the set amount of pre-buffered data, it will start rendering the page according to the default encoding specified by each browser. If the page encoding information is obtained again at this time, it will not be the same as the encoding currently used. If it is inconsistent, the entire page will have to be re-rendered, and in some cases the data will even need to be re-obtained. Therefore, for pages whose size exceeds 1KB (according to tests in various browsers, the maximum amount of pre-buffered data is 1KB), encoding information should be indicated as early as possible.