Masukan developer diperlukan - Frame Timing API

Selama beberapa tahun terakhir, browser telah membuat langkah besar dalam hal performa rendering, terutama di seluler. Sebelumnya Anda tidak berharap dapat mencapai kecepatan frame yang lancar untuk sesuatu yang jauh kompleks, saat ini hal tersebut setidaknya dapat dicapai jika Anda berhati-hati.

Namun, bagi sebagian besar dari kita, ada kesenjangan antara hal yang dapat kita uji secara wajar pada perangkat kita sendiri dan pengalaman pengguna. Jika mereka tidak mendapatkan 60 fps yang halus dan lancar, maka pengalaman mereka akan terganggu, dan pada akhirnya mereka akan pergi ke tempat lain dan kami akan menderita. Kemudian, W3C sedang mendiskusikan API baru yang dapat membantu kita melihat apa yang dilihat pengguna: Frame Timing API.

Jake Archibald dan saya baru-baru ini merekam ringkasan video tentang API. Jadi, jika Anda lebih suka menonton daripada membaca, silakan lihat:

Penggunaan Frame Timing API

Tidak diragukan lagi ada banyak hal yang dapat Anda lakukan dengan Frame Timing API, dan, yang terpenting, Anda dapat mengukur apa yang penting bagi Anda dan project Anda. Meski begitu, berikut beberapa idenya:

  • Melacak fps animasi JavaScript dan CSS Anda.
  • Melacak kelancaran pengguliran halaman Anda (atau mungkin daftar pengguliran tak terbatas yang Anda miliki).
  • Menskalakan kembali efek showbiz Anda secara otomatis berdasarkan beban perangkat saat ini.
  • Pengujian regresi pada metrik performa runtime.

{i>Elevator pitch<i}

Seperti inilah tampilan API saat ini dalam spesifikasi: dengan itu Anda akan dapat menarik data pada waktu thread perender, tempat JavaScript, gaya, dan tata letak dijalankan. (Anda mungkin pernah mendengar thread perender yang disebut thread utama; ini adalah hal yang sama dengan nama lain.)

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

Setiap thread perender mencatat yang Anda lihat kembali kurang lebih seperti ini:

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

Setiap kumpulan data pada dasarnya adalah objek yang berisi nomor frame unik, stempel waktu resolusi tinggi saat frame dimulai, dan satu lagi untuk mengetahui durasi CPU yang digunakan. Dengan array ini, Anda dapat melihat setiap nilai startTime dan mengetahui apakah thread utama mencapai 60 fps; pada dasarnya, "apakah startTime setiap frame naik dalam waktu sekitar 16 md?"

Namun, selain itu, Anda juga mendapatkan cpuTime, sehingga Anda akan tahu apakah Anda sudah nyaman berada di dalam batas 16 md, atau apakah Anda tidak mampu melewati batas. Jika cpuTime berada tepat di dekat batas 16 md, tidak akan ada banyak ruang untuk hal-hal seperti pembersihan sampah memori yang dimulai dan, dengan penggunaan CPU yang tinggi, konsumsi baterai juga akan lebih tinggi.

Selain thread perender, Anda juga bisa menarik data tentang pengaturan waktu thread compositor, tempat penggambaran dan pengomposisian terjadi:

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

Masing-masing juga kembali dengan nomor frame sumber, yang dapat Anda gunakan untuk mengaitkan kembali ke peristiwa thread utama:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Karena cara pengomposisian sering berfungsi di browser, mungkin ada beberapa data ini per data thread perender, sehingga Anda dapat menggunakan sourceFrameNumber untuk mengaitkannya kembali. Ada juga diskusi tentang apakah sebaiknya ada waktu CPU dalam catatan ini juga, jadi jika Anda sangat bersedia menyampaikan masalah GitHub.

Informasi selengkapnya

API ini belum dikirim, tetapi mudah-mudahan akan segera diluncurkan. Sementara itu, berikut beberapa hal yang dapat Anda baca dan lakukan: