CSS3 Animation Lag Performance Optimization Solution-excerpt

Recently in the development of small programs, like Vue, they all have a life cycle.

• OnLoad Monitor Page load

• Onready Monitoring page First render complete

• OnShow Monitor page display

What the hell does that mean?

So this touched my knowledge blind area, but the project in the stumbling completed almost, but encountered the CSS3 animation rendering performance problems, so I was forced to, and then back to the browser rendering the process of the Web page, to find the crux of the animation lag.

The process of rendering Web pages by the browser is as follows:

• Creating a Document Object Model (DOM) using HTML

• Creating a CSS Object model using CSS (CSSOM)

• Execute scripts based on DOM and CSSOM (Scripts)

• Merging DOM and CSSOM to form a render tree

• Use the render tree layout (layouts) for all elements

• Render (Paint) all elements

This can be combined with Alon's front-end performance optimization and the display page layout of the Android developer options.

Display page layouts for Android developer Options

How to tell if the mobile app is Native,webview or Hybird?

Simply put, the app is a large chunk is white without red line marked out, but there are buttons, pictures, etc., is webview, that is, through a pseudo-browser to request the data, broken web when the app is not open to show anything on the top

OnLoad Monitor Page load

After rendering the interface, that is, after the native interface is generated by the configuration item in. JSON, the portion of the webview is rendered and a page is called only once.

Onready Monitoring page First render complete

A page is called only once, representing that the page is ready to interact with the view layer.

OnShow Monitor page display

Each time you open the page, you call the function.

where should we put the animation?

It should be in the onshow, because I can see the animation every time I open it.

Why would Chuck?

There is a premise that must be mentioned, front-end developers know that the browser is single-threaded run. But we have to make clear the following concepts: Single-threaded, main thread, and synthetic threads.

Although the browser execution JS is single-threaded execution (note that is executed, not that the browser has only 1 threads, but the runtime, runing), but actually the browser's 2 important threads of execution, these 2 threads work together to render a Web page: the main thread and the composition thread.

In general, the main thread is responsible for: running JavaScript, calculating CSS styles for HTML elements, layout of pages, drawing elements into one or more bitmaps, and handing these bitmaps to a composition thread.

Accordingly, the compositing thread is responsible for drawing the bitmap onto the screen through the GPU, informing the main thread that the page is visible or is about to become visible in the bitmap, calculating which part of the page is visible, and calculating which part is about to become visible when you scroll the page. When you scroll the page, move the elements of the corresponding position to the viewable area.

So why does it cause animation to stutter?

The reason is that the primary thread and the composition thread are not properly dispatched.

Here is a detailed explanation of the reasons for the unreasonable scheduling.

When using height,width,margin,padding as the value of transition, it causes heavy workload on the main thread of the browser, such as from margin-left:-20px rendering to margin-left:0. The main thread needs to calculate the style margin-left:-19px,margin-left:-18px, until margin-left:0, and each time the main thread calculates the style, the compositing process needs to be drawn to the GPU and then rendered to the screen, A total of 20 main thread rendering, 20 synthetic thread rendering, 20+20 times, total 40 calculations.

The main thread of the rendering process, you can refer to the Browser rendering Web page process:

• Creating a Document Object Model (DOM) using HTML

• Creating a CSS Object model using CSS (CSSOM)

• Execute scripts based on DOM and CSSOM (Scripts)

• Merging DOM and CSSOM to form a render tree

• Use the render tree layout (layouts) for all elements

• Render (Paint) all elements * *

That is, the main thread needs to perform the four phases of Scripts,render Tree, layout, and paint each time.

If you use transform, such as Tranform:translate ( -20px,0) to Transform:translate (0,0), the main thread only needs to be tranform:translate once ( -20px,0) To Transform:translate (0,0), then the synth thread goes to convert the -20px to 0px at once, so the total 1+20 calculation.

It may be said that this has increased 19 times, what good performance?

Assume 10ms at a time.

That would reduce the time-consuming of about 190ms.

Some people will say, spicy chicken, only 190ms, no matter.

So if Margin-left is from -200px to 0, one 10ms,10ms*199≈2s.

Some people will say, spicy chicken, also on the 2s, does not matter.

Have you forgotten the single thread?

If the page has 3 animations, 3*2s=6s is the 6s performance boost.

Since the data is speculative, so for the time being without regard to its authenticity, I did an experiment with Chrome Devtools's performance later in the article.

To know, in the "Customer first" today, a good user experience is all products must abide by a rule, whether for developers or product managers, the pursuit of extreme performance is our ability to create a good product must be the quality.

May have looked at my slightly unprofessional analysis, everyone on the main thread, synthetic threads and their work on the 2 different animation schemes on the workflow is not very understanding, you can go to read a translation of the blog (the original link has been invalidated): in-depth browser understanding of CSS animations and Performance issues with transitions

This article perfectly describes the difference between the main thread of the browser and the composition threads, and a comparison of 2 animation schemes that vary in height from 100px to 200px, and the entire workflow of the main thread and the synthetic threads is thoroughly explained, and it is really recommended to read it carefully.

Back to summarize, CSS3 animation of the solution:

When animating with CSS3 transtion, prioritize transform, and try not to use height,width,margin and padding.

Transform provides us with a rich API, such as Scale,translate,rotate, and so on, but you need to consider compatibility when you use it. In fact, for most CSS3, mobile support is better, and desktop side support requires extra attention.

Add: In order to enhance the persuasion of this article, specifically home to do an experiment, the code is as follows.

2. <!DOCTYPE html>

8.  <meta charset="utf-8" />

10.  <meta http-equiv="X-UA-Compatible" content="IE=edge">

12.  <title>Page Title</title>

14.  <meta name="viewport" content="width=device-width, initial-scale=1">

16.  <style>

18.    .margin-transition{

20.      /* margin-left: 0; */

22.      background: rgba(0,0,255,0.3);

24.      transition: margin-left 1s;

26.    }

28.    .transform-transition{

30.      /* transform: translate(0,0); */

32.      background: rgba(0,255,0,0.3);

34.      transition: transform 1s;

36.    }

38.    .common{

40.      height: 300px;

42.      width: 300px;

44.    }

46.  </style>

50. <body>

52.  <div class="margin-transition common" id="marginTransition">

54.    <p>transition:margin-left 1s</p>

56.  </div>

58.  <div class="transform-transition common" id="transformTransition">

60.      <p>transition:tranform 1s</p>

62.  </div>

64.  <button id="control">见证奇迹</button>

66.  <script>

68.      var btn = document.getElementById(‘control‘);

70.      var marginTransition = document.getElementById(‘marginTransition‘);

72.      var transformTransition = document.getElementById(‘transformTransition‘);

74.      btn.addEventListener("click",function(){

76.        console.log(marginTransition.style,transformTransition.style)

78.        marginTransition.style.marginLeft = "500px";

80.        transformTransition.style.transform = "translate(500px,0)"

82.      })

84.  </script>  

86. </body>

I'll use Chrome Devtools's performance tool to compare performance differences.

First look at the margin animation, dynamic modification of the DOM node Margin-left value from 0 to 500px;.

1. transition: margin-left 1s;

Then look at the transform animation, dynamically modifying the transform value of the DOM node from translate (0,0) to translate (500px,0).

1. transition: transform 1s;

Maybe the picture is not good enough to explain the performance difference, so let's make a time-consuming comparison table, so we can calculate it conveniently.

Time Consuming	margin	Transform
Summery	3518ms	2286ms
Scripting	1.8ms	2.9ms
Rendering	22.5ms	6.9ms
Painting	9.7ms	1.6ms
Other	39.3ms	25.2ms
Idle (Browser is waiting on the CPU or GPU to do some processing)	3444.4ms	2249.8ms
GPU Usage	4.1MB	1.7MB

By the above table we can calculate the performance difference parameter when the Margin,transform and transition combination realizes the CSS3 animation effect.

Key Performance Parameters	margin	Transform
Actual animation time elapsed (total time minus idle time)	73.6ms	36.2ms

It is calculated that the transform animation takes approximately 0.49 times times the time of the margin animation and optimizes performance by 50%.

Because I am not very clear about the specifics of other things, the actual animation time here is also likely to reduce the time in other, and the following table is the data we lost.

Key Performance Parameters	margin	Transform
Actual animation time elapsed (total time minus other time and idle time)	34.3ms	11ms

It is calculated that the transform animation takes approximately 0.32 times times the time of the margin animation, and the performance optimization is nearly 70%.

That is, whether we subtract or not subtract other's time, we use transform to achieve animation faster than the margin animation.

Imprecise to get a small conclusion:transform than margin performance is good 50%~70%.

Although there will be 50%~70% performance improvement, but need to pay attention to the hardware differences, hardware can not be found in the case of lag or other performance problems.

For example, in the process of developing a small program, the emulator is located on the desktop side, so its hardware performance is better, such as CPU,GPU. But once running on the mobile side, such as iOS or Android, performance problems can occur because the hardware conditions on the mobile side are less than the PC-side result.

As a result, performance problems persist, except that hardware differences can lead to different levels of performance impact.

So we go back and summarize the solution to the CSS3 animation:

When animating with CSS3 transtion, prioritize transform, and try not to use height,width,margin and padding.

CSS3 Animation Lag Performance Optimization Solution-excerpt