Entwicklerfeedback erforderlich – Frame Timing API

Paul Lewis
X Startseite

In den letzten Jahren haben Browser große Fortschritte bei der Renderingleistung gemacht, insbesondere auf Mobilgeräten. Früher gab es keine Hoffnung, bei komplexeren Szenen eine flüssige Framerate zu erreichen. Heute ist das zumindest möglich, wenn man ein paar Dinge beachtet.

Bei den meisten von uns gibt es jedoch eine Diskrepanz zwischen dem, was wir auf unseren eigenen Geräten vernünftigerweise testen können, und dem, was unsere Nutzer erleben. Wenn sie keine flüssigen 60 fps erhalten, ist die Nutzung eingeschränkt. Letztendlich werden sie sich woanders umsehen und wir leiden darunter. Gut, dass das W3C eine neue API entwickelt, mit der wir sehen können, was unsere Nutzer sehen: die Frame Timing API.

Jake Archibald und ich haben vor Kurzem eine Videoübersicht über die API aufgenommen. Wenn Sie lieber Videos ansehen als zu lesen, sehen Sie sich das an:

Verwendung der Frame Timing API

Mit der Frame Timing API lassen sich zweifellos viele Dinge tun. Entscheidend ist, dass Sie messen können, was für Sie und Ihr Projekt wichtig ist. Hier sind einige Ideen:

  • Die FPS Ihrer JavaScript- und CSS-Animationen erfassen
  • Sie können die flüssige Scrollfunktion Ihrer Seite (oder vielleicht auch die praktische Liste mit unendlichem Scrollen) erfassen.
  • Die Showbiz-Effekte werden automatisch basierend auf der aktuellen Auslastung des Geräts herunterskaliert.
  • Regressionstests für Laufzeitleistungsmesswerte

Der Elevator Pitch

So sieht die API derzeit in der Spezifikation aus: Mit ihr können Sie Daten zum Timing des Renderer-Threads abrufen, in dem JavaScript, Stile und Layout ausgeführt werden. (Möglicherweise haben Sie den Renderer-Thread auch schon als Hauptthread gehört. Es ist dasselbe, nur ein anderer Name.)

var rendererEvents = window.performance.getEntriesByType("renderer");

Jeder der zurückgegebenen Renderer-Thread-Einträge sieht in etwa so aus:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

Jeder Datensatz ist im Grunde ein Objekt, das eine eindeutige Frame-Nummer, einen hochauflösenden Zeitstempel für den Beginn des Frames und einen weiteren für die CPU-Zeit enthält, die er in Anspruch genommen hat. Mit einer Reihe dieser Werte können Sie sich die einzelnen startTime-Werte ansehen und herausfinden, ob der Hauptthread mit 60 fps läuft. Das bedeutet im Grunde: „Erhöht sich der startTime jedes Frames in etwa 16-ms-Schritten?“

Außerdem wird dir das cpuTime angezeigt, damit du weißt, ob du die 16 ms-Grenze locker unterschreitest oder ob es knapp war. Wenn der Wert für cpuTime nahe der Grenze von 16 ms liegt, bleibt nicht viel Spielraum für Dinge wie die Garbage Collection. Bei hoher CPU-Auslastung ist auch der Akkuverbrauch höher.

Zusätzlich zum Renderer-Thread können Sie auch Daten zum Timing des Compositor-Threads abrufen, in dem die Darstellung und das Compositing stattfinden:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

Jede dieser Meldungen enthält auch eine Quellframe-Nummer, mit der Sie sie mit den Ereignissen des Hauptthreads verknüpfen können:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Aufgrund der Art und Weise, wie das Compositing in Browsern oft funktioniert, kann es mehrere dieser Einträge pro Renderer-Thread-Eintrag geben. Mithilfe von sourceFrameNumber können Sie diese wieder zusammenführen. Es wird auch diskutiert, ob in diesen Einträgen auch CPU-Zeiten enthalten sein sollten. Wenn Sie der Meinung sind, dass dies der Fall sein sollte, äußern Sie sich in den GitHub-Problemen.

Weitere Informationen

Diese API ist noch nicht verfügbar, wird aber hoffentlich bald eingeführt. In der Zwischenzeit können Sie Folgendes lesen und tun: