Interaction to Next Paint (INP): Cara Mengukur Responsivitas Website

Website yang cepat dibuka belum tentu terasa cepat saat digunakan. Pengunjung bisa melihat halaman dalam sekejap, tetapi tetap kesal ketika tombol tidak merespons, menu terlambat terbuka, atau filter produk membeku setelah disentuh. Interaction to Next Paint (INP) membantu mengukur masalah tersebut dengan melihat seberapa cepat halaman memberikan respons visual terhadap interaksi pengguna.

INP termasuk Core Web Vitals dan menggantikan First Input Delay (FID) pada Maret 2024. Berbeda dari FID yang hanya menilai keterlambatan awal pada interaksi pertama, INP mengamati interaksi yang memenuhi syarat sepanjang kunjungan halaman. Karena itu, metrik ini memberi gambaran yang lebih luas tentang pengalaman saat pengguna benar-benar memakai website.

Apa yang Diukur oleh INP?

INP mengukur waktu sejak pengguna mengeklik, mengetuk, atau menekan tombol keyboard hingga browser menampilkan frame berikutnya yang mencerminkan hasil interaksi. Contohnya adalah ketika pengguna membuka menu, memilih varian produk, mengirim formulir, atau menambahkan barang ke keranjang. Scroll dan zoom biasa tidak dihitung sebagai interaksi INP.

Nilai akhirnya biasanya mencerminkan interaksi paling lambat selama kunjungan, dengan penanganan pencilan untuk halaman yang memiliki sangat banyak interaksi. Angka ini bukan sekadar kecepatan unduh halaman. Website dapat memiliki gambar yang cepat tampil tetapi tetap terasa lambat jika JavaScript membuat utas utama sibuk ketika pengguna menekan tombol.

Tiga Bagian yang Membentuk Keterlambatan

• Input delay: waktu menunggu sebelum browser mulai menjalankan penanganan peristiwa. Tugas JavaScript panjang yang sedang berjalan dapat membuat klik berikutnya mengantre.
• Processing duration: waktu yang digunakan kode untuk memproses interaksi, termasuk event handler dan pekerjaan aplikasi yang dipicu olehnya.
• Presentation delay: waktu setelah pemrosesan hingga browser menyelesaikan perubahan visual. Pembaruan DOM besar, kalkulasi gaya, layout, dan paint yang mahal dapat memperpanjang bagian ini.

Memisahkan tiga bagian tersebut penting karena solusi yang tepat berbeda. Mengurangi ukuran gambar tidak otomatis memperbaiki event handler yang memblokir utas utama, sedangkan memindahkan kode ke worker tidak akan menyelesaikan layout yang terlalu mahal dengan sendirinya.

Ambang INP yang Perlu Diketahui

Untuk menilai pengalaman pengguna, Google menggunakan persentil ke-75 dari kunjungan nyata, dengan pemisahan perangkat seluler dan desktop. Panduan umum INP adalah:

• Baik: 200 milidetik atau kurang.
• Perlu peningkatan: lebih dari 200 hingga 500 milidetik.
• Buruk: lebih dari 500 milidetik.

Jangan menyimpulkan kualitas seluruh website dari satu pengujian di laptop pengembang. Perangkat kelas bawah, jaringan, ekstensi, skrip pihak ketiga, dan pola penggunaan nyata dapat menghasilkan pengalaman berbeda.

Cara Mengukur INP

1. Periksa data lapangan. Buka PageSpeed Insights atau laporan Core Web Vitals di Search Console untuk melihat data pengguna nyata jika volume data mencukupi. Bandingkan URL dan kelompok perangkat, bukan hanya skor beranda.
2. Reproduksi interaksi yang lambat. Catat langkah spesifik, misalnya membuka pencarian, mengubah filter, atau menekan tombol checkout. Uji pada perangkat seluler dan halaman yang benar-benar digunakan.
3. Rekam di Chrome DevTools. Buka panel Performance, mulai rekaman, lakukan interaksi, lalu hentikan rekaman. Periksa jalur Interactions dan Main untuk menemukan tugas panjang, event handler, serta pekerjaan rendering.
4. Gunakan data lapangan dan lab bersama-sama. DevTools membantu menemukan penyebab, sedangkan data lapangan menunjukkan apakah masalah itu dialami pengunjung dalam kondisi sebenarnya. Total Blocking Time dapat menjadi petunjuk saat pengujian lab, tetapi bukan pengganti INP lapangan.

Strategi Praktis untuk Memperbaiki INP

Kurangi pekerjaan JavaScript yang tidak perlu. Audit plugin, widget chat, analitik, iklan, dan pustaka yang dimuat setiap halaman. Hapus fitur yang tidak digunakan dan tunda skrip yang tidak dibutuhkan untuk interaksi awal.

Pecah tugas panjang menjadi bagian kecil. Jika event handler melakukan banyak pekerjaan sinkron, selesaikan bagian yang penting untuk respons awal terlebih dahulu. Pekerjaan tambahan dapat dijadwalkan setelah browser mendapat kesempatan merender. Untuk komputasi berat yang tidak membutuhkan DOM, pertimbangkan Web Worker.

Berikan umpan balik segera. Ketika permintaan jaringan masih berjalan, tampilkan status seperti “Memproses…” atau indikator loading yang bermakna. Umpan balik tidak menghapus keterlambatan teknis, tetapi membantu pengguna memahami bahwa tindakan mereka diterima. Hindari menunggu seluruh respons server sebelum memperbarui bagian antarmuka yang dapat diperbarui lebih awal.

Jaga rendering tetap ringan. Batasi perubahan DOM yang besar, hindari membaca layout lalu menulis gaya berulang kali dalam satu siklus, dan gunakan virtualisasi untuk daftar sangat panjang jika sesuai. Profilkan dahulu sebelum menerapkan optimasi CSS agar perubahan benar-benar menyasar hambatan yang terukur.

Baca juga: Speculation Rules API: Prefetch dan Prerender.

Referensi resmi: web.dev: Interaction to Next Paint (INP).

Kesimpulan

INP yang baik bergantung pada respons cepat terhadap interaksi pengguna, bukan sekadar skor laboratorium. Prioritaskan interaksi yang paling sering digunakan, ukur sebelum dan sesudah perubahan, lalu optimalkan skrip dan pekerjaan utama hanya berdasarkan profil yang terukur.