In Richtung eines Messwerts für flüssige Animation

Hier erfahren Sie mehr über das Messen von Animationen, über Animationsframes und über die Flüssigkeit der Seite insgesamt.

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

Bestimmt sind Ihnen schon einmal Seiten begegnet, die beim Scrollen oder bei Animationen ruckeln oder hängen. Uns ist bewusst, dass diese Abläufe nicht reibungslos sind. Um diese Probleme zu beheben, hat das Chrome-Team daran gearbeitet, die Unterstützung für unsere Lab-Tools zur Animationserkennung zu verbessern und die Rendering-Pipeline-Diagnose in Chromium kontinuierlich zu verbessern.

Wir möchten Ihnen einige aktuelle Fortschritte mitteilen, konkrete Informationen zu Tools geben und Ideen für zukünftige Messwerte zur Animationseffizienz besprechen. Wie immer freuen wir uns über dein Feedback.

In diesem Beitrag werden drei Hauptthemen behandelt:

• Kurzer Überblick über Animationen und ‑frames
• Unsere aktuellen Gedanken zur Messung der Gesamtflüssigkeit der Animation.
• Hier sind ein paar praktische Vorschläge, die Sie in den heutigen Lab-Tools anwenden können.

Was sind Animationen?

Mit Animationen werden Inhalte lebendig. Durch bewegte Inhalte, insbesondere als Reaktion auf Nutzerinteraktionen, können Animationen die Nutzung natürlicher, verständlicher und unterhaltsamer gestalten.

Schlechte Animationen oder zu viele Animationen können jedoch die Nutzererfahrung beeinträchtigen und sie nicht gerade unterhaltsam machen. Wahrscheinlich haben wir alle schon einmal mit einer Benutzeroberfläche interagiert, die einfach zu viele hilfreiche Übergangseffekte einsetzte, die bei schlechter Leistung zu wünschen übrig lassen. Einige Nutzer bevorzugen daher möglicherweise weniger Bewegung. Diese Nutzerpräferenz sollten Sie berücksichtigen.

Wie funktionieren Animationen?

Zur Wiederholung: Die Rendering-Pipeline besteht aus mehreren sequenziellen Phasen:

1. Stil: Hier werden die Stile berechnet, die auf die Elemente angewendet werden.
2. Layout: Hiermit werden die Geometrie und die Position jedes Elements generiert.
3. Paint: Hiermit werden die Pixel für jedes Element in Ebenen gefüllt.
4. Composite: Die Ebenen werden auf dem Bildschirm gezeichnet.

Es gibt viele Möglichkeiten, Animationen zu definieren. Im Grunde funktionieren sie alle mithilfe einer der folgenden Methoden:

• Layouteigenschaften anpassen
• Eigenschaften der Farbe anpassen
• Kompositeigenschaften anpassen

Da diese Phasen sequenziell sind, ist es wichtig, Animationen in Bezug auf Eigenschaften zu definieren, die weiter unten in der Pipeline liegen. Je früher die Aktualisierung im Prozess erfolgt, desto höher sind die Kosten und desto unwahrscheinlicher ist es, dass sie reibungslos verläuft. Weitere Informationen finden Sie unter Rendering-Leistung.

Layouteigenschaften können zwar praktisch sein, aber es entstehen Kosten, auch wenn diese Kosten nicht sofort sichtbar sind. Animationen sollten nach Möglichkeit in Bezug auf Änderungen an zusammengesetzten Properties definiert werden.

Deklarative CSS-Animationen definieren oder Web-Animationen verwenden und zusammengesetzte Eigenschaften animieren sind ein guter erster Schritt zu flüssigen und effizienten Animationen. Dennoch garantiert dies allein die flüssige Wiedergabe nicht, da selbst effiziente Webanimationen Leistungsgrenzen haben. Deshalb ist es immer wichtig, zu messen.

Was sind Animationsframes?

Es kann einige Zeit dauern, bis Änderungen an der visuellen Darstellung einer Seite sichtbar werden. Eine visuelle Änderung führt zu einem neuen Animationsframe, der schließlich auf dem Bildschirm des Nutzers gerendert wird.

Die Anzeigen werden in einem bestimmten Intervall aktualisiert, sodass visuelle Updates in einem Batch ausgeführt werden. Viele Displays werden in einem festen Intervall aktualisiert, z. B. 60 Mal pro Sekunde (60 Hz). Einige modernere Displays können höhere Aktualisierungsraten bieten (90–120 Hz sind üblich). Oft können diese Displays die Bildwiederholraten bei Bedarf aktiv anpassen oder sogar vollständig variable Bildraten bieten.

Das Ziel jeder Anwendung wie eines Spiels oder eines Browsers besteht darin, alle diese Batch-visuellen Updates zu verarbeiten und jedes Mal innerhalb des Zeitlimits einen visuell vollständigen Animationsframe zu erstellen. Dieses Ziel unterscheidet sich grundlegend von anderen wichtigen Browseraufgaben wie dem schnellen Laden von Inhalten aus dem Netzwerk oder der effizienten Ausführung von JavaScript-Aufgaben.

Irgendwann kann es zu schwierig werden, alle visuellen Änderungen innerhalb des vom Display zugewiesenen Termins abzuschließen. In diesem Fall setzt der Browser einen Frame. Das Display wird nicht schwarz, sondern wiederholt sich nur. Sie sehen die visuelle Aktualisierung etwas länger – denselben Animationsframe, der bei der vorherigen Frame-Chance präsentiert wurde.

Das kommt tatsächlich häufig vor. Sie ist nicht unbedingt wahrnehmbar, insbesondere bei statischen oder dokumentenähnlichen Inhalten, die insbesondere auf der Webplattform üblich sind. Ausgelassene Frames werden nur bei wichtigen visuellen Aktualisierungen wie Animationen sichtbar, für die ein kontinuierlicher Stream von Animationen erforderlich ist, um eine flüssige Bewegung zu ermöglichen.

Was wirkt sich auf Animationsframes aus?

Webentwickler können die Fähigkeit eines Browsers, visuelle Änderungen schnell und effizient zu rendern und zu präsentieren, erheblich beeinflussen.

Beispiele:

• Die Verwendung von Inhalten, die zu groß oder zu ressourcenintensiv sind, um sie auf dem Zielgerät schnell zu decodieren.
• Verwendung zu vieler Ebenen, die zu viel GPU-Arbeitsspeicher erfordern.
• Definieren von übermäßig komplexen CSS-Stilen oder Web-Animationen
• Verwendung von Anti-Patterns für das Design, die schnelle Rendering-Optimierungen deaktivieren.
• Im Hauptthread wird zu viel JS ausgeführt, was zu langen Aufgaben führt, die visuelle Updates blockieren.

Aber woher wissen Sie, wann ein Animationsframe die Frist nicht eingehalten hat und zu einem Frame-Drop geführt hat?

Eine mögliche Methode ist das Polling mit requestAnimationFrame(). Diese Methode hat jedoch mehrere Nachteile. requestAnimationFrame() oder „rAF“ teilt dem Browser mit, dass Sie eine Animation ausführen möchten, und bittet um die Möglichkeit, dies vor der nächsten Malphase der Rendering-Pipeline zu tun. Wenn die Callback-Funktion nicht zum erwarteten Zeitpunkt aufgerufen wird, wurde eine Paint nicht ausgeführt und mindestens ein Frame wurde übersprungen. Wenn Sie abfragen und zählen, wie oft rAF aufgerufen wird, können Sie eine Art „Frames pro Sekunde“-Messwert (FPS) berechnen.

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

Die Verwendung von requestAnimationFrame()-Umfragen ist aus mehreren Gründen keine gute Idee:

• Für jedes Script muss eine eigene Abfrageschleife eingerichtet werden.
• Sie kann den kritischen Pfad blockieren.
• Selbst wenn die rAF-Abrufe schnell sind, kann sie verhindern, dass requestIdleCallback() lange inaktive Blöcke einplanen kann, wenn sie kontinuierlich verwendet werden (Blöcke, die einen einzelnen Frame überschreiten).
• Ebenso verhindert das Fehlen langer Inaktivitätsblöcke den Browser, andere Aufgaben mit langer Ausführungszeit zu planen (z. B. eine längere automatische Speicherbereinigung und andere Hintergrund- oder spekulative Arbeiten).
• Wenn das Polling aktiviert und deaktiviert ist, werden Sie nicht berücksichtigt, wenn das Frame-Budget überschritten wurde.
• Beim Polling werden in Fällen, in denen der Browser eine variable Aktualisierungshäufigkeit verwendet (z. B. aufgrund des Ein-/Aus-Status oder des Sichtbarkeitsstatus), falsch positive Ergebnisse gemeldet.
• Und vor allem werden nicht alle Arten von Animationsaktualisierungen erfasst.

Zu viel Arbeit im Hauptthread kann sich auf die Sichtbarkeit von Animationsframes auswirken. Im Jank-Beispiel sehen Sie, wie eine RAF-gestützte Animation zu Frame-Ausfällen, weniger RAF-Callbacks und niedrigeren FPS führt, wenn der Hauptthread zu viel Arbeit hat (z. B. beim Layout).

Wenn der Hauptthread überlastet ist, beginnen visuelle Aktualisierungen zu stottern. Das ist nicht gut.

Viele Analysetools haben sich hauptsächlich darauf konzentriert, dass der Haupt-Thread zeitnah Ergebnisse liefert und die Animationsframes reibungslos laufen. Aber das ist noch nicht alles! Dazu ein Beispiel:

Im Video oben ist eine Seite zu sehen, auf der regelmäßig lange Aufgaben in den Haupt-Thread eingeschleust werden. Diese langen Aufgaben beeinträchtigen die Möglichkeit der Seite, bestimmte Arten von visuellen Aktualisierungen bereitzustellen. Außerdem können Sie links oben einen entsprechenden Rückgang von requestAnimationFrame() fps auf 0 sehen.

Trotz dieser langen Aufgaben scrollt die Seite weiterhin reibungslos. Das liegt daran, dass in modernen Browsern das Scrollen oft gethreadet ist und vollständig vom Compositor gesteuert wird.

Dieses Beispiel enthält gleichzeitig viele verlorene Frames im Haupt-Thread, aber dennoch viele erfolgreich gestreamte Frames des Scrollens im Compositor-Thread. Sobald die lange Aufgabe abgeschlossen ist, führt die Aktualisierung der Malerei im Hauptthread ohnehin zu keiner visuellen Änderung. Die rAF-Abfrage ergab einen Frame-Drop auf 0, aber visuell konnte ein Nutzer keinen Unterschied feststellen.

Bei Frames für Animationen ist das nicht ganz so einfach.

Animationsframes: Wichtige Updates

Das obige Beispiel zeigt, dass es mehr zu der Geschichte gibt als nur requestAnimationFrame().

Wann sind Aktualisierungen von Animationen und Animationsframes wichtig? Hier sind einige Kriterien, die wir uns überlegen und zu denen wir gerne Feedback erhalten würden:

• Updates des Hauptthreads und des zusammengesetzten Threads
• Fehlende Updates für die Malanwendung
• Animationen erkennen
• Qualität versus Quantität

Updates des Hauptthreads und des zusammengesetzten Threads

Bei Updates des Animationsframes handelt es sich nicht um einen booleschen Wert. Frames können nicht nur vollständig entfernt oder vollständig dargestellt werden. Es gibt viele Gründe, warum ein Animationsframe teilweise präsentiert wird. Das heißt, es kann gleichzeitig einige veraltete Inhalte enthalten und gleichzeitig einige neue visuelle Aktualisierungen angezeigt werden.

Das häufigste Beispiel hierfür ist, wenn der Browser innerhalb des Frame-Deadlines keine neue Aktualisierung des Hauptthreads vornehmen kann, aber eine neue Aktualisierung des Compositor-Threads hat (z. B. das Beispiel für das Thread-Scrolling oben).

Ein wichtiger Grund, aus dem die Verwendung deklarativer Animationen zum Animieren zusammengesetzter Eigenschaften empfohlen wird, besteht darin, dass dadurch eine Animation vollständig vom zusammengesetzten Thread gesteuert werden kann, selbst wenn der Hauptthread ausgelastet ist. Diese Arten von Animationen können weiterhin effizient und parallel visuelle Aktualisierungen erzeugen.

