Memperkenalkan scheduler.yield(): API Terbaru Chrome untuk Mengoptimalkan INP

Diterbitkan: 2023-09-15

Tidak ada keraguan bahwa Google mengutamakan daya tanggap pada tahun 2023.

Sejauh ini, mereka:

Memindahkan Interaksi ke Cat Berikutnya dari eksperimental ke tertunda;
Mengumumkan bahwa POLRI akan menggantikan First Input Delay sebagai metrik Core Web Vital baru untuk daya tanggap pada bulan Maret 2024;
Mulai menandai masalah POLRI di Search Console dan mengirim email ke situs web yang tidak memenuhi ambang batas respons yang baik.

Kini, Tim Chrome mengumumkan bahwa mereka sedang menjalankan uji coba asal untuk API penjadwal baru – scheduler.yield() .

scheduler.yield() diharapkan dapat membantu pengembang meningkatkan respons situs mereka dengan menyediakan cara yang lebih mudah dan lebih baik untuk mengembalikan kontrol ke thread utama.

Baca terus untuk mengetahui lebih lanjut tentang API baru dan cara mencobanya di situs web Anda.

Rekap Singkat tentang Tugas Panjang dan Thread Utama

Jika Anda sangat mengetahui tugas panjang dan thread utamanya, silakan lewati bagian ini. Jika belum, sebaiknya Anda membaca rekap singkat ini karena ini merupakan dasar untuk memahami scheduler.yield() dan cara mengimplementasikannya.

Segala sesuatu yang dilakukan browser sebagai pekerjaan dianggap sebagai tugas. Ini termasuk rendering, parsing HTML dan CSS, menjalankan kode JavaScript yang Anda tulis, dan hal-hal lain yang mungkin tidak dapat Anda kendalikan secara langsung.

Thread utama adalah tempat browser melakukan sebagian besar pekerjaan.

Utas Utama

Sayangnya, thread utamahanya dapat memproses satu tugas dalam satu waktu .Dan jika suatu tugas membutuhkan waktu lebih dari 50 md untuk dijalankan, itu dianggap sebagai tugas yang panjang.

Menghadapi tugas yang panjang berarti browser akan menjalankannya selama diperlukan untuk menyelesaikannya. Setelah selesai, kontrol dikembalikan ke thread utama, memungkinkan browser memproses tugas berikutnya dalam antrian.

Tugas yang panjang adalah sumber utama rendahnya respons halaman karena menunda kemampuan browser untuk merespons masukan pengguna. Selain itu, JavaScript, dengan model run-to-completion-nya, adalah penyebab utama pemblokiran thread utama.

Itu sebabnya ia dianggap sebagai sumber daya yang memblokir render – ketika browser menemukannya, ia harus mengunduh, menguraikan, dan mengeksekusinya sebelum melakukan hal lain.

Kabar baiknya adalah hanya karena kode Anda memulai tugas di browser tidak berarti Anda harus menunggu hingga tugas tersebut selesai sebelum kontrol dikembalikan ke thread utama.

Tugas yang panjang sebelumnya

Anda dapat memecah tugas yang panjang dengan menghasilkan tugas secara eksplisit.

Dalam istilah sederhana, penyerahan tugas memastikan bahwa browser tidak terlalu terjebak dalam satu tugas sehingga melewatkan atau menunda respons terhadap tugas penting lainnya atau interaksi pengguna.

Tugas yang panjang setelahnya

Sayangnya, strategi menghasilkan keuntungan yang ada saat ini tidaklah sempurna…

Mengapa scheduler.yield(): Masalah dengan Strategi Hasil Saat Ini

Menyerah pada thread utama bukanlah konsep baru. Pengembang telah menggunakan strategi hasil yang berbeda untuk memecah tugas-tugas panjang selama beberapa waktu:

1. setWaktu habis()

