【 Interview Series 1 】 What is the meaning of rearranging and redrawing

Hello, I am Tao Weng

How do you understand rearranging and redrawing?

I find that many candidates fail to answer the key points. I feel like I have read relevant articles somewhere. It sounds scattered and illogical.

Error model

The typical interview process goes something like this:

Interviewer: How do you understand rearrangement and redrawing?

Candidate: Reordering is when the structure of the page changes, such as changing font sizes, adding and deleting DOM elements, etc. Redraw is the same structure of the page, but the appearance of the page is changed, such as changing the font color, background color and so on. All that happens is redraw.

Of course, he was right, and I couldn’t just say he was wrong and continue to guide

Interviewer: What does rearrangement have to do with redrawing?

Candidate: Rearrangement does not necessarily lead to redrawing, redrawing does not necessarily lead to rearrangement.

Interviewer: Why?

Candidate: Because the rearrangement structure has changed, it will definitely lead to redrawing.

This is my expression:

If you think the above answers are true, you should definitely take a look at the following.

I’m not going to skip it, I’m going to ask the browser again for key render paths to guide.

If you don’t know, I will guide it again (basically give up at this point).

Do you know what happens when a browser loads an HTML?

If you still don’t know, that’s the next problem.

If you know the key rendering path, the basic guide can still understand, if not clear, certainly can not understand the rearrangement and redraw.

The examination site

I generally examine two points in this question:

The browser’s key render path. If you can’t answer this, this question is usually cold.
Performance optimization, if reduced redraw and backflow, is certainly based on an understanding of key render paths (which is not the point).

review

The purpose of review is to know what the test point is. I will simply review it for you. For more detailed content, I hope I can introduce knowledge points (you can see the article RECOMMENDED by me at the end of the article for in-depth study).

We know that we can write HTML, CSS, and JavaScript to render a page on the screen, but how do browsers render our code to pixels on the screen? This requires understanding the concept of CRP:

The Critical Rendering Path is the sequence of steps a browser takes to convert HTML, CSS, and JavaScript into pixels on the screen. Optimizing key render paths improves rendering performance.

Here’s how it works: The DOM is created when the HTML is parsed, the HTML can request JavaScript, and JavaScript, in turn, can change the DOM. HTML contains or requests styles, in turn, to build CSSOM.

The browser engine combines the two to create a Render Tree, a Layout determines the size and location of all the content on the page, and once the Layout is determined, the pixels are painted onto the screen.

Optimizing key render paths can shorten the first render time. Understanding and optimizing key render paths is important to ensure that rearrangements and redraws can occur at 60 frames per second to ensure efficient user interaction and avoid nuisance.

Let’s look at the detailed process:

steps

1. Generate a DOM

DOM builds are incremental. The browser downloads bytes from the remote browser => Convert them into strings based on the corresponding encoding (such as UTF8) => Parse them into tokens through the AST => Generate Nodes => generate DOM.

A DOM node starts with a startTag token and ends with an endTag token. The node contains all the relevant information about the HTML element. This information is described using tokens. Nodes are connected to the DOM tree according to the token hierarchy.

If another set of StartTags and endTag tokens lies between a set of StartTags and EndTags, then there is a node within the node, and this is how we define the DOM tree hierarchy.

2. Generate CSSOM

The browser parses the CSS file to generate CSSOM. CSSOM contains all the styles of the page, that is, information about how to present the DOM.

CSSOM is like DOM, but different.

DOM constructs are incremental; CSSOM is not. CSS is render blocking: the browser blocks the page rendering until it has received and executed all the CSS.

CSS is rendering blocked because rules can be overwritten, so content cannot be rendered until CSSOM is complete.

3. Render Tree

The Render Tree contains both content and styles: THE DOM and CSSOM trees are combined into a Render Tree.

To construct the render tree, the browser examines each node, starting at the root of the DOM tree, and decides which CSS rules are added.

The render tree contains only the visible content (the part in the body).

The Head (usually) does not contain any visible information and is therefore not included in the render tree. If there is an element with display: None; , itself and its descendants will not appear in the render tree.

4. Layout

Once the render tree is built, the layout becomes possible. The layout depends on the screen size. Layout is the step that determines where and how to place elements on the page, how wide and tall each element is, and how relevant they are to each other.

Tip: a page rendered on different screen sizes, such as mobile and PC, display difference, in the previous steps are unchanged, only in the layout will be differentiated according to the screen size.

5. Paint

The final step is to draw the pixels on the screen, rasterize all the elements, and convert the elements into actual pixels.

Once the render tree is created and the layout is complete, the pixels can be drawn on the screen. When loading, the entire screen is drawn. After that, only the affected area of the screen is redrawn, and the browser is optimized to redraw only the minimum area that needs to be drawn.

The drawing time depends on what type of update is attached to the render tree. Drawing is a very fast process, so this is probably not the most effective part of focusing on improving performance

Reflow and Repaint

After the critical path rendering above, rearranging and redrawing is a trivial case.

