This article is excerpted from the book "The Master of CSS" written by Tiffany Brown. The book is available in major bookstores around the world, and you can also purchase the e-book version here.
CSS certain properties and values ??trigger reflow, which is expensive and may reduce the user interface's response speed - page rendering, animation fluency and scrolling performance will be affected, especially on mobile phones and tablets on low-power devices such as TVs.
What is rearrangement? {.title}
Rearrangement refers to any operation that changes part or all of the layout of the page. For example, change the size of an element or update its left position. They cause the browser to recalculate the height, width, and position of other elements in the document.
Repaint (repaint) is similar to repainting, and forces the browser to re-render part of the document. For example, changing the color of the mouse when hovering over a button is a redraw operation. Redraw has less impact on re-arrangement because it does not affect the size or position of the node; however, redraw should also be minimized.
Rearrangement and redrawing are usually triggered by DOM operations, such as adding or removing elements. But they can also be caused by changes in attributes that affect element size, visibility, or position. This is true whether the changes are caused by JavaScript or CSS-based animations.
Note: Page loading {.title}
When the page loads, the browser parses the initial HTML, CSS, and JavaScript, which always triggers reordering and redrawing.
It is difficult to completely avoid redrawing and rearrangement in projects. However, we can use timeline tools to identify them and reduce their impact.
The timeline tool can be a little confusing at first. They measure the performance of the front-end and record the time it takes for various tasks to complete. By recording activity while interacting with the page, we can find out which CSS code can cause performance bottlenecks.
To use the timeline, click the Timeline tab in the Developer Tools interface. In Chrome, Opera, and Firefox, it is aptly named "Timeline". Safari named it the plural form "Timeline". Internet Explorer 11 uses the more descriptive name "UI Responsiveness". [9]
In any browser, press the "Record" button to start the recording process. Interact with the part of the page that has problems, and when finished, click the corresponding button to stop recording.
Depending on the browser you are using, you may see the data immediately, or after stopping the recording. Safari and Firefox display data in real time, while Chrome, Opera, and Internet Explorer render performance charts after you stop recording.
Document loading, function calls, DOM events, style recalculation, and drawing operations are all recorded in each browser, allowing us to outline the performance bottlenecks. As for CSS performance, we need to focus on at least two related aspects:
- A lot of style recalculation and drawing operations
- Long time-consuming operation, larger blocks in the timeline represent
To understand the actual situation, we will compare two basic documents, Example A and Example B. In both cases, we move a series of div{.literal} elements from x position 0 to x position 1000. Both examples use CSS conversion. However, in Example A, we will animate the left attribute. In Example B, we will use the transformation transformation and animate the transform attribute.
The marks of the two examples are the same (the results are shown in Figure 3.16):
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="utf-8">
<title>Performance example</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<button type="button" id="move">Move</button>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<div></div>
<??>
</body>
</html>
Figure 3.16. Our HTML demo page in Safari browser, the JavaScript code for both documents is also the same. Clicking the "Move" button will switch class on each div element: moved
var move = document.getElementById('move');
move.addEventListener('click', function(e) {
var objs = document.body.querySelectorAll('div');
Array.prototype.forEach.call(objs, function(o){
o.classList.toggle('moved');
});
});Our CSS code is a different part of the two. The CSS used in Example A is as follows:
After
div {
background: #36f;
margin-bottom: 1em;
width: 30px;
height: 30px;
position: relative;
left: 0;
transition: left 2s ease-in;
}
.moved {
left: 1000px;
}, this animation will generate a large number of style calculations and redraw indicators in our timeline. The following image shows the timeline output of this conversion in Safari (Figure 3.17), Chrome (Figure 3.18), Internet Explorer (Figure 3.19), and Firefox (Figure 3.20).
Figure 3.17. Timeline output of left position conversion in Safari browser Figure 3.18. Same output in Chrome browser Figure 3.19. Timeline output of left position conversion in Internet Explorer 11 browser Figure 3.20. The reason for the output in Firefox browser style calculation and redrawing is with us The properties of the conversion are related to: . left Attributes trigger reordering when changed, even if the changes are caused by animation or transformation. left
Now, let's take a look at the CSS of Example B:
div {
background: #f3f;
margin-bottom: 1em;
width: 30px;
height: 30px;
position: relative;
left: 0;
transition: transform 2s ease-in;
transform: translateX(0);
}
.moved {
transform: translateX(1000px);
}Here we use the conversion and convert between
and translateX(0). translateX(1000px)
In most browsers, conversions do not trigger reordering, and our timeline will contain fewer repaint operations. This is evident in Safari (Figure 3.21), Chrome (Figure 3.22), and Internet Explorer (Figure 3.23). Firefox is the exception; compare Figure 3.20 and Figure 3.24. The timelines of the left conversion and the conversion transformation are very similar.
Figure 3.21. Timeline output of -webkit-transform attribute conversion in Safari browser Figure 3.22. The same output of transform attribute using attribute in Chrome browser Figure 3.23. Output in Internet Explorer 11 browser transformFigure 3.24. Timeline output of attribute conversion in Firefox browser
## Identify the line of code to be removed {.title}
Unfortunately, there is no clear list of which properties will cause rearrangement and redrawing. Paul Lewis's CSS Triggers are closest, but it's Chrome-specific. However, browsers do behave similarly for many of these properties, so this resource at least gives you an idea of ??which properties may cause problems.
Once you know which properties may be problematic, the next step is to test the hypothesis. Use a comment or add a temporary x- prefix to disable the property and rerun the timeline test.
Remember that performance is relative, not absolute or perfect. The goal is to improve: make it perform better than before. If the performance of the attribute or effect is too slow to accept, it is completely removed.
The above is the detailed content of Debugging CSS for UI Responsiveness. For more information, please follow other related articles on the PHP Chinese website!