Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

Dipublikasikan: 6 Mei 2022, Terakhir diperbarui: 9 September 2025

Data penggunaan Chrome menunjukkan bahwa 90% waktu pengguna di halaman dihabiskan setelah halaman dimuat. Oleh karena itu, pengukuran responsivitas di seluruh siklus proses halaman secara cermat sangatlah penting. Inilah yang dinilai oleh metrik INP.

Responsivitas yang baik berarti halaman merespons interaksi dengan cepat. Saat halaman merespons interaksi, browser akan menampilkan masukan visual dalam frame berikutnya yang dirender. Masukan visual memberi tahu Anda apakah, misalnya, item yang Anda tambahkan ke keranjang belanja online benar-benar ditambahkan, apakah menu navigasi seluler telah dibuka, apakah konten formulir login sedang diautentikasi oleh server, dan sebagainya.

Beberapa interaksi secara alami membutuhkan waktu lebih lama daripada yang lain, tetapi untuk interaksi yang sangat kompleks, penting untuk segera memberikan beberapa respons visual awal untuk memberi tahu pengguna bahwa sesuatu sedang terjadi. Frame berikutnya yang akan dirender browser adalah peluang paling awal untuk melakukannya.

Oleh karena itu, maksud INP bukan untuk mengukur semua efek akhir dari suatu interaksi—seperti pengambilan data jaringan dan update UI dari operasi asinkron lainnya—tetapi waktu saat paint berikutnya diblokir. Dengan menunda masukan visual, pengguna mungkin mendapatkan kesan bahwa halaman tidak merespons cukup cepat, dan INP dikembangkan untuk membantu developer mengukur bagian pengalaman pengguna ini.

Dalam video berikut, contoh di sebelah kanan memberikan masukan visual langsung bahwa akordeon sedang terbuka. Responsivitas yang buruk ditunjukkan dalam contoh di sebelah kiri, dan bagaimana hal itu dapat menciptakan pengalaman pengguna yang buruk.

Panduan ini menjelaskan cara kerja INP, cara mengukurnya, dan menunjukkan resource untuk meningkatkannya.

Apa itu INP?

INP adalah metrik yang menilai responsivitas keseluruhan halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi klik, ketuk, dan keyboard yang terjadi selama kunjungan pengguna ke suatu halaman. Nilai INP akhir adalah interaksi terpanjang yang diamati, dengan mengabaikan pencilan.

Interaksi adalah sekelompok pengendali peristiwa yang diaktifkan selama gestur pengguna logis yang sama. Misalnya, interaksi "ketuk" pada perangkat layar sentuh mencakup beberapa peristiwa, seperti pointerup, pointerdown, dan click. Interaksi dapat didorong oleh JavaScript, CSS, kontrol browser bawaan (seperti elemen formulir), atau kombinasi keduanya.

Latensi interaksi terdiri dari durasi terpanjang tunggal dari sekelompok pengendali peristiwa yang mendorong interaksi, dari saat pengguna memulai interaksi hingga saat browser dapat melakukan paint frame berikutnya. Dalam kasus yang jarang terjadi, mungkin tidak ada frame yang akan digambar, tetapi interaksi berakhir saat browser dapat menggambar frame.

Berapa skor INP yang baik?

Menyematkan label seperti "baik" atau "buruk" pada metrik responsivitas sulit dilakukan. Di satu sisi, Anda ingin mendorong praktik pengembangan yang memprioritaskan responsivitas yang baik. Di sisi lain, Anda harus memperhitungkan fakta bahwa ada variabilitas yang cukup besar dalam kemampuan perangkat yang digunakan orang untuk menetapkan ekspektasi pengembangan yang dapat dicapai.

Untuk memastikan Anda memberikan pengalaman pengguna dengan responsivitas yang baik, nilai minimum yang baik untuk diukur adalah persentil ke-75 pemuatan halaman yang direkam di lapangan, yang disegmentasikan di seluruh perangkat seluler dan desktop:

• INP di bawah atau pada 200 milidetik berarti halaman memiliki responsivitas yang baik.
• INP di atas 200 milidetik dan di bawah atau sama dengan 500 milidetik berarti responsivitas halaman perlu ditingkatkan.
• INP di atas 500 milidetik berarti halaman memiliki responsivitas yang buruk.

Apa yang ada dalam interaksi?

Pendorong utama interaktivitas sering kali adalah JavaScript, meskipun browser menyediakan interaktivitas melalui kontrol yang tidak didukung oleh JavaScript, seperti kotak centang, tombol pilihan, dan kontrol yang didukung oleh CSS.

Karena tujuan INP, hanya jenis interaksi berikut yang diamati:

• Mengklik dengan mouse.
• Mengetuk perangkat dengan layar sentuh.
• Menekan tombol pada keyboard fisik atau virtual.

Interaksi terjadi di dokumen utama atau di iframe yang disematkan dalam dokumen, misalnya mengklik tombol putar pada video yang disematkan. Pengguna akhir tidak akan mengetahui apakah konten berada dalam iframe atau tidak. Oleh karena itu, INP dalam iframe diperlukan untuk mengukur pengalaman pengguna di halaman tingkat teratas. Karena JavaScript Web API tidak memiliki akses ke konten iframe, hal ini dapat ditampilkan sebagai perbedaan antara CrUX dan RUM

Interaksi dapat terdiri dari beberapa peristiwa. Misalnya, penekanan tombol mencakup peristiwa keydown, keypress, dan keyup. Interaksi ketuk berisi peristiwa pointerup dan pointerdown. Peristiwa dengan durasi terlama dalam interaksi adalah yang berkontribusi pada total latensi interaksi.

Seperti yang ditunjukkan dalam diagram, durasi pemrosesan INP mencakup semua callback handler peristiwa dalam frame tersebut. Hal ini membuat penundaan input menjadi waktu sebelum callback untuk interaksi ditangani, durasi pemrosesan menjadi waktu untuk semua callback dieksekusi, dan penundaan presentasi menjadi waktu setelah callback dieksekusi hingga frame ditampilkan di layar pengguna.

INP halaman dihitung saat pengguna meninggalkan halaman. Hasilnya adalah satu nilai yang mewakili responsivitas keseluruhan halaman selama siklus prosesnya. INP yang rendah berarti halaman merespons input pengguna dengan andal.

Apa perbedaan INP dengan Penundaan Input Pertama (FID)?

INP adalah metrik pengganti Penundaan Input Pertama (FID). Meskipun keduanya merupakan metrik responsivitas, FID hanya mengukur penundaan input interaksi pertama di halaman. INP meningkatkan FID dengan mengamati semua interaksi di halaman, mulai dari penundaan input, hingga waktu yang diperlukan untuk menjalankan penangan peristiwa, dan akhirnya hingga browser telah menggambar frame berikutnya.

Perbedaan ini berarti bahwa INP dan FID adalah jenis metrik responsivitas yang berbeda. Jika FID adalah metrik responsivitas pemuatan yang dirancang untuk menilai kesan pertama halaman pada pengguna, INP adalah indikator responsivitas keseluruhan yang lebih andal, terlepas dari kapan interaksi terjadi dalam siklus proses halaman.

Bagaimana jika tidak ada nilai INP yang dilaporkan?

Halaman dapat tidak menampilkan nilai INP. Hal ini dapat terjadi karena beberapa alasan, termasuk:

• Halaman dimuat, tetapi pengguna tidak pernah mengklik, mengetuk, atau menekan tombol di keyboard.
• Halaman dimuat, tetapi pengguna berinteraksi dengannya menggunakan gestur yang tidak diukur, seperti men-scroll atau mengarahkan kursor ke elemen.
• Halaman diakses oleh bot seperti crawler penelusuran atau browser tanpa antarmuka yang belum diberi skrip untuk berinteraksi dengan halaman.

Cara mengukur INP

INP dapat diukur baik di lapangan maupun di laboratorium, sejauh Anda dapat menyimulasikan interaksi pengguna yang realistis.

Di lapangan

Idealnya, perjalanan Anda dalam mengoptimalkan INP akan dimulai dengan data lapangan. Pada kondisi terbaiknya, data lapangan dari Pemantauan Pengguna Nyata (RUM) tidak hanya akan memberi Anda nilai INP halaman, tetapi juga data kontekstual yang menyoroti interaksi spesifik yang bertanggung jawab atas nilai INP itu sendiri, apakah interaksi terjadi selama atau setelah pemuatan halaman, jenis interaksi (klik, penekanan tombol, atau ketuk), dan waktu berharga lainnya yang dapat membantu Anda mengidentifikasi bagian interaksi mana yang memengaruhi responsivitas.

Jika situs Anda memenuhi syarat untuk disertakan dalam Chrome User Experience Report (CrUX), Anda dapat dengan cepat mendapatkan data kolom untuk INP melalui CrUX di PageSpeed Insights (dan Data Web Inti lainnya). Setidaknya, Anda bisa mendapatkan gambaran INP situs Anda di tingkat asal, tetapi dalam beberapa kasus, Anda juga bisa mendapatkan data tingkat URL.

Namun, meskipun CrUX dapat memberi tahu Anda jika ada masalah, CrUX tidak dapat memberi tahu Anda penyebab masalah tersebut. Solusi RUM dapat membantu Anda menemukan detail lebih lanjut tentang halaman, pengguna, atau interaksi pengguna yang mengalami masalah responsivitas. Dengan dapat mengatribusikan INP ke setiap interaksi, Anda dapat menghindari tebakan dan upaya yang sia-sia.

Di laboratorium

Sebaiknya Anda mulai menguji di lab setelah memiliki data lapangan yang menunjukkan bahwa halaman memiliki interaksi yang lambat. Data lapangan akan membuat pekerjaan mereproduksi interaksi bermasalah di lab menjadi tugas yang jauh lebih mudah.

Namun, sangat mungkin Anda tidak memiliki data lapangan. Meskipun INP dapat diukur di beberapa alat lab, nilai INP yang dihasilkan untuk halaman selama pengujian lab akan bergantung pada interaksi yang dilakukan selama periode pengukuran. Perilaku pengguna bisa tidak terduga dan sangat bervariasi, yang berarti pengujian Anda di lab mungkin tidak memunculkan interaksi masalah dengan cara yang sama seperti data lapangan. Selain itu, beberapa alat lab tidak akan melaporkan INP halaman karena hanya mengamati pemuatan halaman tanpa interaksi apa pun. Dalam kasus tersebut, Total Blocking Time (TBT) mungkin merupakan metrik proxy yang wajar untuk INP, tetapi bukan pengganti INP itu sendiri.

Meskipun ada batasan dalam alat lab terkait penilaian INP halaman, ada beberapa strategi untuk mereproduksi interaksi lambat di lab. Strateginya mencakup mengikuti alur pengguna umum dan menguji interaksi di sepanjang proses, serta berinteraksi dengan halaman saat halaman dimuat—saat thread utama sering kali paling sibuk—untuk mengidentifikasi interaksi lambat selama bagian penting dari pengalaman pengguna tersebut.

Mengukur INP di JavaScript

Untuk mengukur INP di JavaScript, Anda perlu mengukur waktu peristiwa untuk semua interaksi, lalu mengambil persentil ke-98 di semua interaksi ini saat halaman dibongkar. Anda dapat melihat kode sumber library JavaScript web vitals yang berisi penerapan referensi tentang cara menghitung INP.

Dalam sebagian besar kasus, nilai INP saat ini pada saat halaman dibongkar adalah nilai INP akhir untuk halaman tersebut, tetapi ada beberapa pengecualian penting seperti yang tercantum di bagian berikutnya. Library JavaScript web vitals memperhitungkan hal ini sebanyak mungkin, dalam batasan Web API.

Perbedaan antara metrik dan API

• Entri event di bawah 104 milidetik tidak dilaporkan secara default menggunakan pengamat performa. Default ini dapat diubah saat pengamat performa didaftarkan menggunakan parameter durationThreshold, tetapi nilai minimumnya adalah 16 milidetik. Oleh karena itu, sebaiknya amati juga entri first-input, yang juga merupakan entri Waktu Peristiwa, tetapi dijamin dapat diamati meskipun durasinya kurang dari durationThreshold. Hal ini membantu memastikan bahwa halaman dengan interaksi selalu melaporkan beberapa nilai INP.
• Secara teknis, penghitungan persentil yang sempurna memerlukan penyimpanan semua sampel dalam memori, yang dapat menimbulkan biaya besar. Namun, Anda dapat memperkirakan persentil, terutama persentil yang sangat tinggi seperti p98, hanya dengan menyimpan daftar kecil interaksi N terburuk. 10 adalah pilihan umum.
• Jika halaman dipulihkan dari back/forward cache, nilai INP-nya harus direset ke nol karena pengguna mengalami hal ini sebagai kunjungan halaman yang berbeda.
• API tidak melaporkan entri event untuk interaksi yang terjadi dalam iframe, tetapi metrik ini melakukannya karena merupakan bagian dari pengalaman pengguna di halaman. Hal ini dapat ditampilkan sebagai perbedaan antara CrUX dan RUM. Untuk mengukur INP dengan benar, Anda harus mempertimbangkannya. Sub-frame dapat menggunakan API untuk melaporkan entri event-timing ke frame induk.

Selain pengecualian ini, INP memiliki beberapa kompleksitas tambahan karena mengukur seluruh masa aktif halaman:

• Pengguna mungkin membiarkan tab tetap terbuka untuk waktu yang sangat lama—berhari-hari, berminggu-minggu, berbulan-bulan. Bahkan, pengguna mungkin tidak pernah menutup tab.
• Di sistem operasi seluler, browser biasanya tidak menjalankan callback pelepasan halaman untuk tab latar belakang, sehingga sulit untuk melaporkan nilai "akhir".

Untuk menangani kasus tersebut, INP harus dilaporkan setiap kali halaman berada di latar belakang—selain setiap kali halaman dibongkar (peristiwa visibilitychange mencakup kedua skenario ini). Kemudian, sistem analisis yang menerima data ini perlu menghitung nilai INP akhir di backend.

Daripada menghafal dan bergelut dengan semua kasus ini sendiri, developer dapat menggunakan library JavaScript web-vitals untuk mengukur INP, yang memperhitungkan semua hal yang disebutkan sebelumnya, kecuali kasus iframe:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

Cara meningkatkan INP

Kumpulan panduan tentang mengoptimalkan INP tersedia untuk memandu Anda melalui proses mengidentifikasi interaksi lambat di lapangan, dan menggunakan data lab untuk membantu Anda mengidentifikasi penyebab dan mengoptimalkannya.

Log perubahan

Terkadang, bug ditemukan di API yang digunakan untuk mengukur metrik, dan terkadang di definisi metrik itu sendiri. Akibatnya, perubahan terkadang harus dilakukan, dan perubahan ini dapat muncul sebagai peningkatan atau regresi dalam laporan dan dasbor internal Anda.

Untuk membantu Anda mengelola hal ini, semua perubahan pada penerapan atau definisi metrik ini akan ditampilkan di Log Perubahan ini.

Jika Anda memiliki masukan untuk metrik ini, berikan di grup Google web-vitals-feedback.

Menguji pengetahuan Anda