In Richtung eines Messwerts für flüssige Animation

Hier erfahren Sie mehr über das Messen von Animationen, Animation Frames und die allgemeine Seitenflüssigkeit.

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

Bestimmt sind Ihnen schon einmal Seiten begegnet, die beim Scrollen oder bei Animationen ruckeln oder hängen. Wir sagen gerne, dass diese Erfahrungen nicht reibungslos ablaufen. 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 euch über die jüngsten Fortschritte informieren, konkrete Hinweise zu Tools geben und Ideen für zukünftige Messwerte zur Animationseffizienz besprechen. Wie immer freuen wir uns über Feedback.

In diesem Beitrag werden drei Hauptthemen behandelt:

• Kurzer Überblick über Animationen und ‑frames
• Unsere aktuellen Überlegungen zur Messung der allgemeinen flüssigen Darstellung von Animationen.
• Hier einige praktische Vorschläge für die Nutzung von Lab-Tools.

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. Wir alle haben wahrscheinlich schon einmal mit einer Benutzeroberfläche interagiert, die zu viele „hilfreiche“ Übergangseffekte enthält, die die Nutzung erschweren, wenn sie nicht richtig funktionieren. Einige Nutzer bevorzugen daher möglicherweise weniger Bewegung. Diese Nutzerpräferenz sollten Sie berücksichtigen.

Hinweis : Weitere Informationen zu Animationen, einschließlich Leistungsstarke Animationen erstellen und Animationen mithilfe von Entwicklertools prüfen

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. Sie funktionieren jedoch alle im Grunde auf eine der folgenden Arten:

• 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 Renderingleistung.

Es kann zwar praktisch sein, Layouteigenschaften zu animieren, aber das hat auch Nachteile, auch wenn diese nicht sofort ersichtlich 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. Das allein ist jedoch keine Garantie für flüssige Animationen, da selbst effiziente Webanimationen Leistungseinschränkungen 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 Display 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 bieten höhere Bildwiederholraten (90–120 Hz werden immer häufiger). Oft können diese Displays die Bildwiederholraten bei Bedarf aktiv anpassen oder sogar vollständig variable Bildraten bieten.

Das Ziel jeder Anwendung, z. B. 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. Das ist nicht unbedingt wahrnehmbar, insbesondere bei statischen oder dokumentähnlichen Inhalten, die vor allem 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
• Design-Antimuster verwenden, die schnelle Rendering-Optimierungen deaktivieren
• Zu viel JS-Arbeit im Hauptthread, was zu langen Aufgaben führt, die visuelle Aktualisierungen 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 Paint-Phase der Rendering-Pipeline zu tun. Wenn Ihre Callback-Funktion nicht zum erwarteten Zeitpunkt aufgerufen wird, bedeutet das, dass eine Paint-Aktion nicht ausgeführt wurde und ein oder mehrere Frames übersprungen wurden. Wenn Sie abfragen und zählen, wie oft rAF aufgerufen wird, können Sie eine Art „Frames pro Sekunde“-Messwert (FPS) berechnen.

Warnung : Der folgende Code ist ein Anti-Muster und wird dringend abgelehnt.

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()-Polling 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-Abfrage schnell ist, kann sie verhindern, dass requestIdleCallback() bei kontinuierlicher Nutzung lange Inaktivitätsblöcke (Blöcke, die einen einzelnen Frame überschreiten) planen kann.
• Außerdem verhindert das Fehlen langer Inaktivitätsblöcke, dass der Browser andere lang laufende Aufgaben plant, z. B. eine längere Garbage Collection und andere Hintergrund- oder spekulative Aufgaben.
• Wenn die Polling-Funktion aktiviert und deaktiviert wird, werden Fälle, in denen das Frame-Budget überschritten wurde, nicht erfasst.
• 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 intensiv 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 verhindern, dass die Seite bestimmte visuelle Aktualisierungen vornehmen kann. Oben links sehen Sie einen entsprechenden Rückgang von requestAnimationFrame() gemeldeten FPS auf 0.

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 hat einen Frame-Drop auf 0 angezeigt, aber visuell konnte ein Nutzer keinen Unterschied feststellen.

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

Hinweis : Es gibt viele Gründe, warum lange Aufgaben schlecht sind. Diese werden mit speziellen Leistungs-APIs erfasst, z. B. der Long Tasks API oder der Event Timing API. Es gibt jedoch auch Funktionen wie isInputPending(), bei denen lange Aufgaben während der Inaktivität ganz bewusst hinzugefügt werden können und sogar von Vorteil sind.

Animationsframes: Wichtige Updates

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

Wann sind also Animationen und ‑frames wichtig? Hier sind einige Kriterien, die wir uns überlegen und zu denen wir gerne Feedback erhalten würden:

• Aktualisierungen des Haupt- und des Compositor-Threads
• Fehlende Updates für die Malfunktion
• Animationen erkennen
• Qualität versus Quantität

Aktualisierungen des Haupt- und des Compositor-Threads

Aktualisierungen von Animationsframes sind nicht boolesche Werte. Frames können nicht nur vollständig entfernt oder vollständig dargestellt werden. Es gibt viele Gründe, warum ein Animation frame nur teilweise angezeigt wird. Mit anderen Worten: Es kann gleichzeitig veraltete Inhalte und neue visuelle Updates enthalten.

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 dafür, dass deklarative Animationen zum Animieren von zusammengesetzten Eigenschaften empfohlen werden, ist, dass eine Animation so vollständig vom Compose-Thread gesteuert werden kann, auch wenn der Hauptthread ausgelastet ist. Mit diesen Arten von Animationen können visuelle Updates weiterhin effizient und parallel erstellt werden.

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 Malfunktion

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, können Browser beim Rendern visueller Updates beim schnellen Scrollen ins Hintertreffen geraten. Das liegt daran, dass die Pixeldarstellungen von Inhalten außerhalb des sichtbaren Darstellungsbereichs möglicherweise verworfen werden, um GPU-Speicher 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 wirklich überlastet ist, kann der Browser (oder die Plattform) sogar die Rate drosseln, mit der visuelle Aktualisierungen versucht werden, und so die effektiven Frameraten verringern. Technisch gesehen kann dadurch die Anzahl der fehlenden Frame-Updates reduziert werden, optisch wird jedoch weiterhin ein niedrigerer Frame-Durchsatz angezeigt.

Nicht alle Arten von niedrigem Frame-Durchsatz sind jedoch 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 dadurch der Akku geschont werden.

Wann spielt der Frame-Durchsatz also 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 eine visuelle Aktualisierung oder Animation auslöst. 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.

Hinweis : Die Animationerkennung in Tools sowie die spezifischen Animationsumsetzungen in Browsern entwickeln sich ständig weiter und werden verbessert. In Chrome wurden vor Kurzem Hintergrundfarbanimationen aus dem Hauptthread in den Compositor verschoben.

Qualität versus Quantität

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

Beispielsweise kann beim Ansehen eines Videos eine stabile Bildrate von 60 fps angezeigt werden. Technisch gesehen ist das Bild flüssig, aber das Video selbst hat möglicherweise eine niedrige Bitrate oder es gibt Probleme mit der Netzwerkpufferung. Dies wird nicht direkt von den Messwerten für die Animationseffizienz erfasst, kann aber für Nutzer dennoch irritierend sein.

Oder ein Spiel, das <canvas> nutzt (möglicherweise sogar mit Techniken wie Offscreen-Canvas, um eine stabile Framerate zu gewährleisten), kann technisch gesehen in Bezug auf die Animationsframes perfekt flüssig laufen, während es nicht gelingt, hochwertige Spiel-Assets in die Szene zu laden 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.

Status 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:

Kein Update gewünscht	Inaktive Zeit, Wiederholung des vorherigen Frames.
Vollständig präsentiert	Die Aktualisierung des Hauptthreads wurde entweder innerhalb des Termins vorgenommen oder es war keine Aktualisierung des Hauptthreads gewünscht.
Teilweise eingereicht	Nur für den Compositor. Die verzögerte Aktualisierung des Hauptthreads hatte keine optischen Auswirkungen.
Teilweise eingereicht	Nur für den Compositor. Der Hauptthread wurde visuell aktualisiert, aber diese Aktualisierung enthielt keine Animation, die sich auf die Laufruhe auswirkt.
Teilweise eingereicht	Nur für den Compositor. Der Hauptthread hat eine visuelle Aktualisierung erhalten, die sich auf die Bildflüssigkeit auswirkt, aber ein zuvor veralteter Frame wurde empfangen und stattdessen verwendet.
Teilweise eingereicht	Nur für den Compositor, ohne das gewünschte Hauptupdate. Das Compositor-Update enthält eine Animation, die sich auf die Laufruhe auswirkt.
Teilweise eingereicht	Nur für den Compositor, aber das Compositor-Update enthält keine Animation, die sich auf die Laufruhe auswirkt.
Ausgelassener Frame	Keine Aktualisierung. Es war kein Update für den Compositor erforderlich und die Hauptversion wurde verschoben.
Ausgelassener Frame	Ein Update des Renderers war erforderlich, wurde aber verschoben.
Veralteter Frame	Es wurde ein Update benötigt, das vom Renderer erstellt wurde, aber die GPU hat es trotzdem nicht vor Ablauf der vsync-Frist präsentiert.

Es ist möglich, diese Status in eine Art Bewertung umzuwandeln. Dieser Wert kann als Wahrscheinlichkeit interpretiert werden, dass der Fehler vom Nutzer wahrgenommen wird. Ein einzelner Frame, der nicht gesendet wurde, ist möglicherweise nicht sehr auffällig, aber eine Reihe von nicht gesendeten Frames, die sich negativ auf die Bildflüssigkeit auswirken, ist es definitiv.

Zusammenfassend: Der Messwert „Prozentsatz der fehlenden Frames“

Manchmal ist es zwar erforderlich, den Zustand jedes Animationsframes genau zu untersuchen, aber es ist auch nützlich, einer User Experience einfach eine schnelle „auf einen Blick“-Bewertung zuzuweisen.

Da Frames möglicherweise nur teilweise dargestellt werden und selbst vollständig übersprungene Frame-Updates die Glättung nicht unbedingt beeinträchtigen, konzentrieren wir uns weniger auf das Zählen von Frames als vielmehr darauf, inwiefern der Browser visuell vollständige Updates zur richtigen Zeit bereitstellen kann.

Das mentale Modell sollte sich von:

1. Bilder pro Sekunde, um
2. Fehlende und wichtige Animationsupdates erkennen, um
3. Prozentualer Rückgang 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
• Schlechtester Fall bei Prozentsatz der fehlenden Frames:Gemessen über gleitende Zeitfenster von 1 Sekunde.
• 95. Perzentil der Prozentzahl der fehlenden Frames:Gemessen über gleitende Zeitfenster von 1 Sekunde.

Diese Bewertungen sind bereits in einigen Chrome-Entwicklertools verfügbar. Bei diesen Messwerten liegt der Schwerpunkt nur auf dem Gesamtdurchsatz der Frames. Wir bewerten aber auch andere Faktoren wie die Frame-Latenz.

Hinweis : Diese Namen sind etwas veraltet. Die Benennung „Prozentsatz ausgelassen“ entspricht nicht mehr dem Konzept „wurde ein Frame ausgelassen“. Wie im vorherigen Abschnitt beschrieben, ist jeder Animationsframe eine komplizierte Anordnung von Bedingungen, die zu einer Gesamtwahrscheinlichkeit führen. Diese Namen werden sich mit der Zeit ändern.

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 unter „Rendering-Einstellungen“ die Option „Frame-Rendering-Statistiken“, um eine Liveansicht der neuen 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 DevTools-Aufzeichnungen von Leistungsprofilen

Im Leistungsbereich der DevTools gibt es schon lange einen Frames-Viewer. Allerdings hatte sich die Funktionsweise von der modernen Rendering-Pipeline etwas entfernt. 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-Analyse

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. Wir halten euch dort auf dem Laufenden.

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 an die Google-Gruppe web-vitals-feedback senden. Geben Sie dazu in der Betreffzeile „[Glättungsmesswerte]“ an. Wir freuen uns auf deine Meinung.