Apa Itu INP dan Berapa Batas Nilainya
INP, singkatan dari Interaction to Next Paint, mengukur berapa lama layar butuh waktu menanggapi interaksi pengunjung, dan nilai 200 milidetik atau kurang dianggap baik. Angka itu dibaca pada persentil ke-75 kunjungan nyata, dipisah untuk ponsel dan desktop.
Batas lengkapnya sebagai berikut:
- Baik: 200 milidetik atau kurang.
- Perlu perbaikan: lebih dari 200 sampai 500 milidetik.
- Buruk: lebih dari 500 milidetik.
Interaksi yang dihitung adalah klik, ketukan di layar sentuh, dan penekanan tombol papan ketik. Menggulir, mengarahkan kursor, dan memperbesar tampilan tidak dihitung. Nilai akhirnya diambil dari interaksi paling lambat selama kunjungan. Pada halaman dengan sangat banyak interaksi, satu interaksi terlambat dilewatkan untuk setiap 50 interaksi supaya pencilan tidak merusak angka, tetapi sebagian besar halaman punya kurang dari 50 interaksi, jadi yang tercatat biasanya yang terburuk.
Sebagai satu dari tiga Core Web Vitals, INP perlu dibaca dari data kunjungan nyata. Pengujian cepat di laptop sendiri hanya berguna untuk mencari penyebabnya.
Bedanya dengan FID
INP menggantikan First Input Delay (FID) sebagai metrik responsivitas Core Web Vitals sejak Maret 2024. FID hanya mengukur jeda sebelum penanganan interaksi pertama dimulai, sedangkan INP mengamati seluruh interaksi sepanjang kunjungan sampai layar benar-benar menampilkan hasilnya.
| FID | INP | |
|---|---|---|
| Interaksi yang dinilai | hanya yang pertama | seluruh interaksi selama kunjungan |
| Bagian yang diukur | jeda sebelum penanganan dimulai | sampai frame berikutnya tampil |
| Status | sudah digantikan | metrik Core Web Vitals saat ini |
Akibatnya, situs yang dulu lolos FID bisa gagal di INP tanpa ada kode yang berubah. Pengukurannya lebih ketat, bukan mutu situsnya yang turun.
Tiga Bagian yang Menyusun INP
Satu interaksi terdiri dari tiga bagian waktu, dan perbaikan INP dimulai dengan mengetahui bagian mana yang paling besar.
- Input delay: waktu sebelum event handler mulai berjalan, biasanya karena main thread sedang sibuk mengerjakan hal lain.
- Processing duration: waktu yang dipakai event handler untuk berjalan.
- Presentation delay: waktu dari handler selesai sampai frame berikutnya tampil di layar.
Penyebab yang paling sering muncul di situs bisnis:
- JavaScript berat saat halaman dimuat, yang menahan main thread tepat ketika pengunjung mulai mengetuk.
- Skrip pihak ketiga seperti pelacak, obrolan langsung, peta, dan iklan yang berjalan bersamaan. Bagian ini paling sering diremehkan, karena skripnya biasanya dipasang tim lain dan jarang dipertanyakan.
- Tugas panjang yang berjalan tanpa jeda, sehingga interaksi harus menunggu sampai selesai.
- Event handler yang mengerjakan terlalu banyak dalam satu jalan.
- DOM yang besar, yang membuat setiap pembaruan tampilan lebih mahal.
Urutan Perbaikan
Perbaikan INP paling efisien kalau dimulai dari interaksi paling lambat, karena nilai yang dilaporkan diambil dari interaksi terburuk. Memperbaiki tombol yang sudah cepat tidak mengubah angkanya.
- Temukan interaksi paling lambat lebih dulu, lalu tentukan apakah masalahnya di input delay, processing duration, atau presentation delay.
- Kurangi pekerjaan main thread saat halaman dimuat, terutama parsing, kompilasi, dan eksekusi skrip yang belum dibutuhkan di layar awal.
- Tinjau skrip pihak ketiga. Buang yang tidak dipakai, dan muat sisanya setelah halaman siap.
- Pecah tugas panjang menjadi potongan kecil, misalnya dengan
setTimeout, supaya interaksi sempat dilayani di sela-selanya. Menyerahkan giliran secara rutin lebih baik daripada tidak sama sekali. - Tampilkan tanggapan visual lebih dulu, lalu tunda pekerjaan yang tidak mendesak, seperti menyimpan data atau memeriksa ejaan, ke tugas berikutnya.
- Ringankan event handler, dan hindari layout thrashing, yaitu membaca ukuran atau posisi elemen tepat setelah mengubah gayanya dalam tugas yang sama.
- Kecilkan DOM, dan pakai
content-visibilityagar elemen di luar layar tidak dirender lebih awal.
Skrip yang berat juga menunda tampilnya elemen terbesar, jadi pekerjaan ini beririsan dengan cara memperbaiki LCP. Gambar dan iklan yang belum punya ruang tetap memicu pergeseran tata letak yang dibahas dalam cara memperbaiki CLS.
Cara Menemukan Interaksi yang Lambat
Interaksi yang lambat paling mudah ditemukan lewat data lapangan, lalu diuji ulang di lab untuk mencari penyebabnya.
- Data lapangan dari layanan pemantau pengunjung nyata (RUM) menunjukkan interaksi mana yang lambat, jenisnya, dan apakah terjadi saat atau sesudah halaman dimuat. PageSpeed Insights menampilkan data kunjungan nyata dari CrUX, tetapi konteks per interaksinya biasanya lebih terbatas.
- Uji lab dengan alur pengguna yang umum. Berinteraksilah saat halaman masih dimuat, karena main thread biasanya paling sibuk pada saat itu.
- Panel Performance di Chrome DevTools untuk melihat tugas yang memblokir main thread dan layout thrashing.
- Perangkat kelas menengah sebagai alat uji, bukan komputer kerja Anda. Pengunjung nyata memakai beragam ponsel, dan nilai INP paling terasa di perangkat dengan prosesor yang lebih lemah.