Animationen ohne Ruckeln: Bewegung, die Ladezeiten respektiert
Warum manche Animationen ruckeln und andere nicht, und wie Bewegung barrierearm bleibt.
Warum Animationen ruckeln
Eine Animation wirkt flüssig, wenn der Browser 60 Bilder pro Sekunde zeichnet. Für jedes Bild bleiben ihm damit gut 16 Millisekunden, auf Bildschirmen mit 120 Hertz, wie sie viele aktuelle Smartphones und Laptops haben, nur gut 8. In dieser Zeit muss er Skripte ausführen, das Layout berechnen und die Seite zeichnen. Dauert ein Bild länger, fällt es aus, und das Auge nimmt die Lücke als Ruckeln wahr.
Ob eine Animation in dieses Zeitfenster passt, hängt weniger davon ab, wie aufwendig sie aussieht, als davon, welche Arbeit sie dem Browser abverlangt.
transform und opacity
Browser können Verschiebungen, Skalierungen und Transparenz besonders effizient berechnen. Wer stattdessen Breite, Höhe oder Position animiert, zwingt den Browser zu teuren Neuberechnungen.
Der Grund: Ändert sich die Breite eines Elements, muss der Browser prüfen, wie sich alle umliegenden Elemente verschieben, und die Seite neu zeichnen. Eine Verschiebung per transform dagegen übernimmt der Grafikprozessor, ohne dass sich am Layout etwas ändert. Mit den beiden Eigenschaften lässt sich fast jede Bewegung umsetzen: Einblenden, Gleiten, Wachsen und Drehen.
Vorsicht ist bei Effekten wie Unschärfe und großen Schatten geboten. Sie sehen elegant aus, kosten aber bei jedem Bild Rechenzeit, besonders auf großen Flächen und auf Smartphones.
Nur animieren, was sichtbar ist
Animationen sollten erst starten, wenn sie im sichtbaren Bereich sind, und anhalten, wenn der Tab im Hintergrund liegt. Das spart Akku und Rechenleistung.
Das gilt besonders für Endlosschleifen: ein langsam rotierendes Logo, ein bewegter Hintergrund, ein Partikeleffekt. Einzeln wirken sie harmlos, zusammen halten sie den Prozessor dauerhaft beschäftigt, auch wenn niemand hinsieht. Beim Bau dieser Website brauchte der 3D-Hintergrund im Kopfbereich nur rund eine Millisekunde pro Bild. Mehr kostete eine kaum sichtbare, langsam wandernde Textebene: Ohne sie halbierte sich die Rechenzeit, die die Seite im Ruhezustand verbrauchte.
Scrollen hat Vorrang
Nichts fällt so schnell auf wie eine Seite, die beim Scrollen hängt. Animationen, die an die Scrollposition gekoppelt sind, sollten deshalb keine Maße der Seite auslesen, während gescrollt wird, und ihre Berechnungen auf das Nötigste beschränken. Moderne Browser können solche Effekte inzwischen auch ohne JavaScript direkt mit CSS an die Scrollposition binden.
Das Scrollen selbst sollte dabei unangetastet bleiben. Seiten, die die Scrollgeschwindigkeit verändern oder Abschnitte erzwingen, fühlen sich für viele Besucherinnen und Besucher fremd an und machen die Bedienung schwerer.
Erst der Inhalt, dann die Bewegung
Animationen dürfen den Seitenaufbau nicht verzögern. Text und Bilder im sichtbaren Bereich sollten sofort erscheinen, auch wenn die Animationsbibliothek noch lädt. Inhalte, die per Skript erst unsichtbar gemacht und dann eingeblendet werden, verschlechtern sonst den Largest Contentful Paint, eine der Kennzahlen, mit denen Google die Ladezeit bewertet.
Eine zweite Kennzahl betrifft die Reaktionszeit: Interaction to Next Paint misst, wie schnell die Seite nach einem Klick oder Fingertipp sichtbar reagiert. Als gut gelten bis zu 200 Millisekunden. Läuft im Hintergrund gerade eine rechenintensive Animation, muss die Reaktion warten.
Reduzierte Bewegung respektieren
Mit prefers-reduced-motion lässt sich erkennen, wenn Nutzer weniger Bewegung wünschen. Dann werden Animationen reduziert oder durch einfache Überblendungen ersetzt.
Diese Einstellung nutzen nicht nur Menschen, denen starke Bewegung Schwindel oder Übelkeit bereitet, sondern auch alle, die sich beim Lesen nicht ablenken lassen wollen. Für Bewegung, die von selbst startet und länger als fünf Sekunden läuft, verlangen die Richtlinien zur Barrierefreiheit (WCAG) außerdem eine Möglichkeit, sie anzuhalten.
Messen statt vermuten
Ob eine Animation flüssig läuft, zeigt sich auf einem schnellen Entwicklungsrechner selten. Ich teste deshalb auf einem gewöhnlichen Smartphone und messe mit den Entwicklerwerkzeugen des Browsers, welcher Effekt wie viel Rechenzeit kostet. Oft ist es nicht der auffälligste Effekt, der die Seite bremst, sondern ein unscheinbarer, der ständig im Hintergrund läuft.