Front-end performance optimization: Detail rearrangement and redrawing of browser rendering

Front-end performance optimization involves computer network, data algorithms, graphics and image processing, browser rendering and other aspects of computer knowledge, often as front-end engineers love to discuss technology, and because of this, it is also one of the interview questions easily asked in the interview.

origin

This article is based on a random interview question and answer. From the perspective of browser rendering, it explores the ideas and practical suggestions for front-end performance optimization. Of course, browser rendering is a complex process, and the author of this article will start with two key words: rearrangement and redrawing.

The directory structure

The general idea of the article is as follows:

• The process of a URL from input to page presentation

• DOM and JavaScript

• Why DOM manipulation is “slow”

• The process by which a browser parses HTML

• rearrangement

• redraw

• Optimization scheme

The process of a URL from input to page presentation

Before discuss the browser parses HTML, to understand the url from the input to the last page rendering process is a necessary step, it can help us to grasp the overall process, let us know it before know HTML parsing the details in which stages of the request cycle, it is of great help to our build perfect knowledge map.

First, we assume that the input URL request is the simplest Http request. Take GET request as an example, which can be roughly divided into the following steps:

1. The user enters the URL in the address bar of the browser. The browser will first look at the browser caches – system caches – router caches based on this URL. If there is one in the cache, skip to Step 6. If not, follow these steps.

2. The browser resolves the host name based on the entered URL.

3. The browser translates the host name into the server IP address. If yes, go to Step 4. If no, the browser sends a query request to the default DNS server and caches the current IP address to the DNS cache list. For details, see how to search for a domain name in DNS.

4. After getting the IP address, the browser parses the port number from the URL.

5. Once the IP and port are in hand, the browser establishes a TCP connection to the target Web server, known as the three-way handshake. Portal: Complete TCP connection.

6. The browser sends an HTTP request packet to the server.

7. The server returns an HTTP response packet to the browser.

8. Close the connection browser to parse the document.

9. If there are resources in the document, repeat actions 6, 7, and 8 until all resources are loaded.

The above steps outline the process of the browser from entering the URL to the final page rendering, but they are not very specific, such as what type of request message the browser will encounter, what error scenarios the browser will parse the response message, and so on.

In fact, there will be some differences in the details of the process of accessing the server in different scenarios such as HTTP request, proxy and load balancing. However, this does not affect our understanding of the whole access link. Interested students can have a detailed understanding on the Internet, which will not be detailed here.

DOM and JavaScript

The Document Object Model (DOM) is a language-independent API for manipulating XML and HTML documents. On the Web side, we often use THE DOM to manipulate HTML, but DOM can also manipulate XML documents.

We now know that DOM is a language-independent API. In other words, DOM is a language-independent API. Other languages can implement specific APIS for manipulating DOM, but it is implemented in JavaScript in the browser. DOM is an important part of JavaScript coding these days, because JavaScript often manipulates underlying documents.

Why is DOM manipulation slow

Although DOM is implemented by JavaScript, DOM and JavaScript are implemented separately in browsers. For example, in IE, the implementation of JavaScript is named JScript and stored in the jscript.dll file. The DOM is in another library called mshtml.dll. In Safari, DOM and rendering are implemented using WebCore in Webkit, while JavaScript is implemented by a separate JavaScriptCore engine. In Chrome, WebCore is also used for rendering. The JavaScript engine is their own V8 engine.

DOM and JavaScript are implemented separately and independently, so every time you manipulate the DOM through JS, you need to connect THE JS and DOM first. We can understand this: Compare the DOM and JavaScript to two islands connected by a toll bridge. Each time you access the DOM, you need to cross the bridge and pay a toll. The more times you access the DOM, the higher the toll. Because browsers have a lot of access to the DOM, the “travel” and “operation” costs naturally increase, which is why DOM manipulation is slow

The steps the browser takes to render HTML

HTML rendering is roughly divided into the following steps:

1. HTML is parsed into a DOM Tree by an HTML parser, and CSS is parsed into a CSSOM Tree by a CSS parser.

2. After the DOM Tree and CSSOM Tree are parsed, they are attached together to form the Render Tree.

3. Node information calculation (rearrangement) is a process called Layout(Webkit) or Reflow(Mozilla). That is, the geometry information of each node is calculated according to the rendering tree.

4. Rendering (repainting) is a process called Painting or Repaint. That is, draw the entire page based on the calculated information.

In theory, every dom change or CSS geometry change will cause a browser rearrangement/redraw process, whereas non-geometric CSS changes will only cause a redraw process. So rearrangement always leads to redrawing, and redrawing doesn’t necessarily lead to rearrangement.

Rearrangement (Relayout/Reflow)

