CSS3 Animation (Performance)_html/css_WEB-ITnose

Written in front

Compared with PC scenarios, high-performance mobile Web needs to consider more and more complex factors. We summarize them as follows: Traffic, Power consumption and fluency.

In the PC era, we pay more attention to the smoothness of the experience, but in the rich scenarios of the mobile side, we need to pay extra attention to the usage of user base station network traffic and device power consumption. situation.

Regarding fluency, it is mainly reflected in front-end animation. In the existing front-end animation system, there are usually two modes: JS animation and CSS3 animation. JS animation is a solution that uses JS to dynamically rewrite styles to achieve animation capabilities. It is a recommended solution for PCs that are compatible with low-end browsers. On the mobile side, we choose the native browser implementation with better performance: CSS3 animation.

However, CSS3 animations will face more performance problems than PCs in mobile multi-terminal device scenarios, mainly reflected in animation stuttering and flickering.

At present, there are several main methods to improve the mobile CSS3 animation experience:

Use as much hardware capabilities as possible (3D deformation will consume more memory and power consumption, so there should be Only use it when there is a performance problem, and it is a trade-off)

1. Use 3D deformation to turn on GPU acceleration

-webkit-transform: translate3d(0, 0, 0);-moz-transform: translate3d(0, 0, 0);-ms-transform: translate3d(0, 0, 0);transform: translate3d(0, 0, 0);

2. There is flickering during animation (usually occurs when the animation starts), you can try the following Hack

-webkit-backface-visibility: hidden;-moz-backface-visibility: hidden;-ms-backface-visibility: hidden;backface-visibility: hidden;-webkit-perspective: 1000;-moz-perspective: 1000;-ms-perspective: 1000;perspective: 1000;

3. The animation smoothness of an element moved 500px to the right through translate3d will be significantly better than using the left attribute

CSS animation properties will trigger the entire page to reflow layout, repaint, and reorganize recomposite

Paint is usually the most expensive among them. Try to avoid using CSS animation properties that trigger paint. This is also Why do we recommend using webkit-transform: translateX(3em) in CSS animations instead of using left: 3em, because left will additionally trigger layout and paint, while webkit-transform only triggers the entire page composite (this is also why it is recommended in CSS animations Use the solution of webkit-transform: translateX(500px) instead of using left: 500px)

#ball-1 {  transition: -webkit-transform .5s ease;  -webkit-transform: translate3d(0, 0, 0);}#ball-1.slidein {  -webkit-transform: translate3d(500px, 0, 0);}#ball-2 {  transition: left .5s ease;  left: 0;}#ball-2.slidein {  left: 500px;}

div {  -webkit-animation-duration: 5s;  -webkit-animation-name: move;  -webkit-animation-iteration-count: infinite;  -webkit-animation-direction: alternate;  width: 200px;  height: 200px;  margin: 100px;  background-color: #808080;  position: absolute;}/*第一种方案  用css属性left*/@-webkit-keyframes move{    from {        left: 100px;    }    to {        left: 200px;    }}/*第二种方案  用css3动画属性translateX*/@-webkit-keyframes move{    from {        -webkit-transform: translateX(100px);    }    to {        -webkit-transform: translateX(200px);    }}

whenever possible Use less box-shadows and gradients

Box-shadows and gradients are often performance killers of the page, especially when they are used in one element at the same time, so embrace flat design

Keep animated elements out of the document flow as much as possible to reduce reflow

position: fixed;position: absolute;

Optimize DOM layout performance

// 触发两次 layoutvar newWidth = aDiv.offsetWidth + 10;   // ReadaDiv.style.width = newWidth + 'px';     // Writevar newHeight = aDiv.offsetHeight + 10; // ReadaDiv.style.height = newHeight + 'px';   // Write// 只触发一次 layoutvar newWidth = aDiv.offsetWidth + 10;   // Readvar newHeight = aDiv.offsetHeight + 10; // ReadaDiv.style.width = newWidth + 'px';     // WriteaDiv.style.height = newHeight + 'px';   // Write

Continuously reading the offsetWidth/Height properties and continuously setting the width/height properties can trigger the layout one less time than reading and setting individual properties separately. From the conclusion, it seems to be related to the execution queue. Yes, this is the optimization strategy of the browser. All operations that can trigger layout will be temporarily put into the layout-queue. When it must be updated, the results of all operations in the entire queue will be calculated , so that you can only One-time layout to improve performance.

Under what operations will the layout be updated (also called reflow or relayout)?

Element: clientHeight, clientLeft, clientTop, clientWidth, focus(), getBoundingClientRect(), getClientRects(), innerText, offsetHeight, offsetLeft, offsetParent, offsetTop, offsetWidth, outerText , scrollByLines(), scrollByPages(), scrollHeight, scrollIntoView(), scrollIntoViewIfNeeded(), scrollLeft, scrollTop, scrollWidth

Frame, HTMLImageElement: height, width

Range: getBoundingClientRect(), getClientRects()

SVGLocatable: computeCTM(), getBBox()

SVGTextContent: getCharNumAtPosition(), getComputedTextLength(), getEndPositionOfChar(), getExtentOfChar(), getNumberOfChars(), getRotationOfChar(), getStartPositionOfChar() , getSubStringLength(), selectSubString()

SVGUse: instanceRoot

window: getComputedStyle (), scrollBy(), scrollTo(), scrollX, scrollY, webkitConvertPointFromNodeToPage(), webkitConvertPointFromPageToNode()

CSS properties behavior table in CSS animation