Feedback van ontwikkelaars nodig - Frame Timing API

De afgelopen jaren hebben browsers enorme vooruitgang geboekt op het gebied van weergaveprestaties, vooral op mobiel. Waar je voorheen geen hoop had op een soepele framerate voor iets dat ook maar enigszins complex was, is dit tegenwoordig in ieder geval haalbaar als je voorzichtig bent.

Voor de meesten van ons bestaat er echter een kloof tussen wat we redelijkerwijs op onze eigen apparaten kunnen testen en wat onze gebruikers ervaren. Als ze geen zijdezachte 60 fps halen, wordt hun ervaring aangetast en uiteindelijk gaan ze ergens anders heen en zullen wij lijden. Het is dus maar goed dat het W3C een nieuwe API bespreekt die ons zou kunnen helpen zien wat onze gebruikers zien: de Frame Timing API .

Jake Archibald en ik hebben onlangs een video-overzicht van de API opgenomen, dus als je liever kijkt dan leest, kijk dan eens:

Gebruik van de Frame Timing-API

Er zijn ongetwijfeld een heleboel dingen die u kunt doen met de Frame Timing API, en, cruciaal, u kunt meten wat belangrijk is voor u en voor uw project. Toch zijn hier een paar ideeën:

  • Het bijhouden van de fps van uw JavaScript- en CSS-animaties.
  • Het bijhouden van de soepelheid van uw pagina-scrolls (of misschien die handige oneindige scroll-lijst die u heeft.)
  • Schaal uw showbizz-effecten automatisch terug op basis van de huidige belasting van het apparaat.
  • Regressietesten op runtime-prestatiestatistieken.

De elevatorpitch

Dit is hoe de API er momenteel uitziet in de specificaties: hiermee zou je gegevens kunnen ophalen over de threadtiming van de renderer, waar JavaScript, stijlen en lay-out worden uitgevoerd. (Misschien heb je gehoord dat de rendererthread de hoofdthread wordt genoemd; het is hetzelfde onder een andere naam.)

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

Elk van de rendererthreadrecords die u terugkrijgt, ziet er ongeveer zo uit:

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

Elke record is in wezen een object dat een uniek framenummer bevat, een tijdstempel met hoge resolutie voor wanneer het frame is gestart, en een andere voor hoeveel CPU-tijd het heeft gebruikt. Met een array hiervan kun je naar elk van de startTime waarden kijken en ontdekken of de hoofdthread op 60 fps draait; in wezen "gaat startTime van elk frame omhoog in blokken van ongeveer 16 ms?"

Maar meer dan dat, je krijgt ook de cpuTime , zodat je weet of je comfortabel binnen de grens van 16 ms zit, of dat je tot aan de draad zit. Als de cpuTime precies in de buurt van de grens van 16 ms ligt, is er niet veel ruimte voor zaken als het verzamelen van afval, en als het CPU-gebruik hoog is, zal het batterijverbruik ook hoger zijn.

Naast de rendererthread kun je ook gegevens ophalen over de timing van de thread van de compositor, waar het schilderen en componeren plaatsvindt:

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

Elk van deze komt ook terug met een bronframenummer, dat je kunt gebruiken om terug te koppelen naar de gebeurtenissen in de hoofdthread:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Vanwege de manier waarop compositing vaak in browsers werkt, kunnen er meerdere van deze records per threadrecord in de renderer zijn, dus u kunt het sourceFrameNumber gebruiken om deze weer aan elkaar te koppelen. Er is ook enige discussie over de vraag of er ook CPU-tijd in deze records zou moeten zitten, dus als je je sterk voelt, spreek dan uit over de GitHub-problemen .

Meer informatie

Deze API wordt nog niet verzonden, maar hopelijk binnenkort. In de tussentijd zijn hier enkele dingen die u kunt lezen en doen: