The crux of the matter is as follows. The site has a sidebar (a menu that slides out to the right), the animation of which is built on CSS transitions. In the inactive state, the sidebar has the following code:
position: fixed; top: 0; bottom: 0; right: 0; opacity: 0; width: 300px; background: #fff; z-index: 9999; -o-transition: all 250ms ease-in-out; transition: all 250ms ease-in-out; transform: translate(300px, 0px);
in the active state, a class with the following code is added to it:
transform: translate(0px, 0px); opacity: 1;
The problem is that brakes are periodically observed when opening / closing the menu. The Google Chrome profiler does not really give any information due to freezes. It takes only 1-3 ms per animation frame, but the FPS can drop to 15-20 frames. Brakes come out periodically (at these moments the whole animation slows down), from the patterns I noticed that they often appear during periods of downtime (when no actions are performed on the site for 20-30 seconds).
I suppose the possible reason is partly in the hardware / software itself (although it is nimble), but I would like to eliminate the freezes. Hence the questions:
- What is the reason for such brakes, who faced this?
- What solutions did you use to make the animation smoother?
will-change: transform; does not help, because The browser renders everything in a separate layer even without it.
A set of the following actions helped to achieve smoother animation:
- The exact property of the transition (i.e. instead of "transition: all" we specify the specific property with which the animation is performed).
- The use of class manipulation in JS is not classList, but className. Switching to this solution allowed for real progress in animation fluidity. In particular, this decision was suggested by VK, the same scheme is used there. The className method is included in DOM Core (level 2), has almost complete compatibility with all browsers, and is also more efficiently processed by browser engines with minimal delays.