Andererseits kann es vorkommen, dass eine Aktualisierung des Hauptthreads erst nach mehreren verpassten Frame-Terminen für die Präsentation verfügbar wird. Der Browser hat ein neues Update, es ist aber möglicherweise nicht das neueste.

Im Allgemeinen betrachten wir Frames, die einige neue visuelle Änderungen enthalten, aber nicht alle, als einen teilweisen Frame. Teilweise angezeigte Frames sind relativ häufig. Idealerweise sollten Teilaktualisierungen zumindest die wichtigsten visuellen Aktualisierungen wie Animationen umfassen. Das ist aber nur möglich, wenn Animationen vom Compositor-Thread gesteuert werden.

Fehlende Updates für die Farbgebung

Eine weitere Art der teilweisen Aktualisierung tritt auf, wenn Medien wie Bilder nicht rechtzeitig für die Frame-Darstellung decodiert und gerastert wurden.

Selbst wenn eine Seite vollkommen statisch ist, kann es vorkommen, dass Browser beim schnellen Scrollen hinter dem Rendering von visuellen Updates zurückbleiben. Das liegt daran, dass die Pixelwiedergaben von Inhalten jenseits des sichtbaren Darstellungsbereichs verworfen werden können, um GPU-Arbeitsspeicher zu sparen. Das Rendern von Pixeln dauert seine Zeit. Nach einem großen Scrollen, z. B. durch Wischen, kann es länger als ein einzelner Frame dauern, bis alles gerendert ist. Dies wird allgemein als Karomuster bezeichnet.

Bei jeder Frame-Rendering-Möglichkeit lässt sich nachvollziehen, wie viel von den neuesten visuellen Updates tatsächlich auf dem Bildschirm zu sehen ist. Die Fähigkeit, dies über viele Frames (oder Zeit) hinweg zu tun, wird allgemein als Frame-Durchsatz bezeichnet.

Wenn die GPU tatsächlich nicht reagiert, kann der Browser (oder die Plattform) sogar die Rate, mit der visuelle Updates durchgeführt werden, drosseln, wodurch die effektiven Frame-Raten verringert werden. Technisch gesehen kann dies zwar die Anzahl der ignorierten Frame-Updates reduzieren, aber optisch trotzdem ein niedrigerer Framedurchsatz angezeigt werden.

Allerdings sind nicht alle Arten von niedrigem Framedurchsatz schlecht. Wenn die Seite größtenteils inaktiv ist und keine aktiven Animationen vorhanden sind, ist eine niedrige Framerate genauso visuell ansprechend wie eine hohe Framerate. Außerdem kann so der Akku geschont werden.

Wann spielt der Frame-Durchsatz eine Rolle?

Animationen erkennen

Ein hoher Frame-Durchsatz ist besonders wichtig, wenn wichtige Animationen zu sehen sind. Verschiedene Animationstypen hängen von visuellen Aktualisierungen eines bestimmten Threads (Haupt-, Compositor- oder Worker-Thread) ab. Die visuelle Aktualisierung hängt also davon ab, ob dieser Thread die Aktualisierung innerhalb des Zeitlimits bereitstellt. Wir sagen, dass ein bestimmter Thread die Laufruhe beeinträchtigt, wenn es eine aktive Animation gibt, die von dieser Threadaktualisierung abhängt.

Einige Arten von Animationen lassen sich leichter definieren und erkennen als andere. Deklarative Animationen oder Animationen, die vom Nutzer eingegeben werden, lassen sich einfacher definieren als JavaScript-gestützte Animationen, die als regelmäßige Aktualisierungen von animierbaren Stileigenschaften implementiert werden.

Auch mit requestAnimationFrame() können Sie nicht immer davon ausgehen, dass jeder RAF-Aufruf unbedingt zu einer visuellen Aktualisierung oder Animation führt. Wenn Sie beispielsweise die rAF-Abfrage nur zum Erfassen der Framerate verwenden (wie oben gezeigt), sollte dies die Messungen der Bildreinheit nicht beeinflussen, da es keine visuelle Aktualisierung gibt.

Qualität versus Quantität

Schließlich ist die Erkennung von Animationen und Animationskadern nur ein Teil der Geschichte, da nur die Anzahl der Animationen erfasst wird, nicht die Qualität.

Beispielsweise wird beim Ansehen eines Videos eine stabile Bildrate von 60 fps angezeigt. Technisch gesehen ist das einwandfrei, aber das Video selbst kann eine niedrige Bitrate oder Probleme mit der Zwischenspeicherung im Netzwerk haben. Dies wird nicht direkt durch die Messwerte für die Flüssigkeitserkennung von Animationen erfasst, kann aber für Nutzer verstörend sein.

Ein Spiel, das <canvas> nutzt (und vielleicht sogar Methoden wie Offscreen-Canvas nutzt, um eine konstante Framerate zu gewährleisten) funktioniert möglicherweise technisch reibungslos in Bezug auf Animationsframes, ohne dass qualitativ hochwertige Spiel-Assets in die Szene geladen werden oder Rendering-Artefakte auftreten.

Natürlich kann es auch sein, dass eine Website einfach nur wirklich schlechte Animationen hat 🙂

Ich denke, sie waren für ihre Zeit ziemlich cool.

Zustände eines einzelnen Animationsframes

Da Frames teilweise dargestellt werden können oder Frame-Ausfälle auf eine Weise auftreten können, die sich nicht auf die Laufruhe auswirkt, haben wir damit begonnen, jedem Frame einen Wert für Vollständigkeit oder Laufruhe zuzuweisen.

Hier ist das Spektrum der Möglichkeiten, wie wir den Status eines einzelnen Animationsframes interpretieren, sortiert vom Best- bis zum Worst-Case-Szenario:

Es ist möglich, diese Status in eine Art Bewertung umzuwandeln. Und vielleicht eine Möglichkeit, diese Punktzahl zu interpretieren, besteht darin, sie als Wahrscheinlichkeit zu betrachten, dass sie für den Nutzer beobachtbar ist. Ein einzelner Frame-Drop ist möglicherweise nicht sehr auffällig, aber eine Reihe von Frame-Drops, die sich negativ auf die Bildflüssigkeit auswirken, ist es definitiv.

Zusammenfassend: Der Messwert „Prozentsatz der fehlenden Frames“

Manchmal kann es erforderlich sein, den Zustand jedes Animations-Frames genau zu analysieren. Es ist aber auch hilfreich, nur einen schnellen Überblick über die User Experience zuzuweisen.

Da Frames teilweise dargestellt werden und auch vollständig übersprungene Frame-Aktualisierungen die Flüssigkeit nicht beeinträchtigen, möchten wir uns weniger auf das Zählen der Frames konzentrieren und mehr auf das Ausmaß, in dem der Browser im entscheidenden Moment keine visuell vollständigen Updates bereitstellen kann.

Das mentale Modell sollte sich von:

1. Bilder pro Sekunde, um
2. Fehlende und wichtige Animationsupdates erkennen, um
3. Abgebrochener Prozentsatz in einem bestimmten Zeitraum.

Wichtig ist: Der Anteil der Zeit, die auf wichtige Updates gewartet wird. Wir sind der Meinung, dass dies der natürlichen Art entspricht, wie Nutzer die flüssige Darstellung von Webinhalten in der Praxis wahrnehmen. Bisher haben wir die folgenden Messwerte verwendet:

• Durchschnittlicher Prozentsatz der Ausfälle: für alle nicht inaktiven Animationsframes in der gesamten Zeitleiste
• Worst Case (% der abgebrochenen Frames in Prozent):gemessen über gleitende Fenster von einer Sekunde hinweg.
• 95. Perzentil des Prozentsatzes der verworfenen Frames:gemessen über 1 Sekunde gleitende Zeitfenster.

Sie finden diese Punktzahlen bereits in einigen Chrome-Entwicklertools. Bei diesen Messwerten liegt der Schwerpunkt nur auf dem Gesamtdurchsatz der Frames. Wir bewerten aber auch andere Faktoren wie die Frame-Latenz.

Probieren Sie es selbst in den Entwicklertools aus.

HUD für die Leistung

Chromium hat ein praktisches HUD für die Leistung, das sich hinter einem Flag (chrome://flags/#show-performance-metrics-hud) verbirgt. Dort finden Sie Live-Werte für Dinge wie Core Web Vitals sowie einige experimentelle Definitionen für die Animationsflüssigkeit, die auf dem prozentualen Anteil der fehlenden Frames im Zeitverlauf basieren.

Frame-Rendering-Statistiken

Aktivieren Sie in den DevTools über die Rendering-Einstellungen die Option „Frame-Rendering-Statistiken“, um eine Liveansicht neuer Animationsframes zu sehen. Diese sind farblich codiert, um teilweise Aktualisierungen von vollständig gelöschten Frame-Aktualisierungen zu unterscheiden. Die angegebene Bildrate gilt nur für vollständig dargestellte Frames.

Frame-Viewer in Aufzeichnungen von Leistungsprofilen in den Entwicklertools

Im Leistungsbereich der DevTools gibt es schon lange einen Frames-Viewer. Sie war jedoch etwas nicht mehr mit der Funktionsweise der modernen Rendering-Pipeline synchron. Es gab in letzter Zeit viele Verbesserungen, auch in der neuesten Version von Chrome Canary. Wir sind der Meinung, dass sich damit die Fehlerbehebung bei Animationen erheblich vereinfachen lässt.

Heute sind die Frames im Frame-Viewer besser an den vsync-Grenzen ausgerichtet und werden je nach Status farblich gekennzeichnet. Die oben beschriebenen Nuancen werden noch nicht vollständig visualisiert. Wir planen jedoch, in naher Zukunft weitere hinzuzufügen.

Chrome-Tracing

Mit Chrome Tracing, dem Tool der Wahl für detaillierte Analysen, können Sie über die neue Perfetto-Benutzeroberfläche (oder about:tracing) einen „Webcontent-Rendering“-Trace aufzeichnen und die Grafikpipeline von Chrome genauer untersuchen. Das kann eine entmutigende Aufgabe sein, aber es gibt einige Dinge, die vor Kurzem in Chromium hinzugefügt wurden, um die Arbeit zu erleichtern. Eine Übersicht über die verfügbaren Funktionen findest du im Dokument Leben eines Frames.

Anhand von Trace-Ereignissen können Sie Folgendes genau bestimmen:

• Welche Animationen ausgeführt werden (mit Ereignissen vom Typ TrackerValidation)
• Die genaue Zeitachse der Animationsframes abrufen (mit Ereignissen vom Typ PipelineReporter)
• Wenn die Animation ruckelt, ermitteln Sie anhand der Ereignisaufschlüsselungen in den PipelineReporter-Ereignissen genau, was die Ausführung der Animation verhindert.
• Bei eingabebasierten Animationen können Sie mithilfe von Ereignissen vom Typ EventLatency ermitteln, wie lange es dauert, bis eine visuelle Aktualisierung erfolgt.

Nächste Schritte

Die Web Vitals-Initiative soll Messwerte und Anleitungen für eine optimale Nutzererfahrung im Web bieten. Laborbasierte Messwerte wie die Gesamte Blockierzeit (Total Blocking Time, TBT) sind entscheidend, um potenzielle Probleme mit der Interaktivität zu erkennen und zu diagnostizieren. Wir planen, einen ähnlichen LAB-basierten Messwert für die flüssige Wiedergabe von Animationen zu entwickeln.

Wir halten euch auf dem Laufenden, während wir weiter an Ideen für einen umfassenden Messwert arbeiten, der auf Daten einzelner Animationsframes basiert.

In Zukunft möchten wir auch APIs entwickeln, mit denen sich die Animation für echte Nutzer sowohl im Feld als auch im Labor effizient messen lässt. Das gilt auch für Updates.

Feedback

Wir freuen uns über die jüngsten Verbesserungen und Entwicklertools, die in Chrome eingeführt wurden, um die Laufruhe von Animationen zu messen. Probieren Sie diese Tools aus, führen Sie Benchmarks für Ihre Animationen durch und lassen Sie uns wissen, was Sie herausgefunden haben.

Sie können Ihre Kommentare mit „[Smoothness Metrics]“ in der Betreffzeile an die Google-Gruppe web-vitals-feedback senden. Wir freuen uns auf deine Meinung.