setTimeout() memungkinkan Anda menjadwalkan tugas untuk dijalankan setelah penundaan tertentu atau secara berkala. Ini menunda eksekusi panggilan balik menjadi tugas terpisah, meskipun Anda menentukan batas waktu 0. Metode ini efektif bila Anda memiliki beberapa fungsi yang harus dijalankan satu demi satu.

Kekurangan: Presisi tidak dijamin. Callback mungkin tidak berjalan tepat setelah penundaan yang ditentukan karena ada tugas lain dalam antrean. Selain itu, jika Anda memproses kumpulan data yang sangat besar dalam satu putaran, tugas tersebut dapat memakan waktu, terutama dengan jutaan entri.

2. permintaanIdleCallback()

requestIdleCallback() memungkinkan Anda menjadwalkan tugas untuk dijalankan selama periode idle apa pun yang mungkin dialami browser. Ini berguna untuk melakukan tugas-tugas yang tidak mendesak tanpa memengaruhi pengalaman pengguna.

Kekurangan: requestIdleCallback() menjadwalkan tugas dengan prioritas serendah mungkin, artinya jika thread utama padat, tugas yang dijadwalkan mungkin tidak akan pernah bisa dijalankan.

3. isInputPending()

isInputPending() dapat dijalankan kapan saja untuk memeriksa apakah pengguna mencoba berinteraksi dengan elemen di halaman. Jika ya, fungsinya akan mengembalikantrue; jika tidak, ia mengembalikanfalse.

Bayangkan Anda memiliki serangkaian tugas yang harus dijalankan tetapi tidak ingin mengganggu interaksi pengguna. Anda dapat menggunakan fungsi isInputPending() dan fungsi yieldToMain() untuk memastikan input pengguna tidak tertunda saat mereka berinteraksi dengan halaman.

Kekurangan: isInputPending() mungkin tidak selalu mengembalikan nilai true segera setelah input pengguna. Ini karena sistem operasi memerlukan waktu untuk memberi tahu browser bahwa interaksi terjadi. Ini berarti kode lain mungkin sudah mulai dijalankan.

Ini adalah beberapa cara populer untuk kembali ke thread utama. Seperti yang Anda lihat, masing-masing memiliki kekurangannya masing-masing.

Namun kelemahan yang paling signifikan adalah:

Saat Anda menyerah pada thread utama dengan menunda kode untuk dijalankan pada tugas berikutnya, kode tersebut akan ditambahkan ke akhir antrian tugas.

Mengapa hal itu menjadi masalah?

Ini adalah jawaban tiga kali lipat:

Peningkatan kemungkinan kesalahan logika: Karena kode yang ditangguhkan ditempatkan di akhir antrian tugas, mungkin ada tugas lain yang dijalankan browser sebelum kembali ke tugas yang ditangguhkan. Hal ini dapat memengaruhi urutan eksekusi fungsi dan berpotensi menyebabkan kesalahan logika atau perilaku tidak terduga.
Keterlambatan eksekusi : Jika ada banyak tugas dalam antrean, mungkin diperlukan waktu yang cukup lama sebelum browser mencapai dan mengeksekusi kode yang ditangguhkan.
Ketidakpastian: Sulit untuk memprediksi dengan tepat kapan tugas yang ditangguhkan akan dijalankan, karena hal ini bergantung pada jumlah dan sifat tugas yang sudah ada dalam antrean. Ketidakpastian ini dapat membuat proses debug dan optimalisasi kinerja menjadi menantang.

Singkatnya, meskipun menggunakan strategi saat ini untuk menyerah pada thread utama dapat membantu mempertahankan antarmuka pengguna yang responsif, hal ini juga dapat menimbulkan tantangan dalam memastikan eksekusi kode yang tepat waktu dan teratur.

Memperkenalkan penjadwal.hasil()

Kegembiraan tentang Chrome yang menjalankan uji coba asal untuk scheduler.yield() adalah karena ini adalah API penjadwal yang mengatasi semua kelemahan dari strategi hasil lainnya.

Selain itu, ini adalah solusi yang memungkinkan pengembang dan pemilik mencapai situs web responsif dan skor INP yang baik sambil menjalankan sisa kode dengan lancar.

Jadi, apa yang sedang ramai dibicarakan scheduler.yield() ?

Sebagai permulaan, scheduler.yield() adalah fungsi hasil khusus. setTimeout(), misalnya, digunakan untuk memecah tugas-tugas panjang dan menghasilkan thread utama, tetapi ini lebih merupakan efek samping fungsi daripada opsi default.

Kedua, scheduler.yield() mengirimkan sisa pekerjaan ke depan antrian. Artinya, pekerjaan yang ingin Anda lanjutkan segera setelah diserahkan tidak akan mengesampingkan tugas dari sumber lain.

Sederhananya:

scheduler.yield() memberi Anda yang terbaik dari kedua dunia – Anda dapat menghasilkan untuk meningkatkan respons situs Anda dan skor INP dan memastikan bahwa pekerjaan yang ingin Anda selesaikan setelah menghasilkan tidak tertunda.

“Memfaktorkan ulang tugas yang panjang tidak selalu mudah. Sangat menyenangkan bahwa tim Chrome menyediakan cara yang ergonomis untuk melakukan hal itu. Ini jelas merupakan langkah ke arah yang benar.” – Ivailo Hristov, CTO NitroPack.

Cara Mencoba API Penjadwal Baru

Mulai di Chrome 115, Anda dapat menguji scheduler.yield sendiri.

Untuk bereksperimen dengan API baru, cukup ikuti petunjuk Google:

Jika Anda ingin bereksperimen dengan scheduler.yield secara lokal, ketik dan masukkan chrome://flags di bilah alamat Chrome dan pilih Aktifkan dari tarik-turun di bagian Fitur Platform Web Eksperimental. Ini akan membuat scheduler.yield (dan fitur eksperimental lainnya) hanya tersedia di Chrome Anda.
Jika Anda ingin mengaktifkan scheduler.yield untuk pengguna Chromium asli pada asal yang dapat diakses publik, Anda harus mendaftar untuk uji coba asal scheduler.yield. Hal ini memungkinkan Anda bereksperimen dengan aman dengan fitur-fitur yang diusulkan selama jangka waktu tertentu, dan memberikan wawasan berharga kepada Tim Chrome tentang cara fitur-fitur tersebut digunakan di lapangan. Untuk informasi selengkapnya tentang cara kerja uji asal, baca panduan ini.

Setelah Anda mengujinya, Anda juga dapat memberikan umpan balik tentang cara memperbaikinya.

Pengujian yang aman!

Bagaimana NitroPack Dapat Membantu Membuka Blokir Thread Utama

Membagi tugas yang panjang menjadi bagian-bagian yang lebih kecil sangat penting untuk memberikan pengalaman yang cepat kepada pengguna.

Namun bukankah akan lebih baik jika Anda dapat mengoptimalkan terlebih dahulu beberapa JavaScript yang berat?

Di situlah NitroPack berperan.

Dengan 35+ fitur kinerja web tingkat lanjut , NitroPack membantu 180.000+ situs web secara global mencapai pengalaman pengguna yang luar biasa, Data Web Inti, dan tingkat konversi.

Salah satu keunggulan NitroPack yang paling signifikan adalah caranya menangani eksekusi JavaScript.

Setelah menginstal NitroPack, layanan kami menunda pemuatan sumber daya yang tidak penting hingga interaksi pengguna terdeteksi.

Selain itu, berkat mekanisme pemuatan sumber daya milik kami, NitroPack dapat mengatur ulang cara sumber daya diumpankan ke thread utama. Kami melakukan ini untuk memanfaatkan sifat multi-core CPU modern dengan memindahkan tugas dari thread utama.

Dengan cara ini, kami dapat menjamin bahwa thread utama Anda tetap tidak diblokir dan tersedia untuk menangani interaksi pengguna.