Gesaan dan konteks
Pengguna melaporkan halaman tersangkut-sangkut (janky) selepas mengklik butang penapis. Terangkan cara mencari long task utas utama, menilai kesannya terhadap Interaction to Next Paint (INP), dan mengesahkan pembetulan.
Bezakan kelewatan input (input delay), kerja pengendali acara (event-handler work), dan cat seterusnya (next paint). Menyatakan "tambah debounce" atau "gunakan worker" bukanlah diagnosis. Rangkumi bukti pengguna sebenar, surihan makmal, metrik regresi, dan sempadan sandaran (fallback).
Perkara yang diuji oleh penemu bual
Model prestasi
Jawapan yang kukuh membahagikan interaksi kepada menunggu input, pemprosesan acara, rendering, dan pengecatan, kemudian menerangkan sebab utas utama yang sibuk melambatkan maklum balas penyemak imbas.
Diagnosis berasaskan bukti
Gunakan PerformanceObserver, surihan Performance penyemak imbas, dan konteks interaksi untuk mengenal pasti skrip, komponen, dan saiz data dan bukannya meneka.
Pertukaran pembaikan
Bincangkan pemisahan tugas, pengurangan kerja segerak, pemayaan (virtualization), penangguhan kemas kini bukan kritikal, dan worker sambil mengambil kira pemeringkatan (serialization) dan ketekalan keadaan.
Pengesahan pengguna sebenar
Bandingkan p75 INP, bilangan long task, persentil interaksi, dan penukaran perniagaan. Asingkan sampel makmal daripada peranti sebenar, rangkaian, dan CPU kelas rendah.
Soalan penjelasan untuk ditanya
- Adakah jank menjejaskan setiap interaksi atau satu syarat penapis sahaja?
- Peranti, penyemak imbas, dan saiz data yang manakah dalam skop?
- Adakah isu tersebut berlaku semasa muatan awal, pemprosesan acara, atau susun atur dan pengecatan selepas acara?
- Adakah sampel INP pengguna sebenar, tempoh acara, dan long task wujud?
- Adakah hasil mesti dikemas kini secara segerak, atau bolehkah UI bertindak balas sebelum pengiraan selesai?
- Bolehkah pengisihan, penomboran halaman (pagination), atau kejituan hasil diubah?
Rangka kerja jawapan 30 saat
“Saya akan menggunakan sampel INP dan interaksi pengguna sebenar untuk mencari halaman yang terjejas, kemudian merakam surihan Performance dengan peranti dan saiz data yang sama. PerformanceObserver boleh mengumpul long task melebihi 50ms; surihan tersebut mengesan timbunan panggilan dan fasa pengecatan. Jika kerja acara segerak terlalu besar, saya akan membahagikan kerja, mengurangkan render semula, dan memayankan senarai. Saya hanya akan mempertimbangkan worker untuk kerja CPU tulen yang menguntungkan, termasuk kos mesej dan pemeringkatan. Selepas itu, saya akan membandingkan p75 INP, long task interaksi, dan penukaran.”
Analisis mendalam langkah demi langkah
Langkah 1: Wujudkan garis dasar
Segmenkan p75 INP, tempoh acara, kelewatan cat seterusnya, bilangan long task, dan ralat mengikut halaman, interaksi, peranti, dan keluaran. Mesin tempatan yang pantas bukanlah garis dasar populasi.
Langkah 2: Menghasilkan semula dan mencari punca
Rakam interaksi penapis dalam panel Performance penyemak imbas. Periksa carta api (flame chart) utas utama, long task, susun atur, dan cat. PerformanceObserver boleh mengumpul entri long task masa jalan dan melampirkan konteks halaman, interaksi, dan keluaran.
Langkah 3: Asingkan kekangan (bottlenecks)
Tunggu input yang lama menunjukkan tugas segerak sebelumnya; kerja acara yang lama menunjukkan penghuraian, penapisan, atau kemas kini keadaan; cat yang lama menunjukkan susun atur, gaya, atau DOM yang besar. INP ialah keseluruhan laluan input-ke-cat-seterusnya, bukan tempoh satu fungsi sahaja.
Langkah 4: Kurangkan kerja segerak
Kurangkan pengiraan dan render semula dengan penomboran halaman, pemayaan, penapisan berperingkat, dan penimbalan (caching). Alihkan pengelogan, pengambilan awal (prefetching), dan analitik keluar daripada laluan interaksi kritikal. Gunakan penjadualan melahu (idle) atau berketul hanya dengan pelan untuk masa melahu yang tidak mencukupi.
Langkah 5: Nilaikan worker
Worker sesuai untuk kerja CPU tulen dengan data yang boleh dipindahkan atau diuruskan. Salinan yang besar, pemesejan yang kerap, dan capaian DOM boleh memadamkan keuntungan prestasi. Versikan hasil, batalkan kerja lapuk, dan elakkan penapis lama daripada menulis ganti keadaan yang lebih baharu.
Langkah 6: Sahkan dan cegah regresi
Main semula pada peranti kelas rendah dan set data yang mewakili, kemudian lancarkan secara beransur-ansur. Bandingkan p75/p95 INP, bilangan long task, penyiapan interaksi, pembatalan, dan penukaran. Tetapkan belanjawan prestasi yang memberi amaran atau menyekat regresi.
Contoh jawapan berkualiti tinggi
“Saya mula-mula akan menggunakan data pengguna sebenar untuk mengenal pasti interaksi, peranti, dan keluaran di mana masalah itu tertumpu, kemudian merakam penapis dengan saiz data yang sama. Surihan menunjukkan penapisan tatasusunan, kemas kini keadaan, dan susun atur senarai dalam satu pengendali, jadi saya akan mencache penapisan, memayankan senarai, dan menangguhkan kerja bukan kritikal.
Saya akan mengumpul long task melebihi 50ms dengan PerformanceObserver dan mengaitkannya dengan halaman serta interaksi. Jika penapisan kekal sebagai kekangan CPU tulen, saya akan memindahkannya ke worker, mengehadkan saiz mesej, dan membuang hasil lapuk. Saya akan menguji pembetulan secara canary pada peranti kelas rendah dan membandingkan p75 INP, bilangan long task, pembatalan, dan penyiapan penapis sebelum mengembangkannya.”
Kesilapan biasa
- Hanya melihat kependaman purata → pengguna ekor hilang → segmenkan p75/p95 INP mengikut peranti.
- Menganggap long task sebagai INP → input dan cat ditinggalkan → surih keseluruhan garis masa interaksi.
- Menambah debounce pada sebarang jank → maklum balas yang diperlukan mungkin tertangguh → cari punca kekangan pengiraan, render, dan rangkaian terlebih dahulu.
- Memindahkan semua kerja ke worker → kos penyalinan dan pemesejan meningkat → hijrahkan kerja CPU tulen yang menguntungkan sahaja.
- Menguji pada komputer riba pembangunan sahaja → peranti kelas rendah masih tersangkut-sangkut → main semula pada peranti, data, dan kohort pelancaran yang mewakili.
- Pembahagian ketulan tanpa pembatalan → hasil lapuk menulis ganti keadaan baharu → tambah semakan versi, pembatalan, dan komit.
- Menggunakan Lighthouse makmal sahaja → interaksi sebenar terlepas → sampel INP dan long task pengguna sebenar.
- Tiada belanjawan prestasi selepas pembetulan → regresi tidak disedari → tetapkan ambang dan pemantauan berterusan.
Soalan susulan dan respons
Soalan susulan 1: Satu long task hanya 60ms. Mengapa INP masih teruk?
Periksa menunggu input, susun atur dan cat selepas pengendali, serta tugas bersebelahan. INP ialah laluan tindak balas lengkap; satu tugas 60ms bukanlah keseluruhan penjelasan.
Soalan susulan 2: Bagaimana jika worker menjadikan hasilnya lebih perlahan?
Ukur pemeringkatan, pemindahan, dan penjadualan. Kekalkan laluan pantas utas utama untuk data kecil, kumpulkan mesej yang lebih besar atau pindahkan penimbal (transfer buffers), dan batalkan permintaan lapuk.
Soalan susulan 3: Bagaimanakah anda memerhati sumber long task?
Rakam masa mula, tempoh, halaman, dan keluaran dengan PerformanceObserver, kemudian gunakan surihan Performance untuk melihat timbunan panggilan. Jangan sekali-kali log input pengguna yang sensitif.
Soalan susulan 4: Bagaimana jika penapisan mesti dirasakan serta-merta?
Akui input dan tunjukkan kemajuan secara segerak, kemudian kira secara berperingkat. Pastikan versi hasil sejajar dengan keadaan penapis dan paparkan keadaan sementara berbanding keadaan yang telah selesai.
Soalan susulan 5: Bagaimanakah anda membuktikan penukaran tidak terjejas?
Lancarkan perubahan secara canary dan bandingkan p75 INP, penyiapan, pembatalan, ralat, dan penukaran teras mengikut peranti dan rangkaian, dengan syarat henti yang jelas.
Sumber 1: Data prestasi MDN
MDN mentakrifkan rekod long task sebagai tugas yang berlangsung selama 50ms atau lebih, memberikan bukti masa jalan bagi sekatan utas utama.
Sumber 2: PerformanceObserver
MDN mendokumentasikan pemerhatian entri prestasi dengan PerformanceObserver, menyokong pengumpulan masa jalan bagi long task dan konteks keluaran.
Sumber 3: Long Tasks dan INP di web.dev
web.dev menerangkan bahawa long task menyekat utas utama dan melambatkan maklum balas, serta mengesyorkan pemisahan tugas, pengurangan kerja segerak, dan penilaian worker; INP merekodkan kereaktifan daripada interaksi hingga ke cat seterusnya.