Wawancara Frontend: Kapan Anda harus menggunakan requestIdleCallback?

1. Pertanyaan dan Konteks

Pertanyaan ini menguji performa frontend dan dasar-dasar browser. Sebuah halaman menangani input, scrolling, dan animasi sambil juga memproses analitik, komputasi berprioritas rendah, atau pekerjaan yang ditangguhkan. Jelaskan masalah apa yang diselesaikan oleh callback idle, cara menghindari menunggu tanpa batas waktu, dan mengapa commit DOM biasanya termasuk dalam requestAnimationFrame.

2. Apa yang Sedang Dievaluasi oleh Pewawancara

Apakah Anda memahami bahwa requestIdleCallback menjadwalkan pekerjaan berprioritas rendah selama periode idle browser; fungsi ini tidak melakukan preempting terhadap thread utama.
Apakah Anda menggunakan IdleDeadline.timeRemaining() untuk membagi tugas (chunks) dan menetapkan timeout ketika pekerjaan memiliki tenggat waktu.
Apakah Anda mengenali dukungan browser yang terbatas dan merancang deteksi kapabilitas dengan semantik fallback yang eksplisit.
Apakah Anda memisahkan komputasi, pengiriman jaringan, mutasi DOM, dan timing animasi, lalu mengukur dampaknya terhadap interaksi.

Panduan wawancara frontend Coursera mencantumkan optimasi performa, metrik produksi, dan trade-off sebagai area evaluasi inti. MDN menjelaskan requestIdleCallback() sebagai pekerjaan latar belakang selama periode idle; opsi timeout dapat mencegah pekerjaan yang diperlukan menunggu terlalu lama tetapi dapat mengganggu interaksi. Contoh resmi Chrome lebih lanjut memisahkan komputasi idle dari pembaruan DOM pada frame berikutnya.

3. Pertanyaan Klarifikasi Sebelum Anda Menjawab

Apakah pekerjaan tersebut boleh ditunda? Tenggat waktu apa yang berlaku untuk batch analitik, prefetching, dan feedback pengguna yang diperlukan?
Apakah callback akan memutasi DOM, memperbarui state, menulis ke penyimpanan, atau hanya mengirim permintaan jaringan?
Apakah browser target mendukung API ini? Jika tidak, apakah pekerjaan harus ditunda, dijalankan segera, atau dibatalkan?
Metrik mana yang dilindungi: input delay, long tasks, kelancaran animasi, atau pengiriman analitik?

4. Kerangka Jawaban 30 Detik

Saya akan mengklasifikasikan pekerjaan sebagai dapat dibuang, dapat ditunda, atau diperlukan. Untuk komputasi kecil non-kritis atau antrean pengiriman, saya akan menggunakan requestIdleCallback dalam anggaran timeRemaining() yang tersedia dan menambahkan timeout hanya ketika tenggat waktu penting. Callback akan menyiapkan data alih-alih melakukan mutasi DOM yang tidak terduga; requestAnimationFrame berikutnya akan melakukan commit perubahan yang terlihat. Saya akan melakukan feature-detect pada API, mempertahankan semantik pembatalan, kedaluwarsa, dan pengiriman dalam fallback, serta mengukur input delay, long tasks, dan penyelesaian bisnis.

5. Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Putuskan Apakah Pekerjaan Termasuk dalam Waktu Idle

Feedback pengguna, animasi, dan rendering kritis tidak boleh bergantung pada waktu idle. Pengelompokan analitik (batching), prefetching non-kritis, pengindeksan bertahap (sliced), dan serialisasi latar belakang dapat menunggu. Pekerjaan yang harus selesai sebelum tenggat waktu membutuhkan timeout, tetapi jalur batas waktu tersebut dapat bersaing dengan interaksi; kurangi ukuran batch atau bagi pekerjaan jika biaya tersebut tidak dapat diterima.

Langkah 2: Bagi Pekerjaan (Chunk) dalam Anggaran

Callback menerima sebuah deadline. Proses hanya batch kecil yang muat dalam timeRemaining() dan masukkan callback lain ke dalam antrean jika masih ada pekerjaan yang tersisa. Gunakan penanda deduplikasi agar setiap event tidak menjadwalkan callback baru. Batalkan pekerjaan yang mengantre saat terjadi perubahan rute, unmount, atau versi hasil yang lebih baru sehingga hasil yang usang tidak memperbarui halaman.

Langkah 3: Pisahkan Timing Komputasi, Jaringan, dan DOM

Callback idle dapat menyiapkan data, melakukan serialisasi, atau memasukkan pengiriman ke antrean; permintaan jaringan itu sendiri tidak menjamin kelanjutan anggaran idle. Penulisan DOM dapat memicu layout dan paint yang tidak terduga, jadi lakukan komputasi atau buat fragment selama waktu idle dan lakukan commit perubahan yang terlihat di requestAnimationFrame. Jika komputasi tetap membebani CPU, Worker mengisolasi thread utama dengan lebih andal daripada pembagian tugas yang tiada henti.

Langkah 4: Rancang Kompatibilitas dan Pengukuran

Lakukan feature-detect pada API dan pilih penjadwalan native, timer, atau message channel. Jangan mengklaim fallback memiliki semantik idle native; nyatakan apakah fallback tersebut menunda, langsung menjalankan, atau membuang pekerjaan opsional. Catat panjang antrean, waktu tunggu, jumlah timeout, hit pembatalan, input delay, dan long tasks, lalu bandingkan data pengguna riil sebelum dan sesudah perubahan.

6. Contoh Jawaban Berkualitas Tinggi

Pertama-tama saya akan menanyakan apakah pekerjaan tersebut memengaruhi interaksi saat ini dan kapan harus selesai. Analitik, prefetching non-kritis, dan serialisasi yang dapat dibagi dapat menggunakan requestIdleCallback; feedback input, animasi, dan rendering kritis tidak dapat menunggu waktu idle.

Saya akan memproses batch kecil hingga timeRemaining() tidak mencukupi. Hanya antrean dengan tenggat waktu bisnis nyata yang mendapatkan timeout, dan saya menerima bahwa jalur timeout dapat menyebabkan jank. Callback bertugas menyiapkan data, sedangkan requestAnimationFrame melakukan commit perubahan DOM. Unmount dan versi hasil yang lebih baru akan membatalkan antrean sehingga pekerjaan yang usang tidak melakukan penulisan balik.

Karena MDN menandai dukungannya terbatas, saya akan melakukan feature-detect. Tanpa dukungan native, saya akan menunda dengan timer atau message channel, atau membuang pekerjaan opsional sesuai kebutuhan produk, sambil mempertahankan aturan kedaluwarsa yang sama. Terakhir, saya akan mengukur input delay, long tasks, waktu tunggu antrean, jumlah timeout, dan pengiriman analitik untuk membuktikan apakah pengalaman pengguna meningkat.

7. Pola Kegagalan Umum

Menganggap callback idle sebagai background thread; callback ini tetap berjalan di main thread, sehingga kode sinkron yang panjang akan memblokir input.
Menetapkan timeout yang pendek tanpa syarat; timeout mengubah pekerjaan berprioritas rendah menjadi lonjakan perebutan interaksi.
Melakukan mutasi DOM yang besar di dalam callback idle; biaya layout dan paint yang tidak terduga dapat menghilangkan manfaatnya.
Melewatkan deteksi kapabilitas dan menjadikan dukungan API yang terbatas sebagai prasyarat untuk kebenaran fungsi.
Menjadwalkan sekali per event tanpa penggabungan (coalescing), deduplikasi, pembatalan, atau pemeriksaan versi hasil.

8. Pertanyaan Lanjutan dan Tanggapannya

Pertanyaan Lanjutan 1: Bisakah callback menunggu selamanya jika tidak ada waktu idle?

Tanpa timeout, pekerjaan yang diperlukan dapat menunggu dalam waktu yang lama. Berikan batas waktu (timeout) pada pekerjaan yang terikat tenggat waktu dan kurangi ukuran batch atau pilih penjadwal yang lebih langsung pada jalur timeout. Biarkan pekerjaan yang dapat dibuang kedaluwarsa alih-alih mengorbankan respons input.

Pertanyaan Lanjutan 2: Mengapa tidak memperbarui DOM di dalam requestIdleCallback?

Mutasi DOM memiliki biaya layout, paint, dan compositing yang tidak terduga dan dapat melebihi anggaran idle. Lakukan komputasi atau buat fragment selama waktu idle, commit di requestAnimationFrame, dan verifikasi dengan pengukuran long task dan input-delay.

Pertanyaan Lanjutan 3: Kapan Anda harus menggunakan Worker?

Gunakan Worker ketika komputasi berat CPU yang berkelanjutan masih menempati main thread setelah dilakukan chunking. Worker menambah biaya serialisasi, komunikasi, dan pembatalan; pekerjaan kecil yang dapat ditunda lebih sederhana ditangani dengan callback idle.