Interaksi hingga Gambar Berikutnya (INP)

Ringkasnya — INP mengukur seberapa cepat halaman Anda merespons saat seseorang mengeklik, mengetuk, atau mengetik. Browser menghitung jeda antara interaksi dan pembaruan visual berikutnya sepanjang kunjungan, lalu melaporkan nilai yang kira-kira mewakili interaksi terburuk. Nilai di bawah 200 ms tergolong baik; di atas 500 ms tergolong buruk. INP adalah satu dari tiga Core Web Vitals dan menggantikan metrik lama bernama First Input Delay pada 2024.

Apa yang sebenarnya diukur INP

Saat Anda mengeklik tombol, mengetuk menu, atau mengetik dalam kotak, Anda mengharapkan halaman bereaksi—menu terbuka, kotak centang terisi, atau teks muncul. Interaction to Next Paint (INP) mengukur berapa lama reaksi itu berlangsung: sejak interaksi Anda hingga browser menggambar frame berikutnya yang menampilkan perubahan.

Bagian pentingnya, INP tidak hanya melihat satu interaksi. Metrik ini mengamati setiap klik, ketukan, dan penekanan tombol papan ketik selama seluruh kunjungan, lalu melaporkan nilai yang mendekati interaksi paling lambat. Jadi, satu interaksi tersendat—misalnya kotak pencarian yang membeku selama setengah detik setiap kali Anda mengetik—dapat menjatuhkan keseluruhan skor.

Menggulir, mengarahkan penunjuk, dan memperbesar tampilan tidak dihitung. Hanya klik, ketukan, dan interaksi papan ketik yang diukur.

Ambang penilaian

INP dilaporkan dalam milidetik dan Google membaginya menjadi tiga kategori:

• Baik — 200 ms atau kurang
• Perlu ditingkatkan — lebih dari 200 ms hingga 500 ms
• Buruk — lebih dari 500 ms

Sebagai gambaran, 200 ms memang cepat, tetapi ruang waktunya sempit. Semua pekerjaan kode sebagai respons terhadap klik—ditambah waktu browser menggambar hasilnya—harus selesai dalam batas itu.

Mengapa INP menggantikan FID

Metrik daya tanggap lama adalah First Input Delay (FID). FID hanya mengukur penundaan sebelum interaksi pertama pada halaman mulai ditangani, dan berhenti menghitung tepat ketika pekerjaan dimulai. FID tidak menghitung berapa lama pekerjaan itu berjalan ataupun berapa lama layar membutuhkan waktu untuk diperbarui.

INP mengatasi semua kekurangan tersebut. Metrik ini mengukur waktu penuh dari awal hingga pembaruan visual untuk semua interaksi, bukan hanya yang pertama. Google meresmikan peralihannya pada 12 Maret 2024, dan FID dihapus sepenuhnya dari berbagai alat pada September 2024.

Penyebab INP buruk dalam bahasa sederhana

Hampir selalu penyebabnya adalah JavaScript yang memonopoli utas utama. Browser hanya dapat mengerjakan satu hal pada satu waktu di utas itu. Jika sebuah skrip sedang berjalan, klik Anda harus menunggu giliran. Penyebab umumnya meliputi:

• Pekerjaan berat yang dijalankan langsung di dalam handler klik atau ketuk.
• “Tugas panjang” JavaScript yang memblokir pekerjaan lain.
• Skrip pihak ketiga—analitik, banner persetujuan cookie, widget obrolan, dan pengelola tag. Skrip ini termasuk pelanggar terburuk, bahkan pada situs konten sederhana.

Secara umum, perbaikannya adalah mengurangi pekerjaan ketika seseorang berinteraksi dan memecah pekerjaan besar menjadi bagian kecil agar browser dapat menangani interaksi di sela-selanya.

Ingin memahami mekanisme sebenarnya—tiga bagian latensi, perhitungan persentil ke-75, cara tepat memperbaiki setiap penyebab, dan kaitannya dengan SEO? Buka tab Lanjutan.

Ringkasnya — INP adalah Core Web Vital untuk daya tanggap. Metrik ini mengamati latensi semua klik, ketukan, dan interaksi papan ketik selama satu kunjungan, lalu melaporkan nilai pada persentil ke-75 (satu pencilan dibuang untuk setiap 50 interaksi)—bukan hanya input pertama seperti FID. Latensi interaksi = penundaan input + durasi pemrosesan + penundaan penyajian. Baik ≤ 200 ms dan buruk > 500 ms berdasarkan data lapangan pada p75. INP menggantikan FID pada 12 Maret 2024 (FID dihapus sepenuhnya dari berbagai alat pada September 2024). Perbaikannya adalah memecah tugas panjang, menyerahkan waktu ke utas utama dengan scheduler.yield(), mengurangi pekerjaan dalam penangan peristiwa, memperkecil DOM, dan menunda skrip pihak ketiga. INP adalah metrik lapangan; Total Blocking Time merupakan proksi lab, dan keduanya tidak selalu selaras.

Apa yang diukur INP—dan perbedaannya dari FID

Definisi Google sangat tepat: INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (terjemahan) “menilai daya tanggap keseluruhan sebuah halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi klik, ketuk, dan papan ketik yang terjadi sepanjang kunjungan pengguna ke halaman tersebut.”

Ungkapan “semua interaksi… sepanjang kunjungan” adalah inti metrik ini. INP merupakan metrik tingkat kunjungan, bukan metrik waktu pemuatan. Alasan Google adalah bahwa sebagian besar waktu pengguna di halaman berlangsung setelah halaman dimuat, sehingga daya tanggap saat digunakan lebih penting daripada kesan pertama saja.

Perbandingan dengan First Input Delay adalah cara paling jelas untuk memahaminya: “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (terjemahan) “FID hanya mengukur penundaan input pada interaksi pertama di sebuah halaman. INP meningkatkan cakupan FID dengan mengamati semua interaksi di halaman, mulai dari penundaan input hingga waktu yang diperlukan untuk menjalankan penangan peristiwa.” FID hanya mengukur satu hal dari satu interaksi—waktu tunggu sebelum penangan dimulai— serta mengabaikan lama penangan berjalan dan lama layar diperbarui. INP mengukur latensi penuh setiap interaksi.

Ada satu nuansa yang penting karena sering disalahpahami: INP bukan secara harfiah interaksi terburuk. Agar halaman tidak dihukum karena satu lonjakan acak, browser membuang satu pencilan untuk setiap 50 interaksi, lalu melaporkan nilai pada persentil ke-75 tampilan halaman. Pada kunjungan dengan sedikit interaksi, nilai itu adalah interaksi paling lambat; pada kunjungan yang sibuk, beberapa pencilan disisihkan.

Cakupan interaksi juga lebih sempit daripada dugaan banyak orang. Hanya klik, ketukan, dan penekanan tombol papan ketik yang diukur. Menggulir, mengarahkan penunjuk, dan memperbesar tampilan secara tegas dikecualikan. Satu gestur dapat memicu beberapa peristiwa—ketukan menghasilkan pointerdown, pointerup, dan click—yang dikelompokkan INP sebagai satu interaksi, bukan tiga. Dalam kelompok itu, INP mengambil durasi peristiwa individual terpanjang, bukan jumlah seluruh durasi. Jadi, pointerdown yang cepat diikuti click yang lambat tetap dilaporkan sebagai satu interaksi sebesar peristiwa lambat tersebut. Jika tidak ada interaksi yang memenuhi syarat selama kunjungan, halaman itu tidak memperoleh nilai INP.

Tiga bagian latensi interaksi

Latensi setiap interaksi terbagi menjadi tiga bagian berurutan. Ingat model ini karena setiap bagian mengarah pada perbaikan yang berbeda:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Penundaan input — waktu sebelum penangan peristiwa dapat mulai berjalan, biasanya karena utas utama sedang menyelesaikan tugas panjang.
2. Durasi pemrosesan — waktu yang diperlukan seluruh fungsi panggilan balik penangan peristiwa untuk dieksekusi.
3. Penundaan penyajian — waktu sejak penangan selesai hingga browser menggambar frame berikutnya di layar.

Build atribusi web-vitals menampilkan ketiganya (inputDelay, processingDuration, dan presentationDelay) agar Anda dapat melihat bagian yang mendominasi pada interaksi nyata. Menurut data Web Almanac 2024, penundaan penyajian sering menjadi bagian tunggal terbesar pada median. Namun, durasi pemrosesan biasanya memberi peluang optimasi terbesar karena bagian inilah yang membengkak pada halaman yang dibangun dengan buruk.

Ambang penilaian—dan batasan data lapangan p75

Google Search Central menyatakan targetnya dengan jelas—“an INP of less than 200 milliseconds” (terjemahan) “INP kurang dari dua ratus milidetik”—dan membingkai keseluruhan programnya sebagai: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (terjemahan) “Kami sangat menyarankan pemilik situs mencapai Core Web Vitals yang baik agar berhasil di Penelusuran.” Anggaran 200 ms benar-benar ketat karena browser menginginkan satu frame setiap ~16,7 ms pada 60 fps; seluruh pekerjaan penangan beserta perenderan harus muat di dalamnya.

Mengapa INP merupakan metrik lapangan dan data lab tidak cukup

Ini jebakan bagi banyak praktisi SEO: skor Lighthouse hijau tidak menjamin INP yang baik. Namun, pernyataan “Lighthouse tidak dapat mengukur INP” harus dibagi menjadi tiga kasus agar Anda tidak keliru membaca alat sendiri:

1. Lighthouse standar tanpa interaksi sama sekali tidak melaporkan INP. Alat ini hanya mengamati pemuatan halaman—tidak pernah mengeklik, mengetuk, atau mengetik— sehingga tidak ada interaksi yang bisa dihitung. Sebagai gantinya, Lighthouse memakai Total Blocking Time (TBT) sebagai proksi waktu pemuatan. Menurut Google, “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (terjemahan) “Karena TBT berkorelasi baik dengan INP, halaman dengan TBT tinggi cukup masuk akal sebagai petunjuk bahwa nilai INP mungkin tinggi selama pemuatan.” Kata kuncinya adalah “selama pemuatan.” TBT tidak menjelaskan interaksi yang memburuk sepuluh detik kemudian saat widget yang dimuat lambat berjalan; TBT adalah proksi, bukan pengganti atau rumus konversi.
2. Interaksi yang dijalankan secara manual atau sintetis—mengeklik tombol nyata di DevTools atau membuat skrip klik dalam alat lab—menghasilkan angka latensi bergaya INP yang nyata untuk satu interaksi tersebut. Ini berguna untuk mereproduksi masalah tertentu. Namun, hasilnya tetap satu alur terskrip pada satu perangkat, sehingga tidak mewakili campuran perangkat, pengguna, sasaran interaksi, dan seluruh umur kunjungan di lapangan. Menurut Google, nilainya “will be dependent on what interactions are performed during the measurement period,” (terjemahan) “akan bergantung pada interaksi yang dilakukan selama periode pengukuran”, sedangkan perilaku pengguna nyata terlalu beragam untuk diwakili satu pengujian lab.
3. Distribusi lapangan adalah bentuk INP yang sebenarnya. Karena itu, sumber otoritatifnya adalah data lapangan dari Chrome User Experience Report (CrUX), yang ditampilkan melalui PageSpeed Insights dan laporan Core Web Vitals Search Console. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (terjemahan) “Data lapangan adalah sumber informasi terbaik untuk memahami interaksi mana yang bermasalah bagi pengguna sebenarnya.”

Gunakan lab pada kasus 1 dan 2 untuk menemukan serta mereproduksi interaksi lambat; gunakan data lapangan pada kasus 3 untuk memastikan apakah masalah itu benar-benar menurunkan skor pengunjung nyata.

Mengapa skor INP Anda buruk

Hampir setiap masalah INP berawal dari utas utama yang terblokir ketika pengguna berinteraksi. Penyebab yang lazim adalah:

• Tugas panjang. Setiap tugas utas utama di atas 50 ms adalah tugas panjang; bagian di atas 50 ms merupakan “periode pemblokiran”. Selama tugas itu berjalan, interaksi tidak dapat ditangani. Ini penyebab tunggal terbesar.
• Penangan peristiwa yang berat. Terlalu banyak pekerjaan sinkron di dalam penangan klik atau input langsung memperpanjang durasi pemrosesan.
• Ukuran DOM besar. DOM yang lebih besar membutuhkan biaya perenderan lebih tinggi, sehingga memperpanjang penundaan input dan penyajian.
• Skrip pihak ketiga. Menurut Web Almanac, penyedia persetujuan, pengelola tag, analitik, dan widget obrolan termasuk pelanggar utama—bahkan pada situs konten sederhana. Inilah tempat pertama yang saya periksa pada halaman yang tidak saya bangun.
• JavaScript pascapemuatan. Halaman yang sudah dirender belum tentu selesai memuat; skrip yang dievaluasi setelah gambar pertama dapat memblokir interaksi awal.

Cara memperbaikinya

Berikut strateginya, kira-kira berdasarkan urutan dampak:

1. Pecah tugas panjang. Saran utama Google untuk penangan adalah “do as little work as possible in them.” (terjemahan) “lakukan sesedikit mungkin pekerjaan di dalamnya.” Pecah pekerjaan besar menjadi tugas yang lebih kecil agar browser dapat menyisipkan interaksi pengguna. Setelah tugas dipecah, “the browser can respond to higher-priority work much sooner — including user interactions.” (terjemahan) “browser dapat jauh lebih cepat merespons pekerjaan berprioritas lebih tinggi—termasuk interaksi pengguna.”

2. Serahkan waktu ke utas utama. Cara modern yang disarankan adalah scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() menjeda kode, memberi browser kesempatan menangani pekerjaan tertunda, lalu melanjutkan dengan prioritas agar tugas lain tidak mendahului kelanjutannya. Alternatif klasiknya adalah setTimeout(..., 0), yang tetap berfungsi tetapi menempatkan kode di belakang antrean tugas (dan browser menerapkan batas bawah 5 ms setelah beberapa panggilan bersarang). Satu hal yang perlu dihentikan adalah isInputPending(); Google kini menyatakan “we no longer recommend using this API.” (terjemahan) “kami tidak lagi menyarankan penggunaan API ini.” Lihat polanya di tab Skrip.

3. Kurangi pekerjaan dalam penangan peristiwa—tunda pekerjaan yang tidak kritis. Jalankan secara sinkron hanya pembaruan visual yang dibutuhkan frame berikutnya; letakkan pekerjaan lain seperti penyimpanan, pemeriksaan ejaan, analitik, dan penghitungan kata di belakang requestAnimationFrame + setTimeout atau penyerahan waktu. Pengguna segera melihat respons, sedangkan pencatatan berlangsung sesudahnya.

4. Hindari layout thrashing. Membaca properti tata letak segera setelah menulis gaya dalam tugas yang sama memaksa browser menghitung tata letak secara sinkron, padahal pekerjaan itu dapat dikelompokkan. Kelompokkan pembacaan terlebih dahulu, lalu penulisan.

5. Kurangi ukuran DOM. Pohon yang lebih kecil dirender lebih cepat. content-visibility dapat merender elemen di luar layar secara bertahap agar elemen tersebut tidak membebani pemuatan atau interaksi.

6. Audit dan tunda skrip pihak ketiga. Ini perbaikan SEO dengan daya ungkit terbesar pada situs nyata. Muat skrip persetujuan, tag, dan analitik secara bertahap; aktifkan setelah interaksi; atau pindahkan dari jalur kritis. Halaman konten yang tampak “ringan” dapat gagal INP hanya karena widget sematan yang berat.

Apakah INP memengaruhi peringkat?

Ya. INP adalah satu dari tiga Core Web Vitals, dan Core Web Vitals merupakan bagian dari sinyal pengalaman halaman Google. Namun, bobotnya ringan: pemecah seri antara hasil dengan relevansi sebanding, bukan faktor peringkat utama. Jangan mengejar skor INP sempurna dengan mengorbankan konten dan relevansi.

Ada dua poin SEO praktis. Pertama, seluler adalah angka yang sulit. Dalam Web Almanac 2024, ~74% situs seluler lulus INP dibandingkan ~97% di desktop. Karena Google mengindeks dengan pendekatan yang mengutamakan seluler, angka selulerlah yang penting. Kedua, situs kompleks berkinerja lebih buruk: hanya ~53% dari 1 000 situs teratas lulus karena halaman kaya fitur mengirim lebih banyak JavaScript yang memblokir utas utama. Pengembangan fitur berat meningkatkan risiko INP, dan halaman dengan banyak interaksi—produk, pembayaran, hasil pencarian, dan formulir—jauh lebih rentan daripada konten statis.

INP dibandingkan FID—gambaran lengkap

FID telah dihapus—dari Search Console pada hari peluncuran INP, lalu dari BigQuery/API CrUX pada September 2024. Jika suatu alat atau audit masih merujuk FID, rujukannya sudah usang.

Kasus tepi yang membuat data INP berbeda

Beberapa kekhasan siklus hidup menjelaskan sebagian besar pertanyaan “mengapa RUM saya tidak cocok dengan CrUX”:

• Tanpa interaksi, tidak ada INP. Jika kunjungan tidak pernah menerima klik, ketukan, atau penekanan tombol—atau hanya menerima gestur yang dikecualikan seperti menggulir dan mengarahkan penunjuk—tampilan halaman itu tidak memiliki nilai INP. Ini wajar pada halaman konten baca-saja, bukan kesalahan pemantauan.
• Iframe dihitung dalam metrik, tetapi JavaScript Anda tidak dapat melihat ke dalamnya. Interaksi di dalam iframe sematan seperti iklan, widget, atau formulir berkontribusi pada INP halaman. Namun, skrip RUM pihak pertama tidak dapat membaca peristiwa dari iframe lintas origin seperti metrik milik browser. Karena itu, CrUX dan RUM sesama origin dapat berbeda secara sah pada halaman dengan sematan pihak ketiga. Dokumentasikan kesenjangan ini alih-alih menganggap ketidaksesuaian RUM/lapangan sebagai kesalahan.
• Pemulihan cache mundur/maju mereset INP ke nol. Halaman yang dipulihkan dari bfcache, misalnya melalui tombol kembali, memulai penghitungan INP baru; interaksi sebelum navigasi tidak dibawa kembali.
• Tab berumur panjang dan berjalan di latar tetap perlu melaporkan. Tab dapat terbuka berjam-jam tanpa pernah benar-benar dibongkar, terutama di perangkat seluler yang dapat dihentikan sistem operasi. Karena itu, INP sebaiknya dicatat ketika halaman menjadi tersembunyi, bukan hanya saat dibongkar. RUM yang hanya mengirim data pada unload akan diam-diam kehilangan kunjungan tersebut.

Posisi INP dalam Core Web Vitals

INP adalah satu bagian dari Core Web Vitals, bersama Largest Contentful Paint untuk pemuatan dan Cumulative Layout Shift untuk stabilitas visual. Periksa INP di PageSpeed Insights dan laporan Search Console untuk data lapangan, lalu telusuri masalahnya di Lighthouse atau Chrome DevTools untuk data lab melalui proksi TBT. Seluruh data dasarnya berasal dari CrUX.

Ringkasan AI

Versi ringkas dari pembahasan Lanjutan:

• INP adalah Core Web Vital untuk daya tanggap. Metrik ini mengamati latensi semua klik, ketukan, dan interaksi papan ketik sepanjang kunjungan, lalu melaporkan nilai pada persentil ke-75 (satu pencilan dibuang untuk setiap 50 interaksi), bukan hanya input pertama seperti FID.
• Latensi = penundaan input + durasi pemrosesan + penundaan penyajian. Setiap bagian menunjuk ke perbaikan berbeda; durasi pemrosesan biasanya memberi peluang terbesar.
• Ambang (lapangan, p75): baik ≤ 200 ms, perlu ditingkatkan ≤ 500 ms, buruk > 500 ms.
• Hanya klik, ketukan, dan papan ketik yang dihitung. Menggulir, mengarahkan penunjuk, dan memperbesar tampilan dikecualikan; beberapa peristiwa dalam satu gestur dikelompokkan menjadi satu interaksi.
• INP menggantikan FID pada 12 Maret 2024 (FID dihapus sepenuhnya dari alat pada September 2024). FID hanya menghitung penundaan input pada interaksi pertama.
• INP adalah metrik lapangan, dan “Lighthouse tidak dapat mengukurnya” memiliki tiga kasus: Lighthouse standar tanpa interaksi tidak melaporkan INP dan memakai Total Blocking Time sebagai proksi pemuatan; interaksi lab yang dijalankan manual memang menghasilkan latensi satu interaksi, tetapi tidak mewakili populasi lapangan; hanya data lapangan CrUX, PageSpeed Insights, dan Search Console yang otoritatif.
• Penyebab: tugas panjang (>50 ms), penangan peristiwa berat, DOM besar, dan terutama skrip pihak ketiga seperti persetujuan, pengelola tag, analitik, serta obrolan.
• Perbaikan: pecah tugas panjang, serahkan waktu dengan scheduler.yield() (alternatif setTimeout; isInputPending() tidak lagi disarankan), kurangi pekerjaan dalam penangan, hindari layout thrashing, perkecil DOM, dan tunda skrip pihak ketiga.
• Kasus tepi: tanpa interaksi yang memenuhi syarat tidak ada nilai INP; interaksi iframe dihitung tetapi skrip RUM sesama origin tidak dapat melihat ke dalamnya; pemulihan bfcache mereset INP; tab berumur panjang atau di latar harus melapor saat tersembunyi, bukan hanya saat dibongkar.
• SEO: sinyal pemeringkatan berbobot ringan. Seluler (~74% lulus dibandingkan ~97% desktop) adalah angka penting dalam pengindeksan yang mengutamakan seluler; halaman dengan banyak interaksi paling rentan.

Dokumentasi resmi

Dokumentasi sumber primer dari Google dan tim Chrome.

web.dev—rujukan INP

• Interaction to Next Paint (INP) — definisi utama: hal yang diukur, tiga bagian latensi, jenis interaksi, dan ambang.
• Mengoptimalkan Interaction to Next Paint — panduan optimasi: mengurangi pekerjaan dalam penangan, menunda pekerjaan nonkritis, layout thrashing, ukuran DOM, dan content-visibility.
• Interaction to Next Paint resmi menjadi Core Web Vital — tulisan peluncuran 12 Maret 2024 oleh Jeremy Wagner dan Rick Viscomi; jadwal penghentian FID.
• First Input Delay (FID) — metrik yang dihentikan; hal yang diukurnya dan alasan penggantiannya.
• Metrik daya tanggap baru: kami meminta masukan Anda — keterbatasan rancangan FID dan peningkatan pada INP.
• Mengoptimalkan tugas panjang — definisi tugas panjang 50 ms, scheduler.yield(), alternatif setTimeout, dan alasan isInputPending() tidak lagi disarankan.
• Evaluasi skrip dan tugas panjang — TBT sebagai proksi INP dan panduan ukuran skrip.
• Menemukan interaksi lambat di lapangan — build atribusi web-vitals dan API Long Animation Frames (LoAF).

Chrome / Google Search

• Rujukan fitur performa Chrome DevTools — jalur Interactions, Live Metrics, dan peringatan 200 ms.
• Catatan rilis CrUX — mengonfirmasi penghapusan FID dari BigQuery/API pada September 2024.
• Core Web Vitals dan hasil Google Search — INP sebagai bagian sinyal pengalaman halaman serta target ≤ 200 ms.

Kutipan dari sumber

Pernyataan resmi dari Google dan tim Chrome. Setiap tautan langsung menuju bagian yang dikutip pada halaman sumber.

Hal yang diukur INP dan perbedaannya dari FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (terjemahan) “INP adalah metrik Core Web Vitals yang menilai daya tanggap keseluruhan halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi klik, ketuk, dan papan ketik sepanjang kunjungan pengguna ke halaman.” — web.dev, Interaction to Next Paint (INP). Buka kutipan
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (terjemahan) “FID hanya mengukur penundaan input pada interaksi pertama di halaman. INP meningkatkan cakupan FID dengan mengamati semua interaksi, mulai dari penundaan input hingga waktu menjalankan penangan peristiwa.” Buka kutipan
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (terjemahan) “First Input Delay (FID) bukan lagi Core Web Vital dan telah digantikan oleh metrik Interaction to Next Paint (INP).” — web.dev, First Input Delay (FID). Buka kutipan

Peralihan FID → INP

• “FID will be deprecated.” (terjemahan) “FID akan dihentikan.” — Jeremy Wagner dan Rick Viscomi, blog web.dev, Interaction to Next Paint resmi menjadi Core Web Vital. Buka kutipan
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (terjemahan) “FID akan dihapus dari Google Search Console segera setelah INP menjadi Core Web Vital pada dua belas Maret.” Buka kutipan

Tugas panjang—penyebab utama

• “Any task that takes longer than 50 milliseconds is a long task.” (terjemahan) “Setiap tugas yang berlangsung lebih dari lima puluh milidetik adalah tugas panjang.” — web.dev, Mengoptimalkan tugas panjang. Buka kutipan

Data lapangan adalah sumber utama

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (terjemahan) “Data lapangan adalah sumber informasi terbaik untuk memahami interaksi mana yang bermasalah bagi pengguna sebenarnya.” — web.dev, Menemukan interaksi lambat di lapangan. Buka kutipan

Google Search

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (terjemahan) “Kami sangat menyarankan pemilik situs mencapai Core Web Vitals yang baik agar berhasil di Penelusuran.” — Google Search Central, Core Web Vitals dan hasil Google Search. Sumber

Daftar periksa perbaikan INP

Kerjakan dari atas ke bawah; butir teratas cenderung paling banyak mengubah angka:

• Ambil INP lapangan dari PageSpeed Insights atau laporan CWV Search Console, bukan hanya skor lab, dan periksa seluler secara terpisah.
• Identifikasi interaksi lambat dengan build atribusi web-vitals atau jalur Interactions di Chrome DevTools yang menandai nilai di atas 200 ms.
• Temukan dan pecah tugas panjang (apa pun di atas 50 ms pada utas utama).
• Serahkan waktu ke utas utama di dalam perulangan panjang dengan scheduler.yield() dan alternatif setTimeout(..., 0). Hentikan penggunaan isInputPending().
• Di setiap penangan, jalankan secara sinkron hanya pembaruan yang kritis untuk perenderan; tunda penyimpanan, validasi, pemeriksaan ejaan, dan analitik di balik rAF + setTimeout.
• Periksa layout thrashing, yaitu membaca tata letak tepat setelah menulis gaya dalam tugas yang sama. Kelompokkan pembacaan, lalu penulisan.
• Audit skrip pihak ketiga seperti persetujuan, pengelola tag, analitik, dan obrolan. Tunda, muat bertahap, atau aktifkan setelah interaksi; ini biasanya menghasilkan peningkatan tunggal terbesar.
• Kurangi ukuran DOM dan terapkan content-visibility pada bagian di luar layar.
• Tunda atau pecah kode JavaScript nonkritis agar skrip pascapemuatan tidak memblokir interaksi awal.
• Ukur ulang di lapangan setelah penerapan. CrUX memakai jendela berjalan 28 hari, sehingga skornya berubah perlahan.

INP dibandingkan FID—lembar ringkas

Fakta singkat

• Ambang (lapangan, p75): Baik ≤ 200 ms · Perlu ditingkatkan ≤ 500 ms · Buruk > 500 ms.
• Dihitung: klik, ketukan, papan ketik. Dikecualikan: gulir, arahkan penunjuk, perbesar.
• Latensi = penundaan input + durasi pemrosesan + penundaan penyajian.
• Tugas panjang = tugas utas utama > 50 ms.
• Proksi lab: Total Blocking Time—berkorelasi, tetapi hanya mencerminkan pemblokiran saat pemuatan. Sumber otoritatif adalah data lapangan CrUX.
• Tingkat kelulusan seluler (~74%) jauh di bawah desktop (~97%), dan selulerlah yang penting.

Menyerahkan waktu ke utas utama

Saat menjalankan perulangan panjang, misalnya merender daftar besar atau memproses data setelah klik, kembalikan kendali secara berkala kepada browser agar interaksi pengguna yang tertunda dapat dilayani. API modernnya adalah scheduler.yield(); gunakan setTimeout sebagai alternatif jika API itu tidak didukung.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Beberapa catatan:

• scheduler.yield() mengembalikan promise yang selesai pada tugas mendatang, dan kelanjutannya diprioritaskan sehingga tugas lain dalam antrean tidak mendahului kode yang dilanjutkan.
• setTimeout(..., 0) berfungsi di semua tempat tetapi mendorong kelanjutan ke belakang antrean (browser menerapkan batas bawah ~5 ms setelah beberapa panggilan bersarang).
• Jangan gunakan isInputPending(); menurut Google, “no longer recommend[s] using this API.” (terjemahan) “tidak lagi menyarankan penggunaan API ini.”

Menunda pekerjaan nonkritis dalam penangan

Jalankan hanya pekerjaan yang dibutuhkan frame berikutnya; letakkan sisanya setelah browser menggambar.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Alat untuk mengukur dan memperbaiki INP

Lapangan (otoritatif—nilai inilah yang dinilai Google)

