Konteks dan arahan
Pengguna melaporkan halaman yang patah-patah (janky) setelah mengeklik tombol filter. Jelaskan cara menemukan long task pada main-thread, menilai pengaruhnya terhadap Interaction to Next Paint (INP), dan memverifikasi perbaikannya.
Bedakan antara input delay, event-handler work, dan next paint. Mengatakan “tambahkan debounce” atau “gunakan worker” bukanlah sebuah diagnosis. Sertakan bukti pengguna riil, trace lab, metrik regresi, dan batasan fallback.
Hal yang diuji oleh pewawancara
Model performa
Jawaban yang kuat memecah interaksi menjadi input waiting, event processing, rendering, dan painting, lalu menjelaskan mengapa main-thread yang sibuk menunda respons browser.
Diagnosis berbasis bukti
Gunakan PerformanceObserver, trace Performance browser, dan konteks interaksi untuk mengidentifikasi skrip, komponen, serta ukuran data alih-alih sekadar menebak.
Pertukaran solusi (Tradeoffs)
Bahas pemecahan tugas (task splitting), pengurangan pekerjaan sinkron, virtualisasi, penundaan pembaruan non-kritis, dan worker dengan tetap memperhitungkan serialisasi serta konsistensi state.
Validasi pengguna riil
Bandingkan p75 INP, jumlah long task, persentil interaksi, dan konversi bisnis. Pisahkan sampel lab dari perangkat nyata, jaringan, dan CPU low-end.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah jank memengaruhi setiap interaksi atau hanya satu kondisi filter tertentu?
- Perangkat, browser, dan ukuran data apa saja yang masuk dalam cakupan?
- Apakah masalah terjadi pada pemuatan awal, pemrosesan event, atau layout dan paint setelah event?
- Apakah data sampel INP pengguna riil, durasi event, dan long task sudah tersedia?
- Haruskah hasil diperbarui secara sinkron, atau bisakah UI merespons sebelum komputasi selesai?
- Bisakah pengurutan, paginasi, atau presisi hasil diubah?
Kerangka jawaban 30 detik
“Saya akan menggunakan sampel INP dan interaksi pengguna riil untuk menemukan halaman yang terpengaruh, lalu merekam trace Performance dengan perangkat dan ukuran data yang sama. PerformanceObserver dapat mengumpulkan long task di atas 50ms; trace akan menemukan call stack dan fase paint. Jika pekerjaan event yang sinkron terlalu besar, saya akan membagi tugas, mengurangi rerender, dan memvirtualisasikan daftar. Saya hanya akan mempertimbangkan worker untuk pekerjaan CPU murni yang menguntungkan, dengan memperhitungkan biaya pesan dan serialisasi. Setelah itu, saya akan membandingkan p75 INP, long task interaksi, dan konversi.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Menetapkan baseline
Segmentasikan p75 INP, durasi event, penundaan next-paint, jumlah long task, dan error berdasarkan halaman, interaksi, perangkat, serta rilis. Mesin lokal yang cepat bukanlah representasi baseline populasi.
Langkah 2: Mereproduksi dan menemukan lokasi masalah
Rekam interaksi filter di panel Performance browser. Periksa flame chart main-thread, long task, layout, dan paint. PerformanceObserver dapat mengumpulkan entri long task saat runtime serta menyertakan konteks halaman, interaksi, dan rilis.
Langkah 3: Memisahkan bottleneck
Waktu tunggu input yang lama mengindikasikan adanya tugas sinkron sebelumnya; pekerjaan event yang lama mengindikasikan parsing, pemfilteran, atau pembaruan state; paint yang lama mengindikasikan masalah layout, style, atau DOM yang terlalu besar. INP adalah keseluruhan alur dari input hingga next paint, bukan sekadar durasi satu fungsi.
Langkah 4: Mengurangi pekerjaan sinkron
Kurangi komputasi dan rerender dengan paginasi, virtualisasi, pemfilteran inkremental, dan caching. Pindahkan logging, prefetching, dan analitik keluar dari jalur interaksi kritis. Gunakan penjadwalan idle atau chunking hanya jika memiliki rencana cadangan saat waktu idle tidak mencukupi.
Langkah 5: Mengevaluasi penggunaan worker
Worker cocok untuk pekerjaan CPU murni dengan data yang transferable atau dapat dikelola. Penyalinan data berukuran besar, pengiriman pesan yang terlalu sering, dan manipulasi DOM dapat menghapus manfaat performa. Berikan versi pada hasil, batalkan tugas yang sudah usang, dan cegah filter lama menimpa state yang lebih baru.
Langkah 6: Memverifikasi dan mencegah regresi
Putar ulang pengujian pada perangkat low-end dan dataset yang representatif, lalu lakukan peluncuran secara bertahap. Bandingkan p75/p95 INP, jumlah long task, penyelesaian interaksi, pembatalan, dan konversi. Tetapkan performance budget yang memberikan peringatan atau memblokir regresi.
Contoh jawaban berkualitas tinggi
“Pertama, saya akan menggunakan data pengguna riil untuk mengidentifikasi interaksi, perangkat, dan rilis tempat masalah terkonsentrasi, lalu merekam interaksi filter dengan ukuran data yang sama. Jika trace menunjukkan pemfilteran array, pembaruan state, dan layout daftar berada dalam satu handler, saya akan menyimpan cache hasil pemfilteran, memvirtualisasikan daftar, dan menunda pekerjaan non-kritis.
Saya akan mengumpulkan long task di atas 50ms dengan PerformanceObserver dan menghubungkannya dengan halaman serta interaksi. Jika pemfilteran tetap menjadi bottleneck CPU murni, saya akan memindahkannya ke worker, membatasi ukuran pesan, dan membuang hasil yang sudah usang. Saya akan merilis perbaikan secara canary di perangkat low-end dan membandingkan p75 INP, jumlah long task, pembatalan, dan penyelesaian filter sebelum meluncurkannya ke skala penuh.”
Kesalahan umum
- Hanya melihat latensi rata-rata → pengguna pada ekor distribusi terabaikan → segmentasikan p75/p95 INP berdasarkan perangkat.
- Menganggap long task sebagai INP → waktu input dan paint terabaikan → telusuri seluruh timeline interaksi.
- Menambahkan debounce untuk setiap masalah jank → respons yang diperlukan bisa tertunda → temukan bottleneck komputasi, render, dan jaringan terlebih dahulu.
- Memindahkan semua tugas ke worker → biaya penyalinan dan pengiriman pesan meningkat → migrasikan hanya pekerjaan CPU murni yang menguntungkan.
- Hanya menguji di laptop pengembangan → perangkat low-end tetap mengalami jank → uji ulang pada perangkat, data, dan kohort peluncuran yang representatif.
- Melakukan chunking tanpa pembatalan → hasil yang usang menimpa state baru → tambahkan pemeriksaan versi, pembatalan, dan commit.
- Hanya menggunakan Lighthouse lab → interaksi riil terlewatkan → ambil sampel INP dan long task dari pengguna riil.
- Tidak ada performance budget setelah perbaikan → regresi tidak terdeteksi → tetapkan ambang batas dan pemantauan berkelanjutan.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Long task hanya berlangsung 60ms. Mengapa INP masih buruk?
Periksa waktu tunggu input, layout dan paint setelah handler, serta tugas-tugas di sekitarnya. INP mencakup seluruh jalur respons; satu tugas berdurasi 60ms bukanlah keseluruhan penjelasannya.
Pertanyaan lanjutan 2: Bagaimana jika worker justru membuat hasilnya lebih lambat?
Ukur biaya serialisasi, transfer data, dan penjadwalan. Pertahankan jalur cepat (fast path) pada main-thread untuk data kecil, gabungkan pesan yang lebih besar atau transfer buffer, dan batalkan permintaan yang sudah usang.
Pertanyaan lanjutan 3: Bagaimana cara mengamati sumber dari long task?
Catat waktu mulai, durasi, halaman, dan rilis menggunakan PerformanceObserver, lalu gunakan trace Performance untuk melihat call stack. Jangan pernah mencatat data input pengguna yang sensitif.
Pertanyaan lanjutan 4: Bagaimana jika pemfilteran harus terasa instan?
Konfirmasi penerimaan input dan tampilkan indikator progres secara sinkron, kemudian lakukan komputasi secara inkremental. Jaga agar versi hasil tetap selaras dengan state filter dan bedakan state sementara dengan state yang telah selesai.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa konversi tidak terganggu?
Rilis perubahan secara canary dan bandingkan p75 INP, tingkat penyelesaian, pembatalan, error, dan konversi utama berdasarkan perangkat serta jaringan, dengan menetapkan kriteria penghentian yang jelas.
Sumber 1: Data performa MDN
MDN mendefinisikan rekaman long task sebagai tugas yang berlangsung selama 50ms atau lebih, yang menyediakan bukti runtime atas pemblokiran main-thread.
Sumber 2: PerformanceObserver
MDN mendokumentasikan pemantauan entri performa dengan PerformanceObserver, yang mendukung pengumpulan long task dan konteks rilis saat runtime.
Sumber 3: Long Tasks dan INP di web.dev
web.dev menjelaskan bahwa long task memblokir main-thread dan menunda respons, serta menyarankan pemecahan tugas, pengurangan pekerjaan sinkron, dan evaluasi penggunaan worker; INP merekam responsivitas dari interaksi hingga next paint.