Entwicklerfeedback erforderlich – Frame Timing API

Paul Lewis

In den letzten Jahren haben Browser große Fortschritte bei der Rendering-Leistung gemacht, insbesondere auf Mobilgeräten. Wo bisher keine Hoffnung auf eine reibungslose Framerate bei Remote-Komplexen besteht, ist das heute zumindest möglich, wenn man aufpasst.

Bei den meisten von uns gibt es jedoch eine gewisse Diskrepanz zwischen dem, was wir auf unseren eigenen Geräten testen können, und dem, was unsere Nutzer erleben. Wenn sie keine flüssigen 60 fps erreichen, ist das Spielerlebnis beeinträchtigt. Letztendlich wechseln sie woanders hin und wir werden leiden. Außerdem erörtert das W3C eine neue API, die uns helfen könnte, das zu sehen, was unsere Nutzer sehen: die Frame Timing API.

Jake Archibald und ich haben vor Kurzem ein Video mit einer Übersicht über die API aufgenommen. Sehen Sie sich diese Videos an:

Verwendung der Frame Timing API

Zweifellos gibt es eine Reihe von Dingen, die Sie mit der Frame Timing API tun können, und vor allem können Sie messen, was Ihnen und für Ihr Projekt wichtig ist. Dennoch hier ein paar Ideen:

  • FPS Ihrer JavaScript- und CSS-Animationen erfassen
  • Erfassen Sie, wie flüssig und ohne Scrollen Ihre Seite gescrollt wird (oder vielleicht auch Ihre raffinierte Liste mit unendlichem Scrollen).
  • Die Showbiz-Effekte werden je nach Auslastung des Geräts automatisch herunterskaliert.
  • Regressionstests für Laufzeitleistungsmesswerte.

Der Elevator Pitch

So sieht die API in der Spezifikation aus: Mit ihr können Sie Daten zum Renderer-Thread-Timing abrufen, wo JavaScript, Stile und Layout ausgeführt werden. Vielleicht haben Sie den Renderer-Thread als Hauptthread gehört.

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

Jeder Datensatz des Renderer-Threads, den Sie zurückerhalten, sehen ungefähr so aus:

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

Jeder Datensatz ist im Wesentlichen ein Objekt, das eine eindeutige Framenummer, einen hochauflösenden Zeitstempel für den Beginn des Frames und ein weiterer für die CPU-Auslastung enthält. Mit einem Array dieser Werte können Sie sich jeden der startTime-Werte ansehen und herausfinden, ob der Hauptthread mit 60 fps arbeitet. Im Wesentlichen bedeutet das: "Geht der startTime-Wert jedes Frames in etwa 16-ms-Blöcken nach oben?"

Darüber hinaus gibt es cpuTime, damit du weißt, ob du dich wohl innerhalb der 16 ms-Grenze befindest oder ob du auf der Leitung warst. Wenn sich cpuTime näher an der Grenze von 16 ms befindet, ist beispielsweise nicht viel Platz für die automatische Speicherbereinigung und bei hoher CPU-Auslastung ist der Akkuverbrauch ebenfalls höher.

Zusätzlich zum Renderer-Thread können Sie auch Daten zum Timing von Compositor-Threads abrufen, wo Painting und Compositing stattfinden:

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

Jedes von ihnen enthält auch eine Quell-Frame-Nummer, mit der Sie eine Verbindung zu den Ereignissen des Hauptthreads herstellen können:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Aufgrund der häufigen Funktionsweise von Compositing in Browsern können mehrere dieser Datensätze pro Renderer-Thread-Eintrag vorhanden sein, sodass Sie diese mithilfe von sourceFrameNumber wieder miteinander verknüpfen können. Es wird auch diskutiert, ob diese Datensätze auch CPU-Zeit haben sollten. Wenn Sie also ausdrücklich die GitHub-Probleme besprechen möchten.

Weitere Informationen

Diese API wird noch nicht ausgeliefert. Wir hoffen aber, dass dies bald der Fall sein wird. In der Zwischenzeit können Sie Folgendes lesen und tun: