In Richtung eines Messwerts für flüssige Animation

Hier erfahren Sie mehr über das Messen von Animationen, über Animationsframes und die allgemeine Seitenglättung.

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

Wahrscheinlich sind Seiten beim Scrollen oder bei Animationen „ruckeln“ oder „einfrieren“. Wir geben an, dass diese Abläufe nicht reibungslos sind. Um diese Probleme anzugehen, hat das Chrome-Team daran gearbeitet, mehr Unterstützung für unsere Labortools zur Erkennung von Animationen zu bieten und die Diagnose der Rendering-Pipeline in Chromium kontinuierlich zu verbessern.

Wir möchten einige aktuelle Fortschritte vorstellen, konkrete Tools an die Hand geben und Ideen für zukünftige Messwerte für die flüssige Wiedergabe von Animationen erörtern. Wie immer freuen wir uns über Ihr Feedback.

In diesem Beitrag werden drei Hauptthemen behandelt:

• Ein kurzer Blick auf Animationen und Animations-Frames.
• zur Messung der flüssigen Wiedergabe von Animationen
• Hier sind einige praktische Vorschläge, die Sie bei der Arbeit mit Labortools anwenden können.

Was sind Animationen?

Animationen erwecken Inhalte zum Leben! Durch Animationen, die sich bewegen, insbesondere als Reaktion auf Nutzerinteraktionen, wirken Animationen natürlicher, verständlicher und unterhaltsamer.

Schlecht implementierte Animationen oder einfach zu viele Animationen können jedoch die Nutzerfreundlichkeit beeinträchtigen und dazu führen, dass sie überhaupt keinen Spaß macht. Wahrscheinlich haben wir alle schon einmal mit einer Benutzeroberfläche interagiert, die einfach zu viele hilfreiche Übergangseffekte hinzugefügt hat, die bei schlechter Leistung sogar unangenehm werden können. Einige Nutzer bevorzugen daher möglicherweise geringere Bewegungen, was Sie berücksichtigen sollten.

Hinweis : Weitere Informationen zu Animationen, etwa zum Erstellen leistungsfähiger Animationen und zum Überprüfen von Animationen mit Entwicklertools

Wie funktionieren Animationen?

Zur Erinnerung: Die Rendering-Pipeline besteht aus einigen aufeinanderfolgenden Phasen:

1. Stil:Sie können die Stile berechnen, die auf die Elemente angewendet werden.
2. Layout:Damit generieren Sie die Geometrie und Position für jedes Element.
3. Farbe:Füllen Sie die Pixel für jedes Element in Ebenen aus.
4. Zusammengesetzt:Zeichnen Sie die Ebenen auf den Bildschirm.

Es gibt zwar viele Möglichkeiten, Animationen zu definieren, aber alle funktionieren im Grunde über eine der folgenden Methoden:

• Layout-Eigenschaften anpassen
• paint-Eigenschaften anpassen
• Zusammengesetzte Eigenschaften anpassen

Da diese Phasen sequenziell sind, ist es wichtig, Animationen anhand von Attributen zu definieren, die sich weiter unten in der Pipeline befinden. Je früher das Update erfolgt, desto höher sind die Kosten und es ist weniger wahrscheinlich, dass es reibungslos verläuft. Weitere Informationen finden Sie unter Rendering-Leistung.

Das Animieren der Layouteigenschaften kann zwar praktisch sein, dafür fallen jedoch Kosten an, auch wenn diese Kosten nicht sofort ersichtlich sind. Animationen sollten nach Möglichkeit in Bezug auf Änderungen der zusammengesetzten Eigenschaften definiert werden.

Um für reibungslose und effiziente Animationen zu sorgen, müssen Sie deklarative CSS-Animationen definieren oder Webanimationen verwenden und zusammengesetzte Eigenschaften animieren. Dennoch garantiert dies allein nicht, dass eine reibungslose Ausführung der Elemente wichtig ist, da selbst effiziente Webanimationen Leistungsgrenzen haben. Deshalb ist es immer wichtig zu messen!

Was sind Animationsframes?

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

Zeigt Updates in einem gewissen Intervall an, sodass visuelle Aktualisierungen in Batches zusammengefasst werden. Viele Bildschirme werden in einem festen Zeitintervall aktualisiert, z. B. 60 Mal pro Sekunde (60 Hz). Einige modernere Displays bieten höhere Aktualisierungsraten (90–120 Hz werden inzwischen üblich). Diese Displays können sich bei Bedarf aktiv zwischen den Aktualisierungsraten anpassen oder sogar vollständig variable Framerates bieten.

Das Ziel für jede Anwendung, z. B. ein Spiel oder ein Browser, besteht darin, alle diese zusammengefassten visuellen Aktualisierungen zu verarbeiten und jedes Mal innerhalb der Frist einen visuell vollständigen Animationsframe zu erzeugen. Dieses Ziel unterscheidet sich jedoch vollständig von anderen wichtigen Browseraufgaben wie dem schnellen Laden von Inhalten aus dem Netzwerk oder der effizienten Ausführung von JavaScript-Aufgaben.

Es kann zu schwierig werden, alle visuellen Aktualisierungen innerhalb der von der Anzeige vorgegebenen Frist abzuschließen. In diesem Fall zieht der Browser einen Frame zurück. Der Bildschirm wird nicht schwarz, er wiederholt sich einfach. Jetzt sehen Sie noch etwas länger das gleiche visuelle Update – der gleiche Animationsframe, der beim vorherigen Frame angezeigt wurde.

Das passiert tatsächlich oft! Sie ist nicht unbedingt wahrnehmbar, insbesondere bei statischen oder dokumentenähnlichen Inhalten, wie sie vor allem auf der Webplattform üblich sind. Ausgeschiedene Frames werden nur sichtbar, wenn wichtige visuelle Updates wie Animationen vorhanden sind, für die ein stetiger Stream von Animationsaktualisierungen erforderlich ist, um eine flüssige Bewegung anzuzeigen.

Was wirkt sich auf Animationsframes aus?

Webentwickler können die Fähigkeit eines Browsers, visuelle Aktualisierungen schnell und effizient zu rendern und zu präsentieren, erheblich beeinträchtigen.

Beispiele:

• Inhalte, die zu groß oder ressourcenintensiv sind, um sie auf dem Zielgerät schnell zu decodieren
• Zu viele Ebenen verwenden, die zu viel GPU-Arbeitsspeicher erfordern.
• Definieren übermäßig komplexer CSS-Stile oder Webanimationen
• Verwendung von Anti-Mustern im Design, die schnelle Rendering-Optimierungen deaktivieren
• Im Hauptthread wird zu viel JS-Code benötigt, was zu langen Aufgaben führt, die visuelle Aktualisierungen blockieren.

Aber woher wissen Sie, wann ein Animationsframe seine Frist verpasst hat und einen verworfenen Frame verursacht hat?

Eine mögliche Methode ist die requestAnimationFrame()-Abfrage. Diese Methode hat jedoch auch mehrere Nachteile. requestAnimationFrame() (rAF) teilt dem Browser mit, dass Sie eine Animation ausführen möchten, und bittet um eine Möglichkeit, dies vor der nächsten Paint-Phase der Rendering-Pipeline zu tun. Wenn die Callback-Funktion zum erwarteten Zeitpunkt nicht aufgerufen wird, bedeutet dies, dass eine Farbe nicht ausgeführt wurde und mindestens ein Frame übersprungen wurde. Durch Abfragen und Zählen, wie oft rAF aufgerufen wird, können Sie eine Art von FPS-Messwert (Frames per Second) berechnen.

Warnung : Bei dem folgenden Code wird dringend davon abgeraten.

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()-Abfragen ist aus verschiedenen Gründen keine gute Idee:

• Jedes Skript muss seine eigene Abfrageschleife einrichten.
• Es kann den kritischen Pfad blockieren.
• Selbst wenn die rAF-Abfrage schnell ist, kann sie verhindern, dass requestIdleCallback() lange inaktive Blöcke planen kann, wenn sie kontinuierlich verwendet werden (Blöcke, die einen einzelnen Frame überschreiten).
• Ebenso wird durch das Fehlen langer inaktiver Blöcke verhindert, dass der Browser andere lang andauernde Aufgaben planen (z. B. längere automatische Speicherbereinigung und andere Hintergrund- oder spekulative Arbeiten).
• Wenn die Abfragefunktion ein- und ausgeschaltet ist, werden Fälle übersehen, in denen das Frame-Budget überschritten wurde.
• Bei Abfragen werden falsch positive Ergebnisse gemeldet, wenn der Browser eine variable Aktualisierungshäufigkeit verwendet (z. B. aufgrund der Stromversorgung oder des Sichtbarkeitsstatus).
• Und was noch wichtiger ist: Nicht alle Arten von Animationsaktualisierungen werden erfasst.

Zu viel Arbeit im Hauptthread kann die Fähigkeit beeinträchtigen, Animationsframes zu sehen. Das Jank-Beispiel zeigt, wie eine rAF-gesteuerte Animation dazu führt, dass bei zu viel Arbeit im Hauptthread (z. B. Layout) ausgelassene Frames, weniger rAF-Callbacks und niedrigere fps entstehen.

Wenn der Hauptthread ins Stocken gerät, ruckeln die visuellen Aktualisierungen. Das ist eine Verzögerung!

Viele Messtools haben den Schwerpunkt darauf gelegt, dass der Hauptthread zeitnah Ergebnisse geliefert wird und Animationsframes reibungslos funktionieren. Aber das ist noch nicht alles! Dazu ein Beispiel:

Das obige Video zeigt eine Seite, von der regelmäßig lange Aufgaben in den Hauptthread eingefügt werden. Durch diese langen Aufgaben können bestimmte Typen visueller Aktualisierungen auf der Seite nicht mehr bereitgestellt werden. Sie sehen in der oberen linken Ecke einen entsprechenden Rückgang der gemeldeten fps von requestAnimationFrame() auf 0.

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

Dies ist ein Beispiel, das gleichzeitig viele gelöschte Frames im Hauptthread enthält, aber noch viele erfolgreich bereitgestellte Frames beim Scrollen im Compositor-Thread enthält. Sobald die lange Aufgabe abgeschlossen ist, muss das Hauptthread- Paint-Update sowieso keine optische Änderung vornehmen. Die rAF-Umfrage schlug vor, dass der Frame auf 0 gesetzt würde, aber visuell würde ein Nutzer keinen Unterschied bemerken.

Für Animationsframes ist die Story nicht so einfach.

Hinweis : Es gibt viele Gründe, warum lange Aufgaben schlecht sind. Sie werden mit speziellen Performance-APIs erfasst, z. B. der Long Tasks API oder der Event Timing API. Es gibt aber auch Funktionen wie isInputPending(), bei denen längere Aufgaben bei Inaktivität sinnvoll hinzugefügt werden können.

Animationsframes: Wichtige Updates

Das Beispiel oben zeigt, dass die Story mehr als nur requestAnimationFrame() beinhaltet.

Wann spielen Animationsaktualisierungen und Animationsframes eine Rolle? Hier sind einige Kriterien, über die wir nachdenken und zu denen wir gerne Feedback erhalten würden:

• Aktualisierungen von Haupt- und Compositor-Threads
• Fehlende Farbaktualisierungen
• Animationen erkennen
• Qualität oder Quantität

Aktualisierungen von Haupt- und Compositor-Threads

Aktualisierungen des Animationsframes sind nicht boolesch. Es ist nicht der Fall, dass Frames nur vollständig abgelegt oder vollständig präsentiert werden. Es gibt viele Gründe, warum ein Animationsframe teilweise präsentiert werden kann. Das heißt, es können gleichzeitig einige veraltete Inhalte und einige neue visuelle Aktualisierungen angezeigt werden.

Das häufigste Beispiel hierfür ist, wenn der Browser nicht innerhalb der Frame-Zeit ein neues Hauptthread-Update erstellen kann, aber ein neues Compositor-Thread-Update hat (wie das vorherige Beispiel für das Scrollen mit Threads).

Deklarative Animationen zum Animieren von zusammengesetzten Attributen werden unter anderem deshalb empfohlen, weil damit eine Animation vollständig vom Compositor-Thread gesteuert werden kann, selbst wenn der Hauptthread ausgelastet ist. Mit diesen Arten von Animationen lassen sich visuelle Aktualisierungen weiterhin effizient und parallel erzeugen.

Andererseits kann es vorkommen, dass ein Hauptthread-Update endlich für die Präsentation verfügbar wird, allerdings erst, nachdem mehrere Frame-Zeitlimits verpasst wurden. In diesem Fall erhält der Browser einige neue Updates. Es ist jedoch möglicherweise nicht die aktuelle Version.

Allgemein gesagt betrachten wir Frames, die einige neue visuelle Aktualisierungen ohne alle neuen visuellen Aktualisierungen enthalten, als Teil-Frame. Partialframes sind ziemlich üblich. Im Idealfall enthalten Teilaktualisierungen mindestens die wichtigsten visuellen Aktualisierungen wie Animationen. Dies ist jedoch nur möglich, wenn Animationen vom Compositor-Thread gesteuert werden.

Fehlende Farbaktualisierungen

Eine andere Art der teilweisen Aktualisierung liegt vor, wenn Medien wie Bilder noch nicht rechtzeitig decodiert und gerastert wurden.

Und selbst wenn eine Seite vollkommen statisch ist, können Browser beim schnellen Scrollen dennoch visuelle Aktualisierungen nicht rendern. 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 nimmt einige Zeit in Anspruch. Außerdem kann es länger als ein einzelner Frame dauern, bis alles nach einem großen Scrollvorgang, z. B. dem Wischen mit dem Finger, vollständig gerendert wird. Dies wird allgemein als Checkerboarding bezeichnet.

Bei jeder Frame-Rendering-Möglichkeit kann erfasst werden, wie viele der neuesten visuellen Aktualisierungen tatsächlich auf den Bildschirm gelangt sind. Das Messen dieser Möglichkeit über viele Frames (oder Zeit) hinweg wird allgemein als Framedurchsatz bezeichnet.

Wenn die GPU wirklich stockt, beginnt der Browser (oder die Plattform) möglicherweise sogar, die Rate zu drosseln, mit der visuelle Aktualisierungen durchgeführt werden, und reduziert so die effektiven Framerates. Obwohl technisch gesehen die Anzahl der abgebrochenen Frame-Updates reduziert werden kann, erscheint visuell trotzdem ein geringerer Frame-Durchsatz.

Dennoch sind nicht alle Arten von niedrigem Frame-Durchsatz schlecht. Wenn die Seite größtenteils inaktiv ist und keine aktiven Animationen vorhanden sind, ist eine niedrige Framerate optisch genauso ansprechend wie eine hohe Framerate und kann außerdem den Akku schonen.

Wann ist der Frame-Durchsatz wichtig?

Animationen erkennen

Ein hoher Frame-Durchsatz ist besonders in Zeiten mit wichtigen Animationen wichtig. Verschiedene Animationstypen hängen von visuellen Aktualisierungen eines bestimmten Threads (Haupt-, Compositor- oder Worker) ab. Die visuelle Aktualisierung hängt also davon ab, dass dieser Thread seine Aktualisierung innerhalb der Frist bereitstellt. Wir sagen, dass ein bestimmter Thread die Glätte beeinflusst, wenn eine aktive Animation vorhanden ist, die von dieser Thread-Aktualisierung abhängt.

Einige Animationsarten sind einfacher zu definieren und zu erkennen als andere. Deklarative Animationen oder vom Nutzer eingegebene Animationen lassen sich besser definieren als JavaScript-gesteuerte Animationen, die als regelmäßige Aktualisierungen animierbarer Stileigenschaften implementiert werden.

Selbst mit requestAnimationFrame() können Sie nicht immer davon ausgehen, dass jeder rAF-Aufruf zwangsläufig eine visuelle Aktualisierung oder Animation erzeugt. Beispielsweise dürfte die rAF-Abfrage nur zum Verfolgen der Framerate (wie oben gezeigt) sich nicht auf die Glättungsmessungen auswirken, da es keine visuelle Aktualisierung gibt.

Hinweis : Die Animationserkennung in Tools sowie die Besonderheiten von Animationsimplementierungen in Browsern werden ständig weiterentwickelt und verbessert. Chrome hat vor Kurzem Hintergrundfarbenanimationen aus dem Hauptthread in den Compositor verschoben.

Qualität oder Quantität

Schließlich ist das Erkennen von Aktualisierungen von Animationen und Animationsframes immer noch nur ein Teil des Ganzen, da nur die Anzahl der Animationsaktualisierungen und nicht die Qualität erfasst wird.

So kann beispielsweise eine kontinuierliche Framerate von 60 fps angezeigt werden, während du dir ein Video ansiehst. Technisch gesehen ist das völlig reibungslos, aber das Video selbst hat möglicherweise eine niedrige Bitrate oder Probleme mit der Netzwerkpufferung. Dies wird von den Messwerten für die Animationsflüssigkeit nicht direkt erfasst, kann aber für den Nutzer verwirrend sein.

Oder ein Spiel, das <canvas> verwendet (möglicherweise sogar mit Techniken wie Offscreen Canvas, um eine konstante Framerate zu gewährleisten) kann in Bezug auf Animationsframes technisch perfekt glatt sein, während qualitativ hochwertige Spiel-Assets nicht in die Szene geladen oder Renderingartefakte gezeigt werden.

Und natürlich kann eine Website auch einfach richtig schlechte Animationen haben. 🙂

Sie waren ziemlich cool für ihre Zeit!

Status eines einzelnen Animationsframes

Da Frames teilweise dargestellt werden oder ausgelassene Frames auf eine Weise auftreten können, die sich nicht auf die Glätte auswirkt, sehen wir nun jeden Frame als Vollständigkeits- oder Glättungswert an.

Hier ist die Bandbreite der Möglichkeiten, wie wir den Status eines einzelnen Animationsframes interpretieren, geordnet vom besten zum Worst-Case:

Keine Aktualisierung gewünscht	Inaktivität, der vorherige Frame wird wiederholt.
Vollständig präsentiert	Für die Aktualisierung des Hauptthreads wurde entweder ein Commit innerhalb der Frist durchgeführt oder es wurde keine Aktualisierung des Hauptthreads gewünscht.
Teilweise präsentiert	Nur Compositor; die verzögerte Aktualisierung des Hauptthreads hatte keine visuelle Änderung.
Teilweise präsentiert	Nur Compositor. Der Hauptthread hatte ein visuelles Update, aber dieses Update enthielt keine Animation, die sich auf die Glätte auswirkt.
Teilweise präsentiert	Nur Compositor; der Hauptthread hatte ein visuelles Update, das sich auf die Glätte auswirkt, aber ein zuvor veralteter Frame wurde zurückgegeben und stattdessen verwendet.
Teilweise präsentiert	Nur Compositor; ohne das gewünschte Hauptupdate und die Compositor-Aktualisierung hat eine Animation, die sich auf die flüssige Darstellung auswirkt.
Teilweise präsentiert	Nur Compositor, aber das Compositor-Update hat keine Animation, die sich auf die Glätte auswirkt.
Gesetzter Frame	Keine Aktualisierung. Es war keine Compositor-Aktualisierung gewünscht und die Hauptfunktion verzögerte sich.
Gesetzter Frame	Eine Compositor-Aktualisierung war zwar gewünscht, hat sich jedoch verzögert.
Veralteter Frame	Ein Update wurde gewünscht. Es wurde vom Renderer erstellt, aber die GPU hat es vor dem vsync-Zeitlimit noch nicht bereitgestellt.

Es ist möglich, diese Stadien in eine gewisse Punktzahl umzuwandeln. Eine Möglichkeit, diesen Wert zu interpretieren, besteht möglicherweise darin, ihn als Wahrscheinlichkeit zu betrachten, dass er vom Nutzer beobachtbar ist. Ein einzelner verworfener Frame ist möglicherweise nicht besonders beobachtbar, aber eine Abfolge von vielen verworfenen Frames, die die Glättung in einer Zeile beeinträchtigen, ist sicherlich der Fall.

Zusammenfassung: Messwert für gelöschte Frames in Prozent

Es kann manchmal notwendig sein, den Status jedes Animationsframes genau zu analysieren. Es ist aber auch sinnvoll, eine kurze „Auf einen Blick“-Bewertung für ein Erlebnis zuzuweisen.

Da Frames teilweise dargestellt werden und selbst vollständig übersprungene Frame-Updates möglicherweise nicht die Flüssigkeit beeinflussen, möchten wir uns weniger auf das Zählen der Frames konzentrieren, sondern mehr auf das Ausmaß, bei dem der Browser keine visuellen Aktualisierungen bereitstellen kann, wenn es darauf ankommt.

Das mentale Modell sollte sich

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

Entscheidend ist, wie lange es dauert, bis auf wichtige Updates gewartet wird. Wir denken, dass dies der natürlichen Art und Weise entspricht, wie Nutzende in der Praxis die flüssigen Inhalte von Webinhalten erleben. Bisher haben wir zunächst folgende Messwerte verwendet:

• Durchschnittlicher Prozentsatz abgebrochen:für alle nicht inaktiven Animationsframes in der gesamten Zeitachse
• Schlechtster Fall von abgebrochenen Frames in Prozent:gemessen über gleitende Zeitfenster von 1 Sekunde.
• 95. Perzentil der verworfenen Frames in Prozent:gemessen über gleitende Zeitfenster von einer Sekunde.

Diese Werte finden Sie schon heute in einigen Chrome-Entwicklertools. Während sich diese Messwerte nur auf den Gesamt-Framedurchsatz konzentrieren, bewerten wir auch andere Faktoren wie die Framelatenz.

Hinweis: Diese Namen sind bereits in der Vergangenheit. Die Bezeichnung „Prozentual verworfen“ entspricht nicht mehr dem literalen Konzept „war ein gelöschter Frame“. Wie im vorherigen Abschnitt beschrieben, ist jeder Animationsframe eine komplizierte Anordnung von Bedingungen, die zu einer Gesamtwahrscheinlichkeit führen. Diese Namen werden sich im Laufe der Zeit ändern.

Probieren Sie es selbst in Entwicklertools aus!

Leistungs-HUD

Chromium hat ein praktisches Leistungs-HUD, das hinter einem Flag verborgen ist (chrome://flags/#show-performance-metrics-hud). Darin findest du Live-Scores für Dinge wie Core Web Vitals sowie einige experimentelle Definitionen für eine flüssige Animation basierend auf der Anzahl der verworfenen Frames im Zeitverlauf.

Frame-Rendering-Statistiken

Aktiviere in den Entwicklertools die Option „Frame-Rendering-Statistiken“ über die Rendering-Einstellungen, um eine Live-Ansicht neuer Animationsframes zu sehen. Diese sind farbcodiert, um Teilaktualisierungen von vollständig entfernten Frames zu unterscheiden. Die gemeldeten fps gelten nur für vollständig präsentierte Frames.

Frame Viewer in den Entwicklertools-Leistungsprofilen aufzeichnen

Im Bereich Leistung der Entwicklertools gibt es schon seit Langem einen Frames-Viewer. Sie war jedoch etwas nicht synchron mit der tatsächlichen Funktionsweise der modernen Rendering-Pipeline. Wir haben in letzter Zeit viele Verbesserungen vorgenommen, selbst in der aktuellen Version von Chrome Canary, die das Debugging von Animationsproblemen erheblich vereinfachen werden.

Heutzutage haben Sie festgestellt, dass Frames in der Frames-Anzeige besser an VSync-Grenzen ausgerichtet und je nach Status farbcodiert sind. Es gibt immer noch keine vollständige Visualisierung für alle oben genannten Nuancen, aber wir planen, in naher Zukunft weitere hinzuzufügen.

Chrome-Tracing

Mit Chrome Tracing, dem Tool Ihrer Wahl, um bis ins Detail zu gehen, können Sie über die neue Perfetto-UI (oder about:tracing) ein Trace für das Rendering von Webinhalten aufzeichnen und die Grafikpipeline von Chrome detailliert untersuchen. Dies kann eine gewaltige Aufgabe sein, aber wir haben kürzlich ein paar Funktionen zu Chromium hinzugefügt, um es zu vereinfachen. Im Dokument Life of a Frame erhalten Sie einen Überblick darüber, was verfügbar ist.

Durch Trace-Ereignisse können Sie definitiv bestimmen:

• Laufende Animationen (mithilfe von Ereignissen mit dem Namen TrackerValidation)
• Abrufen der genauen Zeitachse der Animationsframes (mithilfe von Ereignissen mit dem Namen PipelineReporter)
• Bei langsamen Animationsaktualisierungen können Sie mithilfe der Ereignisaufschlüsselung innerhalb von PipelineReporter-Ereignissen genau herausfinden, was die schnellere Ausführung der Animation verhindert.
• Bei eingabegesteuerten Animationen sehen Sie sich an, wie lange es dauert, bis ein visuelles Update erfolgt (mithilfe von EventLatency-Ereignissen).

Nächste Schritte

Ziel der Web Vitals-Initiative ist es, Messwerte und Empfehlungen für die Gestaltung einer positiven Nutzererfahrung im Web bereitzustellen. Lab-basierte Messwerte wie Total Blocking Time (TBT) sind von entscheidender Bedeutung, um potenzielle Interaktivitätsprobleme zu erkennen und zu diagnostizieren. Wir planen, einen ähnlichen Lab-basierten Messwert für eine reibungslose Animation zu entwickeln.

Wir halten Sie auf dem Laufenden, während wir weiter an Ideen für den Entwurf eines umfassenden Messwerts basierend auf den Daten einzelner Animationsframes arbeiten.

Zukünftig möchten wir auch APIs entwickeln, mit denen sich die Animationsflüssigkeit bei echten Nutzern in der Praxis und im Labor leistungsfähig messen lässt. Wir halten dich auf dem Laufenden!

Feedback

Wir freuen uns über die jüngsten Verbesserungen und Entwicklertools, die in Chrome zur Verfügung gestellt wurden, um die Wiedergabegeschwindigkeit von Animationen zu messen. Probieren Sie diese Tools aus, vergleichen Sie Ihre Animationen und teilen Sie uns mit,

Du kannst deine Kommentare mit „[Smoothness Metrics]“ in der Betreffzeile an die Google-Gruppe web-vitals-feedback senden. Wir freuen uns auf Ihr Feedback!