Anhand eines ausführlichen Artikels auf Dev.Opera bietet die Frontend-Entwicklerin Sara Soueidan einen guten Überblick über die neue CSS-Property will-change. Normalerweise werden CSS-Animationen durch die eher langsame Software Rendering Engine des Browsers gerendert. Mithilfe von will-change können die Animationen deutlich beschleunigt werden, indem man die standardmäßig zumeist völlig ungenutzte GPU zur Hardwarebeschleunigung heranzieht. Da die GPU naturgemäß speziell dafür designt ist, komplexe mathematische und geometrische Berechnungen durchzuführen, kann dies beim Rendering von Grafiken zu deutlich spürbaren Performanceverbesserungen führen.

In einer Zeit vor will-change …

Mithilfe des translateZ() bzw. translate3d()-Hack war es zwar auch schon in der Vergangenheit möglich, den Browser zur Ansteuerung der GPU zu zwingen, was allerdings weder besonders elegant noch unproblematisch ist. So wird bei der Hardwarebeschleunigung einer Operation ein sogenannter Compositor Layer geschaffen; da dieser Vorgang jedoch Speicher im System-RAM und der GPU in Anspruch nimmt, kann dies im Hinblick auf die Performance zu ungewollten Flaschenhälsen führen.

…und heute

Abhilfe schafft nun will-change. Dank dieser Eigenschaft ist der Layer-Hack nicht mehr notwending – stattdessen kann man dem Browser mit ihrer Hilfe vorzeitig mitteilen, welche Änderungen an welchen Elementen vorgenommen werden sollen. Somit kann der Browser ebenfalls vorzeitig optimieren, wie er mit dem Element umgehen wird; so kann er beispielsweise eine Animation vorbereiten, bevor diese tatsächlich abgespielt wird. Die Responsivität einer Seite kann somit deutlich verbessert, bzw. negative Auswirkungen einer Operation auf die Responsivität vermieden werden. Bislang wird will-change jedoch leider nur von den Browsern Chrome Canary 36+, Opera Developer 23+ und Firefox Nightly unterstützt.

Do’s und Dont’s beim Einsatz von will-change

Wie alle Performance-Kniffe muss auch will-change sorgsam eingesetzt werden, um unerwünschte Nebeneffekte zu minimieren:

Nicht zu viele Änderungen an zu vielen Properties oder Elementen vornehmen Man sollte der Versuchung widerstehen, dem Browser alle möglichen Änderungen der Properties bei allen Elementen anzuzeigen. Denn dadurch werden im Zweifelsfall zu viele Ressourcen gebunden; Performanceeinbrüche oder gar ein Crash der Seite sind die Folge.

Dem Browser genug Zeit lassen Wie der Name schon sagt: will-change zeigt dem Browser an, dass eine Änderung nicht zur Zeit stattfindet, sondern erst noch stattfinden wird. Deshalb ergibt es wenig Sinn, will-change auf ein Element anzuwenden, dass sich sofort danach sowieso ändert. Im Gegenteil: In diesem Fall würden sogar mehr Ressourcen verbraucht, also ohne den Einsatz von will-change! Als Beispiel für einen sinnvollen Einsatz sind interaktive, anklickbare Elemente einer Webseite zu nennen. Hier kann will-change dazu verwendet werden, dem Browser eine mögliche Änderung bereits dann anzuzeigen, sobald der Mauszeiger über das Element gefahren wird. Diese kurze Pause (ca. 200ms) zwischen „Mauszeiger zeigt auf das Element“ und „Element wird angeklickt“ genügt dem Browser für die Optimierung.

will-change nach den Änderungen wieder entfernen Normalerweise kehren Browser nach einer Optimierung automatisch in den ressourcenschonenden Normalzustand zurück. will-change überschreibt dieses Verhalten jedoch und behält die Optimierungen deutlich länger bei, als der Browser dies von sich aus tun würde – was im Zweifelsfall unnötige Ressourcen frisst. Desalb: will-change immer entfernen, wenn das Element geändert wurde!

Sparsamer Einsatz in Style Sheets Auch in Style Sheets kann will-change zum Einsatz kommen – wenn auch sparsam. Ein gutes Beispiel sind Elemente, die vom User immer wieder benutzt werden und deshalb möglichst schnell und präzise reagieren sollen, so z.B. der Sidebar.

Property Values

Ingesamt stehen vier Werte zur Auswahl: auto, scroll-position, contents und . Auto bedeutet, dass der Browser keine speziellen Optimierungen druchführen wird, abgesehen von denen, die er normalerweise auch durchführt. Der Value scroll-position zeigt an, dass ein Element bald seine Position verändern wird; das Rendering des Inhalts findet also nicht wie in den meisten Fällen erst im entsprechenden Fenster, sondern schon zuvor statt. Contents wiederum zeigt dem Browser an, dass sich demnächst der Inhalt eines Elements ändern wird; dadurch kann das in diesem Fall unnötige Caching deutlich reduziert bzw. sogar komplett verhindert werden – Auf Nimmerwiedersehen, zugemüllter Cache! Mit dem Value schließlich kann man eine oder mehrere Properties spezifizieren, von denen man erwartet dass sie sich ändern. Dabei werden neben den bereits von zusätzlich die Schlüsselwörter will-change, none, all, auto, scroll-position und contents ausgeschlossen.

Aufmacherbild: