Petunjuk dan konteks
Halaman terlihat bagus di Lighthouse, namun pengguna nyata melaporkan bahwa klik terasa macet. RUM yang ada saat ini hanya melaporkan nilai INP dan tidak dapat memberi tahu apakah penangan peristiwa (event handler), requestAnimationFrame, gaya dan tata letak (style and layout), atau skrip pihak ketiga yang menyebabkan penundaan tersebut. Rancang siklus observasi LoAF, korelasi, sampling, agregasi, dan perbaikan.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda memahami input delay, durasi pemrosesan (processing duration), dan presentation delay pada INP.
- Apakah Anda mengetahui bahwa LoAF mengukur frame di atas 50 milidetik dan mengekspos atribusi skrip serta waktu rendering.
- Apakah Anda mengorelasikan interaksi, LoAF, versi halaman, dan konteks perangkat alih-alih mengunggah setiap peristiwa mentah.
- Apakah Anda menangani dukungan browser, buffer, skrip lintas asal (cross-origin), dan risiko privasi.
- Apakah Anda menghubungkan data dengan perbaikan kode, pemeriksaan regresi, dan peringatan (alerting).
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah tujuannya adalah diagnosis INP, kelancaran animasi, pemantauan long-task, atau ketiganya?
- Berapa tingkat sampling, pengguna harian, anggaran pelaporan, dan periode retensi?
- Bolehkah Anda mencatat URL, sumber skrip, jenis interaksi, dan versi halaman?
- Browser mana yang harus didukung, dan apa fallback-nya ketika LoAF tidak tersedia?
- Tim mana yang bertanggung jawab atas peringatan dan perbaikan, dan apakah ambang batas harus menggunakan p75, p95, atau kohort perangkat?
Jawaban 30 detik
“Saya akan menempatkan rincian fase INP dan observasi LoAF dalam satu jalur korelasi RUM. Gunakan PerformanceObserver untuk long-animation-frame, pertahankan hanya frame yang beririsan dengan jendela interaksi ber-INP tinggi, dan simpan duration, blockingDuration, renderStart, styleAndLayoutStart, serta atribusi skrip. Deteksi dukungan, sensor (redact) bidang sensitif, lakukan sampling secara dinamis, dan kumpulkan laporan secara batch bersama versi halaman, kohort perangkat, dan kunci sesi anonim. Agregasikan berdasarkan interaksi dan rilis, lalu tautkan peringatan ke sourceURL dan fungsi. Validasi setiap perbaikan dengan kohort dan sampling yang sama.”
Penyelidikan mendalam langkah demi langkah
1. Pisahkan fase-fase INP
Input delay adalah waktu dari antrean hingga penangan dimulai, durasi pemrosesan adalah eksekusi penangan, dan presentation delay adalah waktu dari akhir pemrosesan hingga frame berikutnya selesai digambar (painted). LoAF tidak menggantikan INP; LoAF menambahkan konteks frame untuk menemukan fase yang lambat.
2. Amati entri LoAF
Amati long-animation-frame dengan PerformanceObserver alih-alih membaca garis waktu performa secara berulang-ulang. Ambang batasnya adalah 50 milidetik, dan entri mencakup duration, blockingDuration, renderStart, styleAndLayoutStart, firstUIEventTimestamp, dan scripts.
if (PerformanceObserver.supportedEntryTypes.includes("long-animation-frame")) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
queueFrameForCorrelation(entry);
}
});
observer.observe({ type: "long-animation-frame", buffered: true });
}3. Korelasikan interaksi dan rilis
Pertahankan ringkasan interaksi INP yang berumur pendek dan ring buffer dari entri LoAF. Ketika suatu interaksi berakhir, gunakan firstUIEventTimestamp, startTime, dan duration untuk menemukan frame yang beririsan dan pertahankan hanya beberapa frame yang paling jelas memberikan penjelasan. Lampirkan versi halaman, kohort eksperimen, kelas perangkat, dan kunci sesi anonim, jangan pernah menyertakan input pengguna yang lengkap.
4. Jelaskan biaya skrip dan rendering
blockingDuration memperkirakan waktu yang memblokir input atau pekerjaan prioritas tinggi; renderStart dan styleAndLayoutStart membantu memisahkan pra-render, gaya/tata letak, dan fase lainnya. scripts dapat mengidentifikasi URL thread utama, fungsi, dan jenis pemanggil (invoker), tetapi iframe lintas asal, worker, dan ekstensi mungkin memiliki atribusi yang tidak lengkap.
5. Rancang kontrol sampling dan privasi
Laporkan INP tinggi, frame panjang yang anomali, atau sampel acak kecil secara default; batasi laju (rate-limit) setiap sesi anonim. Terapkan allowlist atau hash domain skrip, hapus parameter kueri, input pengguna, dan teks DOM, serta nonaktifkan atribusi terperinci pada halaman sensitif. Terapkan retensi, akses, penghapusan, dan kebijakan sampling berversi di server.
6. Tutup siklus agregasi dan perbaikan
Agregasikan p75/p95 berdasarkan interaksi, rilis, perangkat, jaringan, dan sumber skrip alih-alih hanya rata-rata situs tunggal. Peringatan menampilkan fase input, pemrosesan, dan presentasi ditambah atribusi umum. Bandingkan sebelum dan sesudah menggunakan sampling dan kohort yang sama untuk memastikan masalah tidak berpindah ke perangkat atau interaksi lain.
Contoh jawaban yang kuat
“Saya pertama-tama akan menggunakan rincian fase INP untuk menentukan apakah input, pemrosesan, atau presentasi yang mendominasi, kemudian menambahkan bukti LoAF. Klien mendeteksi fitur dan mengamati long-animation-frame, hanya mempertahankan entri yang beririsan dengan interaksi ber-INP tinggi beserta duration, blockingDuration, waktu rendering, dan atribusi skrip yang tersedia. Korelasi menggunakan rilis, kohort eksperimen, perangkat, dan kunci sesi anonim, bukan input pengguna. Atribusi terperinci disampling dan disensor dengan batas retensi; browser yang tidak didukung tetap melaporkan INP dasar. Server mengagregasi berdasarkan interaksi, rilis, dan perangkat, memberikan peringatan pada kode sumber yang dicurigai, dan memvalidasi perbaikan dengan pemeriksaan regresi tingkat kohort.”
Kesalahan umum
- Hanya melaporkan satu angka INP → tidak ada diagnosis fase atau kode → korelasikan fase INP dengan frame LoAF.
- Mengunggah setiap frame panjang mentah → biaya tinggi dan konteks terekspos → lakukan sampling, sensor data, dan simpan frame yang beririsan dengan INP tinggi.
- Memperlakukan 50 milidetik sebagai batas kelulusan INP → ambang batas frame disalahartikan sebagai metrik produk → jelaskan ambang batas dan target persentil secara terpisah.
- Mengasumsikan setiap skrip memiliki atribusi → frame lintas asal dan worker tidak lengkap → tandai celah dan analisis bersama kohort rilis dan perangkat.
- Hanya melihat rata-rata situs → masalah parah yang spesifik untuk perangkat tertentu hilang → segmentasikan berdasarkan interaksi, perangkat, jaringan, dan rilis.
Pertanyaan lanjutan dan tanggapan
Apakah LoAF akan menggantikan Long Tasks API?
Tidak secara langsung. LoAF mengukur frame dan memberikan konteks yang lebih kaya, sementara Long Tasks tetap berguna untuk pemantauan yang sudah ada dan browser yang kompatibel. Bandingkan keduanya selama migrasi alih-alih menghapus sinyal lama secara mendadak.
Mengapa tidak mengunggah setiap URL skrip?
URL dapat berisi pengenal, parameter kueri, atau jalur internal, dan dapat meningkatkan volume data. Hapus parameter, batasi domain, hash nilainya, atau simpan hanya pemetaan sumber berversi sesuai dengan sensitivitas halaman.
Bagaimana Anda membedakan biaya tata letak dari eksekusi skrip?
Bandingkan renderStart, styleAndLayoutStart, duration, dan entri skrip. Jika waktu skrip kecil tetapi interval gaya/tata letak besar, periksa ukuran DOM, pemilih (selectors), dan tata letak sinkron; konfirmasikan dengan rekaman jejak (trace) lab.
Bagaimana dengan browser tanpa LoAF?
Lakukan deteksi fitur dan fallback ke INP dasar, Event Timing, atau Long Tasks, lalu beri tag pada versi observasi di sisi server. Jangan kecualikan pengguna tersebut dari metrik pengalaman keseluruhan; ungkapkan perbedaan kemampuan diagnostik dalam laporan tersegmentasi.