Then I hovered on the image (before and after applying will-change) and I saw no painting (screen flashing green) occurred in both cases and the layer borders were the same in both cases. That means the browser already optimized that animation.
If will-change was adding any more optimizations, there would have been more layers borders and less painting (in this case no paintings happened in both tests).
You could test it on your end to see if I missed anything.
Side-note:
For browsers that don’t support will-change, but benefit from layer creation, such as older versions of Safari and Mobile Safari, you need to use a 3D transform to force a new layer: transform: translateZ(0);
Although it is a good property it shouldn't be used to promote elements to a new layer unnecessarily.
If you have promoted an element to a new layer, use DevTools to confirm that doing so has given you a performance benefit. Don't promote elements without profiling.
I also agree with you that if the element is going to be animated constantly (for example scroll animations) and there's a performance benefit its much better to use the will-change property in the stylesheets.
Side-note:
If anyone notices any performance benefit when testing this fork, know that will-change optimizations depends on the resources (memory, computing power) available to your browser, meaning it varies in user machines (both desktops, laptops and mobile phones). So me not seeing any optimizations could mean my machine has enough resources for my browser to optimize the animation itself.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I tested your fork;
Paint flashingandLayer borderswill-change) and I saw no painting (screen flashing green) occurred in both cases and the layer borders were the same in both cases. That means the browser already optimized that animation.If
will-changewas adding any more optimizations, there would have been more layers borders and less painting (in this case no paintings happened in both tests).You could test it on your end to see if I missed anything.
Side-note:
For browsers that don’t support
will-change, but benefit from layer creation, such as older versions of Safari and Mobile Safari, you need to use a 3D transform to force a new layer:transform: translateZ(0);More on enabling Layer Borders and enabling realtime Paint Flashing, borders meaning 👉 Chromium's source code and Stackoverflow answer by Paul Irish (note the link to debug.cc in this answer is broken so just check the Chromium's source code I linked)
More resources:
Although it is a good property it shouldn't be used to promote elements to a new layer unnecessarily.
If you have promoted an element to a new layer, use DevTools to confirm that doing so has given you a performance benefit. Don't promote elements without profiling.
I also agree with you that if the element is going to be animated constantly (for example scroll animations) and there's a performance benefit its much better to use the
will-changeproperty in the stylesheets.Side-note:
If anyone notices any performance benefit when testing this fork, know that
will-changeoptimizations depends on the resources (memory, computing power) available to your browser, meaning it varies in user machines (both desktops, laptops and mobile phones). So me not seeing any optimizations could mean my machine has enough resources for my browser to optimize the animation itself.