Masukan developer diperlukan - Frame Timing API

Selama beberapa tahun terakhir, browser telah melakukan kemajuan besar dalam hal performa rendering, terutama di perangkat seluler. Jika sebelumnya Anda tidak memiliki harapan untuk mencapai kecepatan frame yang lancar untuk hal-hal yang rumit, sekarang setidaknya hal itu dapat dicapai jika Anda berhati-hati.

Namun, bagi sebagian besar dari kita, ada kesenjangan antara apa yang dapat kita uji secara wajar di perangkat kita sendiri dan apa yang dialami pengguna. Jika mereka tidak mendapatkan kecepatan 60 fps yang halus, pengalaman mereka akan terganggu, dan pada akhirnya mereka akan beralih ke tempat lain dan kami akan mengalami kerugian. W3C juga membahas 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 ini. Jadi, jika Anda lebih suka menonton daripada membaca, lihat video berikut:

Penggunaan Frame Timing API

Tidak diragukan lagi, ada banyak hal yang dapat Anda lakukan dengan Frame Timing API, dan yang terpenting, Anda dapat mengukur hal-hal yang penting bagi Anda dan project Anda. Meskipun demikian, berikut beberapa ide:

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

Presentasi singkat

Berikut tampilan API saat ini dalam spesifikasi: dengan API ini, Anda akan dapat mengambil data tentang pengaturan waktu thread perender, tempat JavaScript, gaya, dan tata letak berjalan. (Anda mungkin pernah mendengar thread perender disebut thread utama; keduanya sama dengan nama lain.)

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

Setiap kumpulan data thread perender yang Anda dapatkan akan terlihat seperti ini:

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

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

Namun, lebih dari itu, Anda juga mendapatkan cpuTime, sehingga Anda akan tahu apakah Anda berada dalam batas 16 md dengan nyaman, atau apakah Anda sudah hampir mencapai batas. Jika cpuTime berada tepat di dekat batas 16 md, tidak ada banyak ruang untuk hal-hal seperti pengumpulan sampah yang aktif dan, dengan penggunaan CPU yang tinggi, konsumsi baterai juga akan lebih tinggi.

Selain thread perender, Anda juga dapat mengambil data tentang pengaturan waktu thread kompositor, tempat proses menggambar dan pengomposisian terjadi:

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

Setiap peristiwa ini juga akan kembali dengan nomor frame sumber, yang dapat Anda gunakan untuk mengaitkan kembali ke peristiwa thread utama:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Karena cara kerja komposisi sering kali di browser, mungkin ada beberapa data ini per data thread perender, sehingga Anda dapat menggunakan sourceFrameNumber untuk menggabungkannya kembali. Ada juga beberapa diskusi tentang apakah harus ada waktu CPU dalam data ini juga, jadi jika Anda merasa sangat yakin, sampaikan pendapat Anda di masalah GitHub.

Informasi selengkapnya

API ini belum tersedia, tetapi semoga segera tersedia. Sementara itu, berikut beberapa hal yang dapat Anda baca dan lakukan: