[…] die
will-changeEigenschaft landete im August 2015 in den wichtigsten Browsern, und ich habe seitdem Ausschau gehalten, wann ich sie einsetzen kann. Es mag offensichtlich erscheinen, sie auf gängige animierte Eigenschaften wie transform oder opacity anzuwenden, aber der Browser klassifiziert sie bereits als Kompositionseigenschaften, daher sind sie als die wenigen Eigenschaften bekannt, von denen man bereits eine gute Animationsleistung erwarten kann. Also habe ich, um den Rat der großen Entwickler vor mir zu befolgen, Vorsicht walten lassen und auf die richtige Gelegenheit gewartet.
Ich habe vor nicht allzu langer Zeit auch auf ShopTalk darüber nachgedacht. Ich verstehe den Geist hinter will-change. Es ist wie bei responsiven Bildern oder DNS-Prefetching: Man gibt dem Browser zusätzliche Informationen darüber, was man tun wird, und er kann es optimieren, wenn es passiert. Aber bei will-change… *wann*? Gibt es keine einfache, reduzierte Testfall-Demo, die etwas mit schlechter Leistung zeigt, dann will-change angewendet wird und es zu guter Leistung wird?
Nun, Nic hat einen kleinen, direkt nützlichen Fall gefunden, bei dem ein durch Hover transformiertes Pseudo-Element in Safari einen kleinen Farbfleck hinterlässt, der verschwindet, wenn man will-change verwendet. Ich habe es in den neuesten Versionen von Safari getestet und es hat sich als wahr erwiesen. Also gut, ein Anwendungsfall!
Ich würde gerne einen offensichtlicheren, direkteren Anwendungsfall sehen. Ich stelle mir vor, dass der Sweet Spot auf Geräten mit geringerer Leistung liegt (die immer noch über GPUs verfügen), aber neu genug sind, um zu wissen, was will-change ist.
Ich hatte genau dieses Problem mit einigen GSAP-Animationen in Safari 15. Die Animationen hinterließen Artefakte auf dem Bildschirm. will-change hat es behoben.
Das heißt: Liegt der Leistungsgewinn nicht darin, dass Browser mehr Optimierungen für Dinge durchführen können, die sich nicht ändern, indem sie wissen, welche Dinge sich ändern werden? *Schulterzucken*