• PageSpeed Insights — INP lapangan CrUX untuk URL/origin, dipisahkan antara seluler dan desktop, ditambah satu pemeriksaan diagnostik lab.
• Search Console—laporan Core Web Vitals — status INP di seluruh URL Anda, yang dikelompokkan berdasarkan masalah dalam data lapangan.
• CrUX — kumpulan data Chrome User Experience Report yang mendasarinya dan juga dapat dikueri melalui API CrUX atau BigQuery.

Lab / penelusuran masalah

• Chrome DevTools—panel Performance — jalur Interactions menghitung penundaan input, pemrosesan, dan penyajian setiap interaksi serta menandai nilai di atas 200 ms; Live Metrics diperbarui ketika Anda berinteraksi.
• Lighthouse — tidak mengukur INP secara langsung; alat ini melaporkan Total Blocking Time sebagai proksi lab.

Pemantauan pengguna nyata (RUM)

• Pustaka JavaScript web-vitals — onINP() menyediakan nilai; build atribusi (web-vitals/attribution) menampilkan inputDelay, processingDuration, presentationDelay, pemilih interactionTarget, dan entri LoAF sehingga Anda dapat melihat skrip serta elemen yang menyebabkan interaksi lambat. Apa pun RUM yang digunakan, dokumentasikan tingkat sampel dan cakupan atribusinya. Angka RUM tanpa konteks itu tidak dapat dibandingkan dengan p75 lapangan CrUX, dan RUM tidak dapat melihat ke dalam iframe lintas origin seperti metrik agregat. Lihat Kasus tepi pada tab Lanjutan.

Cara alat-alat tersebut memperoleh skor

Contoh langsung metrik yang dijelaskan halaman ini: layanan kecepatan halaman dan pemantauan terkenal diperingkat berdasarkan INP seluler pengguna nyatanya sendiri dari data lapangan Chrome UX Report:

Perbaikan INP yang biasanya meleset dari sasaran

Hanya mengoptimalkan interaksi pertama

INP mengevaluasi interaksi sepanjang kunjungan, bukan hanya input pertama. Uji menu, pencarian, filter, formulir, dan kontrol berulang lain sebelum menyimpulkan halaman sudah responsif.

Menganggap Total Blocking Time sebagai hasil akhir

TBT adalah proksi lab yang berguna karena menampilkan tugas panjang pada utas utama, tetapi TBT bukan INP lapangan. Gunakan TBT untuk menemukan kandidat masalah, lalu verifikasi interaksi sebenarnya dengan data lapangan atau rekaman interaksi.

Memindahkan seluruh pekerjaan ke satu fungsi panggilan balik tertunda

Menunda satu blok besar hanya dapat memindahkan waktu pembekuan. Pecah pekerjaan menjadi tugas lebih kecil dan serahkan waktu agar browser dapat menggambar di antaranya.

Menghapus umpan balik visual untuk mempersingkat penangan

Kontrol yang bekerja tanpa menampilkan respons tetap terasa rusak. Render perubahan keadaan langsung terlebih dahulu, lalu tunda pekerjaan lanjutan yang tidak kritis.

Mendiagnosis INP dengan model latensi tiga bagian

Setiap interaksi lambat memiliki tiga tempat yang perlu diperiksa:

1. Penundaan input: peristiwa harus menunggu karena pekerjaan sebelumnya masih berjalan di utas utama. Audit tugas panjang dan JavaScript pihak ketiga sebelum penangan dimulai.
2. Durasi pemrosesan: penangan peristiwa mengerjakan terlalu banyak hal. Kurangi pekerjaan sinkron, pecah perulangan, dan tunda apa pun yang tidak dibutuhkan frame berikutnya.
3. Penundaan penyajian: gaya, tata letak, atau penggambaran berlangsung terlalu lama setelah penangan selesai. Kurangi kompleksitas DOM dan hindari pemaksaan perhitungan tata letak berulang.

Mulailah dari fase terbesar dalam rekaman. Rekam kembali interaksi yang sama setelah setiap perubahan agar penangan yang lebih cepat tidak menyembunyikan hambatan penyajian baru.

Membuktikan perubahan INP memperbaiki interaksi

Uji penyerahan waktu oleh penangan

Pengujian: rekam interaksi sasaran di panel Performance sebelum dan sesudah memecah pekerjaan panjang atau menyerahkan waktu. Hasil yang diharapkan: rentang pemrosesan interaksi menyusut atau terpisah oleh satu penggambaran. Arti kegagalan: pekerjaan mahal berada di tempat lain atau masih berjalan sinkron. Jendela pemantauan: langsung dalam rekaman berulang. Pemicu pembatalan: kontrol diperbarui tidak berurutan, kehilangan keadaan, atau menimbulkan kesalahan input baru.

Uji penyajian

Pengujian: periksa pekerjaan gaya, tata letak, dan penggambaran pada rekaman yang sama setelah penangan peristiwa. Hasil yang diharapkan: gambar berikutnya muncul lebih cepat tanpa tugas tata letak yang lebih besar. Arti kegagalan: ukuran DOM atau tata letak paksa masih menjadi hambatan. Jendela pemantauan: langsung dalam rekaman lab. Pemicu pembatalan: respons visual menjadi tidak lengkap atau tidak stabil.