Before we figure out what rearrangement is, it’s important to remember that browsers render pages using a Flow Based Layout model by default.

The so-called rearrangement is actually based on the information of each render object in the rendering tree, calculate the geometry information of each render object (DOM object location and size), and place it in the correct position in the interface.

Since the browser rendering interface is based on the streaming layout model, that is, if the information of a DOM node is changed, the DOM structure needs to be recalculated and the interface is rearranged, causing backflow again. However, the change degree of this structure will determine the change scope of the surrounding DOM, namely the global scope and the local scope. Global scope is to rearrange the entire render tree from the root HTML, for example when we change the window size or orientation or change the root element size or font size; A local layout can be a rearrangement of a part of the render tree or a render object.

Here, summing up operations that would cause a rearrangement are:

1. Page rendered for the first time.

2. The browser window size changed. Procedure

3. The size or position of the element changed.

4. Element content changes (text number or image size, etc.).

5. Element font size changes.

6. Add or remove visible DOM elements.

7. Activate CSS pseudo-classes (such as: :hover).

8. Setting the style property

9. Query some properties or call some methods.

Rearrangement is also called reflux. In fact, the literal meaning of reflow is also reflux. The reason why it is called rearrangement may be because it is better to understand and more in line with the Thinking of Chinese people. Standard documents is called a reflux (Reflow), because the browser rendering is based on the fluid layout model, the flow is actually that we often say that the document flow, at the time of change when the dom or CSS geometric properties, document flows to change by volatile linkage, flow like a river of water, reflux is just like throw a stone into the river, It ripples, and then it ripples the water around it, and that’s why it’s called backflow, which is kind of a more standard way of thinking about it, but it doesn’t really matter what it’s called, it really matters that we understand the process.

Repainting

Redraw is a much simpler process than rearranging. Redraw is the process in which the browser assigns a new style to an element on a page without affecting its position in the document flow, such as changing the font color.

Common attributes that cause the browser to draw include:

Performance optimization

We know that manipulating the DOM is a costly operation, not only because of the link access between JS and the DOM itself, but also because of the chain reaction (rearrangement) caused by manipulating the DOM. Therefore, from the perspective of performance optimization, we can start from the following aspects:

• Reduce DOM manipulation

  • Minimize DOM access times and cache DOM access style information to avoid excessive backflow.

  • If you need to access the same DOM multiple times in a local method, store a reference to it first.

• Replace expensive apis with better apis, and transform and optimize the expensive set

  • QuerySelectorAll () instead of getElementByXX().

  • Turn on GPU acceleration for animation and hand over rendering calculations to GPU.

  • Avoid traversal with HTML collections (arrays of classes), because collection traversal is more expensive than true array traversal.

  • Reduce the number of event handlers with event delegates.

• Reduce the rearrangement

  • Avoid setting a lot of style attributes because changing the style of a node will trigger a reflow every time it is set, so it is better to use the class attribute

  • Implement the animation of the element, and its position property is best set to absoulte or fixed, so that it does not affect the layout of other elements

  • Animation implementation speed selection. For example, implementing an animation that moves at 1 pixel is the smoothest, but reflow is too frequent, consuming CPU resources, and moving at 3 pixels is much better.

  • Do not use a table layout, because if one element in the table triggers a reflow, the entire table will trigger a reflow. If you have to use a table, you can set table-layout: Auto; Or table-layout: Fixed renders the table line by line, which is also used to limit the scope of reflow

• CSS and animation processing

  • Use less CSS expressions

  • Reduce the use of JavaScript code to modify element styles and use class names to manipulate styles or animations.

  • Animation should be used on absolutely positioned or fixed positioned elements;

  • Hide out of the screen, or when the page is scrolling, try to stop the animation;

The final summary

This article mainly captures the steps of browser parsing and rendering HTML in the process from URL input to interface rendering to discuss the ideas and reasons of front-end optimization. The core ideas are discussed based on the relationship between rearrangement and redrawing. The themes are as follows:

• The url is the approximate step from input to final rendering.

• Rearrangement must redraw, redraw does not necessarily rearrange.

• Js manipulating the DOM is an expensive process.

• Enumerations of properties and methods that cause reordering/redrawing

• Optimization ideas (less DOM manipulation, replacement of high-performance apis, temporary references, less reordering, hardware acceleration enabled, etc.)

Finally, due to personal level reasons, if there is incomplete or omission of mistakes, please readers criticism and correction, all the way you, very grateful!

Thanks to this era, we can stand on the shoulders of giants and peep out the magnificence of the program world. I would like to travel through the mountains and rivers of the program world with a pure heart! May every colleague who walks in the world of program live the way they want in their hearts, come on.