1

According to Google:

The general rule of thumb is that if the animation might be triggered in the next 200ms [...] then having will-change on animating elements is a good idea. For most cases, then, any element in your app’s current view that you intend to animate should have will-change enabled for whichever properties you plan to change.

So my question is, can will-change be applied via the Web Animations API before any property is actually animated, and will that have the desired effect? Or is that too late in the lifecycle of whatever's going on behind the scenes for will-change to work properly?

It seems like properties modified via this API aren't actually reflected in DevTools as CSS properties, so I can't verify whether this actually even applied will-change at all.

Example of the idea:

this.animation = document.querySelector('#my-element').animate(
  [
    {
      willChange: 'opacity', // will-change applied before any animated property has been changed
      opacity: 'initial',
    },
    {
      willChange: 'opacity',
      opacity: 'initial',
      offset: 0.01, // 1% of the way through the animation
    },
    {
      willChange: 'opacity',
      opacity: 0.5,
      offset: 0.5, // 50% of the way through the animation
    },
    { 
      willChange: 'initial',
      opacity: 'initial'
    },
  ],
  1000
);
Slbox
  • 10,957
  • 15
  • 54
  • 106

2 Answers2

3

Yes, it will have the desired effect.

Animations affect an element's computed style, but many DevTools panels present the element's specified style, hence why you don't see it there.

An alternative approach is to simply add a short delay to the animation. During the delay phase of the animation, the browser is required to apply will-change: opacity (or whatever other properties are being animated). (Spec reference)

That said, there is really no advantage to doing so. The purpose of applying will-change is to let the browser prepare the content for animating (e.g. by re-rasterizing it as separate layers) so that the animation starts without delay. If you simply start the animation as normal, the browser will re-rasterize as necessary and then begin the animation from the start.

The advantage to using will-change is if you know before you need to start the animation which element you are going to animate, you can let the browser doing that preparation ahead of time.

brianskold
  • 809
  • 5
  • 10
  • It's often mentioned that `will-change` shouldn't be left on, even for elements that _will change_. I wonder if it's really a problem to just leave it on for an element whose properties will change quite often? – Slbox Nov 01 '20 at 23:43
  • It's fine to leave it on if you only apply it to a small number of elements. Applying it to all the elements could mean the browser would need to make layers for everything which would drastically increase memory usage. As a result, browsers often have a will-change "budget" after which point they simply ignore any will-change properties. So your best best it to just apply it to a few elements that you expect will be animated next. – brianskold Nov 02 '20 at 02:06
  • That's really interesting regarding browsers having a "budget" for will-change. Would you happen to have a source for that info? – Slbox Nov 02 '20 at 20:05
  • I am the primary author of the Web Animations spec and implementer in Firefox. You can see the "budget" warnings in the Firefox DevTools console if you exceed the budget. You can also see it if you browser the Firefox source code, e.g. https://searchfox.org/mozilla-central/rev/c938c7416c633639a5c8ce4412be586eefb48005/layout/painting/ActiveLayerTracker.cpp#507 Why did you accept the other answer? – brianskold Nov 04 '20 at 23:08
  • I accepted the other answer because I found an answer and answered it. I would have happily changed the accepted answer to yours if you mentioned you're the primary author, waited for a reply about why I accepted the other, and then updated yours to contain that information. But instead you reflexively downvoted my answer, which did answer the question, apparently with a direct quote from you, when yours did not, as soon as I posted it. Why would you neglect to mention you're the author in your original reply? – Slbox Nov 04 '20 at 23:33
-2

It looks like will-change is actually completely unnecessary when using WAAPI (Web Animation API.)

if you have a delay on your animation, you don’t need to worry about using will-change. -- Source

From one of the authors of the spec:

If you have a positive delay, you don’t need will-change since the browser will layerize at the start of the delay and when the animation starts it will be ready to go.

Slbox
  • 10,957
  • 15
  • 54
  • 106
  • That's incorrect. Please see my answer above. I am the primary author of the Web Animations spec you quoted. I added the text that requires browsers to apply will-change to animated content during its delay phase. However, will-change is still useful to allow the browser to layerize its content before you apply the animation. – brianskold Nov 04 '20 at 23:10
  • It's pretty strange you'd insta-downvote a direct quote of yourself. Sorry if I got something wrong, but all I can do is go by what I can find. I've unaccepted my answer now, but I have to say that your approach to showing me that I have it wrong leaves *a lot* to be desired... – Slbox Nov 04 '20 at 23:36
  • Why is this quote wrong? Would this layerization not occur thanks to the use of WAAPI delay? And how could applying it via keyframes possibly perform better than what the browser would apply via using delay? It seems backwards. You're the author so you obviously know better, but if you wouldn't mind explaining a bit, that would go a long way. – Slbox Nov 04 '20 at 23:47
  • The summary is wrong because it's not true that will-change is "completely unnecessary when using the Web Animations API". It's still useful to allow the browser to layerize the content before you apply the animation as my comment mentioned. – brianskold Nov 05 '20 at 08:10
  • Sorry, I have no idea what the significance of a downvote is. I downvoted it because it's wrong and I was trying to point people to the correct answer. Is that not how votes work? – brianskold Nov 05 '20 at 08:11
  • 1
    I looked up downvotes (since I know nothing about these things) and if you're concerned about reputation numbers, apparently I can un-downvote it if you edit the answer. Sorry about that. I really had no idea that was a concern. – brianskold Nov 05 '20 at 08:31
  • 1
    Also, when I refer to will-change still being useful, I'm referring to applying it to the element out-of-band, e.g. via a stylesheet or style attribute, not via keyframes. For a desktop scenario where a button animates on clicking, you could apply will-change on :hover or :focus, for example. – brianskold Nov 05 '20 at 08:32
  • No worries I understand. Stack is a weird place with how downvotes are handled. If you could update your answer to include the quote I included in mine and add the caveats you point out about `will-change` still being useful for animations/transitions/anything triggered from outside of WAAPI I'd be glad to accept your answer. – Slbox Nov 05 '20 at 23:35