Konfirmasi lapangan

Pengujian: bandingkan atribusi onINP() setelah rilis untuk interaksi dan templat yang diubah dengan nilai dasarnya. Hasil yang diharapkan: p75 INP membaik dan elemen sasaran tidak lagi mendominasi peristiwa lambat. Arti kegagalan: kasus lab tidak mewakili perangkat atau perjalanan nyata. Jendela pemantauan: RUM saat kunjungan masuk; CrUX dalam jendela berjalan 28 hari. Pemicu pembatalan: daya tanggap atau penyelesaian interaksi terus memburuk setelah penerapan.

Metrik INP yang layak dipantau

INP pengguna nyata pada p75

Metrik: INP persentil ke-75 menurut templat dan kelas perangkat. Maknanya: apakah kunjungan nyata yang umum tetap responsif sepanjang perjalanan. Cara mengambil: CrUX, PageSpeed Insights, atau RUM web-vitals. Tolok ukur / rentang realistis: 200 ms atau kurang tergolong baik; di atas 500 ms tergolong buruk. Frekuensi: pantau setelah rilis JavaScript dan tinjau tren lapangan berjalan setiap bulan.

Tingkat interaksi lambat

Metrik: persentase interaksi terukur di atas 200 ms yang dikelompokkan menurut sasaran. Maknanya: kontrol mana yang paling banyak menimbulkan penundaan terlihat oleh pengguna, bahkan ketika p75 tingkat halaman lulus. Cara mengambil: build atribusi web-vitals atau data Event Timing dalam RUM. Tolok ukur / rentang realistis: tetapkan nilai dasar per perjalanan dan kurangi pelanggar dengan volume tertinggi. Frekuensi: setiap minggu untuk templat yang menyerupai aplikasi.

Proporsi fase latensi

Metrik: penundaan input, durasi pemrosesan, dan penundaan penyajian untuk interaksi lambat. Maknanya: apakah penjadwalan, kode penangan, atau perenderan menjadi batas utama. Cara mengambil: rekaman DevTools dan atribusi INP. Tolok ukur / rentang realistis: tidak ada pembagian universal yang selalu sehat; bandingkan setiap fase dengan nilai dasarnya sendiri dan ambang baik total 200 ms. Frekuensi: selama setiap investigasi performa terfokus.

Sumber daya yang layak dibaca

Google / Chrome (rujukan utama)

• Interaction to Next Paint (INP) — mulai dari sini.
• Mengoptimalkan Interaction to Next Paint — langkah perbaikan.
• Mengoptimalkan tugas panjang — penyerahan waktu dan scheduler.yield().
• Menemukan interaksi lambat di lapangan — penelusuran LoAF dan atribusi.
• INP menjadi Core Web Vital — peluncuran 12 Maret 2024.

Data

• Web Almanac 2024—Performa — tingkat kelulusan INP dunia nyata dan median tiap subbagian.

Dari industri yang lebih luas

• INP—Dokumentasi Web MDN — entri rujukan MDN untuk memeriksa dukungan browser dan definisi metrik di luar dokumentasi Google.
• Scheduler API: scheduler.yield()—MDN — tabel dukungan browser dan detail spesifikasi untuk mekanisme penyerahan waktu utama.
• PerformanceEventTiming—MDN — API browser dasar yang dibaca INP, berguna saat memeriksa data waktu peristiwa mentah.
• Long Animation Frames API—Status Fitur Chrome — pelacakan dukungan LoAF, API yang mendukung atribusi INP dalam pustaka web-vitals.
• Topik INP di SEL — liputan industri tentang pembaruan INP, hasil pengujian, dan peralihan praktis dari FID.

Statistik yang layak dikutip

• ~74% situs seluler dibandingkan ~97% desktop lulus INP (2024). Seluler jauh lebih sulit, dan karena Google mengutamakan seluler saat mengindeks, angka itulah yang penting bagi SEO. Web Almanac 2024
• Hanya ~53% dari 1 000 situs teratas lulus INP. Situs kaya fitur mengirim lebih banyak JavaScript yang memblokir utas utama, sehingga situs terbesar sering justru berkinerja lebih buruk. Web Almanac 2024
• Tugas panjang = > 50 ms. Setiap waktu di atas 50 ms pada utas utama memblokir respons browser terhadap interaksi; inilah mekanisme langsung di balik INP buruk. web.dev—Mengoptimalkan tugas panjang
• Median subbagian (2024): penundaan penyajian ~36 ms sering menjadi kontributor tunggal terbesar pada median, sedangkan penundaan input dan waktu pemrosesan berdekatan pada p75. Data ini membantu menentukan bagian mana yang harus ditangani. Web Almanac 2024

Video

• Google Chrome Developers (YouTube) — penjelasan Core Web Vitals dan INP dari tim Chrome, termasuk panduan mendiagnosis interaksi lambat di DevTools. Kanal

Uji pemahaman Anda: Interaction to Next Paint

Lima pertanyaan singkat tentang daya tanggap dan diagnosis INP. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan