The will-change CSS property lets browsers know in advance which element is going to be changed and in what way so that they can set up their optimizations before the element actually gets changed. These kinds of optimizations can improve page responsiveness by doing potentially expensive work before it's needed.
To apply it, you only need to indicate what element parameters will change
Important: the will-change property is not for frequent use but rather as a last resort to try and resolve existing performance issues. Don't use it "just in case". The thing is, the default browser itself should normally perform optimization. If it doesn't cope, then you can use will-change. Otherwise, if you use it many times on one page, the browser will not understand what to do first, since there'll be a lot of things to optimize at once.
The stagger parameter starts your animations at the specified time interval. Even the smallest playback delay greatly affects the animation, making it slow and twitchy.
Usage example: gsap.to(".item", {opacity:0, stagger: 0.01}); instead of gsap.to(".item", {opacity:0});.
For example, let's create 1000 elements and try to animate them simultaneously
In the first example, the blocks don't fall smoothly because those 1000 objects are simultaneously animated at once.
When you animate the left/top properties, it triggers the CSS layout recalculation which takes up quite a lot of resources, since it happens in the main thread of the HTML page. While the X and Y transformation uses the GPU and does not recalculate the layout.
For example, instead of gsap.to ("# item", {left: "150px", top: "150px", duration: 3,}); it's better to use gsap.to ("# item", {x: "150px", y: "150px", duration: 3,}).
We recommend not to use fromTo() often to not force the processor to make additional calculations of the initial state of the animation. Better set the initial/final state of the element in HTML/CSS, and use the GSAP library to set the final/initial state transformation.
In the first example, we use the fromTo() method and set the initial and final state of gsap.fromTo (". Box", {opacity: 0}, {opacity: 1, duration: 2}) animation in GSAP
In the second example, we set only the final state of the animation using gsap.to (".box", {opacity: 1, duration: 2}), and the initial one is specified in the CSS class .box opacity:0
Calling animation.kill() immediately stops the animation, removes it from the timeline, and places it in the garbage collection, unloading the processor.
Tip: don't delete animations that you are going to use in the future. Use pause() for those.
It's best to use scaleX/scaleY for resizing where possible. As with the left/top case, when you animate the width/height properties it recalculates the layout, while scaleX and scaleY transformation uses the GPU and doesn't trigger the layout recalculations.
For example, if you need to hover an element, instead of changing the width/height , use scaleX/scaleY
They are too resource-intensive for optimized animations.
SVGs are good for most animations because of the image quality, but if you have a lot of SVG images at once they can have a significant impact on the performance of your animations.
There's no exact number though. It depends not only on the quantity but also on the weight of each piece. A lot of 16×16 px images don't affect the performance as much as a single 800×800 px complex one could.
By animating the CSS property, you resize the element, which entails recalculating the Layout, redrawing the Paint, and composing the Composite. You can learn more about CSS properties on CSS Triggers website.
gsap.ticker.lagSmoothing(1000, 16); lets you avoid animation lags when the CPU starts to freeze.
The first parameter is the threshold (in milliseconds). When the lag becomes greater than this threshold, the engine starts the internal delay clock. As a result, there are no lags at the beginning of the animation.
In video game development, you may have come across a trick of limiting frames per second (FPS). Thus, the animation runs smoothly. Try doing it by adding gsap.ticker.fps(30).
When animating, this plugin allows you to transform the initial state of the first SVG picture into the final state of the second SVG picture. Note that fine-tuned transformation of the initial coordinates into the final coordinates requires a lot of calculations, so here are some tips to help you simplify the calculations: