Determining the reason for dropping frames using CSS3 animations

I am trying to determine the cause of extreme animation slowdowns. As you can see (below), paint times sometimes dive and cause the frame rate to drop to <15 frames per second.

I can’t show the site, but I can tell you that it is not light at the front end, it is a design showcase site, so there are many large images animated from outside the viewing port. I need to establish whether this is just what they have to deal with, or if something can be done to reduce the time they draw.

All animations are performed using the translate() functions. CSS for this particular set of animations:

 .page { height: 100%; position: absolute !important; -webkit-transform: translateY(100%); transform: translateY(100%); /** * Override ng-animate-block-transition on this element. Has an important declaration. */ -webkit-transition: transform ease-in-out 0.5s !important; transition: transform ease-in-out 0.5s !important; } .page.ng-show { -webkit-transform: translateY(0); transform: translateY(0); } .animate-in-enter-complete .page-peak .page.ng-show { -webkit-transform: translateY(-3%); transform: translateY(-3%); } .animate-in-enter-complete .page-peak .page.page-next { -webkit-transform: translateY(95%); transform: translateY(95%); } 

And here is the profile that I made for this particular animation. The root of the #document layer, I am new to these tools, but does this mean that it repaints the entire DOM tree?

How can I find out what causes this?

Screenshots of profiling tools

+5
source share
3 answers

Optimization just guesses without having a page to look at, but I can give you some thoughts that might be useful.

CSS transform and opacity properties do not trigger layout or paint. It doesn't matter if the animation is JavaScript or CSS. This should cause something other than transform . A complete list of works caused by individual CSS properties can be found in CSS Triggers , and you can find a complete guide to creating High - Performance animations on HTML5 rocks. I assume that you can do a lot of rendering, layout and optimization of paint.

Use will-change to make sure the browser knows what you plan on revitalizing. The will-change property allows you to inform the browser in advance what changes you can make to the element so that it can configure the appropriate optimizations to their necessity. Elements can be changed and made faster, resulting in a smoother experience. In the case of your example, adding changes to the transforms looks like this:

 .page { will-change: transform; } 

Note. Do not use will-change for too many elements, this will lead to the opposite. Chrome, Firefox, and Opera currently support this feature. It seems to get support from all modern browsers in the future .

+6
source

Some new CSS3 features can be very heavy:

  • box-shadow combined with border-radius
  • filter (grayscale, blur, contrast, ...)
  • transform
  • ...

By enabling continuous redrawing, you can see which rule causes this load when it is turned off. See this post

If you find that this conversion causes this load, it may be due to the fact that hardware acceleration is not used by the browser. You can force it to use 3D rendering, which will not affect your transformation. One of these rules can do the trick:

 transform: translateZ(0); /* or */ transform: translate3d(0,0,0); /* or */ perspective: 1000; backface-visibility: hidden; 

If not, you can rethink your integration by wondering if the rule really causes the load.

+2
source

23 seconds to draw a single image, too much. They don’t need to β€œdo it,” just to find a mistake. Because there is a mistake in the code, in the design (for example, 2337 images per page) or somewhere else.

Not being able to see the site, nor an anonymous script that reproduces its behavior, nor even HTML (!), And without knowing the number of images, their size, etc., the only possible answer:

enter image description here

+2
source

Source: https://habr.com/ru/post/1206403/


All Articles