Reflow: Rearrangement of elements when their positions change. Also called Reflow. At this point in the Layout phase, calculate the exact position and size of each element in the viewport of the device. When the position of an element changes, the position of both its parent and the elements following it can change, which can be very costly.

In answering the question of What rearrangement is, it’s not a change of position, it’s just Why, not What. What recalculates the exact position and size of each element within the device viewport.
Repaint: The style of the element changes, but the position does not. At this point, during the Paint phase in the critical render path, each node in the render tree is converted to an actual pixel on the screen, a step commonly referred to as drawing or rasterization.

The key to answering the question of What redraw is is to convert each node in the render tree into an actual pixel on the screen during the Paint phase of the key render path, which is What.

JavaScript with critical path rendering

The previous steps are mostly about the relationship between HTML, CSS and CRP. Finally, we will talk about the relationship between JS and CRP. Take a look at the graph at the beginning of this article.

JavaScript is executed before the render tree is generated. This is why loading, parsing, and execution of JavaScript blocks DOM building, blocking page rendering.

This is actually quite reasonable

Because JavaScript can modify the content of a web page, it can change the DOM, and if it doesn’t block, then you’re building the DOM here, and JavaScript is changing the DOM there, how do you make sure that you end up with the right DOM?

What’s wrong with getting a DOM in JS one second before and one second after? It creates a bunch of problems, so JS is blocking, it blocks the DOM build process, so you can’t get the element after JS in JS, because the DOM hasn’t been built there yet.

This is why we want to put js at the bottom of the page, trying to make sure that the DOM tree is generated before loading js.

Performance optimization

Based on the above analysis, simply say a few performance optimization methods, you can analyze why these methods can do performance optimization.

Reduce DOM tree rendering time (e.g. lower HTML hierarchy, make tags as semantic as possible, etc.)
Reduce CSSOM tree rendering time (lower selector level, etc.)
Reduce the number and size of HTTP requests
Place the CSS at the beginning of the page
Leave the JS at the bottom of the page and avoid blocking JS loading with defer or Async whenever possible, ensuring that the DOM tree is generated before loading the JS
Replace @import with link
If the page has less CSS, use inline
To reduce white screen time, a DOM tree is quickly generated when the page loads

Correct performance optimization thinking

When you encounter a performance problem, you should never go to the Internet to find some performance optimization methods, and then no matter what, the whole up, such a large probability is not useful.

The first thing is always to analyze where the performance bottlenecks are.

For example, if you encounter performance problems with the first screen loading, you need to check whether the network is slow due to large resource volume, slow processing at the back end, or slow loading due to too many resources.

If none of this is the case, it may be due to slow rendering, and then analyze the Performce panel to see if js execution is slow or what.

If you encounter a performance problem with WebPack, such as a large amount of packaged resources, and you want to solve the problem, you should not just find a few optimization methods to start the process.

Instead, the webpack-bundle-Analyzer plug-in should be used to analyze why packages are large first.

Is the dependency package too big to do on-demand loading?
Or are several versions of the same dependency repeatedly packaged?
Or because SRC is too big, do you need to do dynamic loading?
Or because of the other components of webpack-bundle-Analyzer analysis to find problems.

Finally, to sum up, we should first find the cause of performance bottleneck through various analysis tools, and then find the corresponding optimization method according to this reason, to the right remedy.

Whether it is the answer in the interview, or when they usually deal with problems, only analyze the problem, a lot of solutions, can not find the problem, fooling around is a waste of time.

Reference answer

I believe that after the review, the knowledge point should be clear, there is no need to say so much during the interview, say the key points, let the interviewer know that you understand it, if the interviewer is interested in it will continue to ask, this time to introduce the point of questioning with him in detail.

If I were asked this question, my answer would be something like this, fyi:

Rearrangement and redraw are two nodes in the browser’s key rendering path, which is DOM and CSSOM generating a rendering tree and then determining the size and location of all the content on the page through a layout step. Once the layout is determined, Draws (also called Paint) pixels onto the screen.

Rearrangement is when the position of the elements changes, the browser rearranges the layout step to resize and reposition the content on the page, and then redraws it to the screen, so rearrangement must result in redrawing.

If the position of the element has not changed, but only the style has changed, then the browser will skip the layout step and go straight to the drawing step, which is redraw, so redraw does not necessarily result in rearrangement.

Answer like this, I think in the vast majority of interviewers there can already get this question points.

If you have any other questions, please tell me in the comments section. I will continue to help you analyze them later.

For performance issues, reducing the redraw and backflow perception is not that important, because optimization is generally not obvious and does not answer the question much, more performance optimization is on the whole link optimization, such as the 8 points in the performance optimization title.

The last

I hope everyone can find the right job during the downturn.

About critical path rendering and rearrangement, redrawing, I finally could not help but recommend two articles of Da Mo teacher to you, have time to read a while.

Critical Rendering Path (CRP)
Understand the rearrangement and redrawing of the Web

Reference article:

Key render path
Developers.google.cn: key rendering path