Interaksi ke Paint Berikutnya (INP)

Interaction to Next Paint mengukur seberapa cepat halaman merespons secara visual terhadap input pengguna, melaporkan nilai yang mewakili latensi interaksi terburuk yang dialami selama kunjungan. Metrik ini menggantikan First Input Delay sebagai metrik responsivitas Core Web Vitals pada Maret 2024, dan perubahannya signifikan: di mana ukuran lama hanya menangkap penundaan sebelum pemrosesan dimulai pada interaksi pertama, ukuran ini mengukur durasi penuh dari input hingga pemrosesan sampai frame berikutnya ditampilkan, di semua interaksi dalam sesi tersebut.

Perbedaan itu penting karena metrik sebelumnya terlalu menguntungkan banyak situs. Sebuah halaman dapat mencatat penundaan input pertama yang sangat baik tetapi tetap lambat sepanjang waktu, karena ukuran tersebut mengabaikan berapa lama penanganan peristiwa berjalan dan berapa lama browser kemudian membutuhkan waktu untuk merender hasilnya, dan karena hanya melihat satu interaksi. Situs yang tampak responsif di bawah ukuran lama seringkali tidak responsif di bawah ukuran baru, terutama aplikasi satu halaman dan antarmuka apa pun dengan logika sisi klien yang kompleks.

Nilai yang dilaporkan diperoleh dari interaksi terlama yang diamati, dengan memperhitungkan nilai ekstrem pada halaman dengan banyak interaksi, dan ambang batas yang dipublikasikan Google menganggap 200 milidetik atau kurang sebagai nilai yang baik pada persentil ke-75 dari pengalaman pengguna sebenarnya. Karena mencakup seluruh jalur dari input hingga rendering, skor yang buruk dapat berasal dari beberapa titik: tugas panjang pada thread utama yang menghalangi browser untuk menangani peristiwa, penangan peristiwa yang melakukan pekerjaan berlebihan secara sinkron, thrashing tata letak yang disebabkan oleh pembacaan dan penulisan gaya secara bergantian, dan rendering yang mahal setelah perubahan status.

Diagnosis biasanya mengarah pada eksekusi JavaScript daripada kondisi jaringan, yang membedakan metrik ini dari pengukuran pemuatan. Penyebab umum meliputi bundel monolitik besar yang dieksekusi pada thread utama, skrip pihak ketiga yang menjalankan pekerjaan sembarangan selama interaksi, rendering ulang framework yang menyentuh lebih banyak bagian pohon daripada yang dibutuhkan perubahan, dan handler yang melakukan komputasi sinkron yang dapat ditunda atau dipindahkan dari thread utama. Tugas yang panjang adalah mekanisme yang mendasarinya dalam sebagian besar kasus, karena browser tidak dapat merespons input saat tugas sedang berjalan.

Perbaikan dilakukan setelah diagnosis. Memecah tugas panjang menjadi bagian-bagian yang lebih kecil dengan penundaan eksplisit memungkinkan browser menangani input di antara bagian-bagian tersebut. Menunda pekerjaan yang tidak penting hingga setelah pembaruan visual, sehingga pengguna melihat respons secara langsung, mengatasi pola yang paling umum. Mengurangi jumlah JavaScript yang dikirim, mengaudit skrip pihak ketiga untuk biaya thread utama, memvirtualisasi daftar panjang, dan memindahkan komputasi berat ke worker masing-masing mengatasi penyebab spesifik. Memberikan umpan balik visual langsung untuk operasi yang lambat tidak meningkatkan nilai yang diukur tetapi mengubah cara penundaan dialami.

Skrip pihak ketiga memerlukan pengawasan khusus karena sering menjadi penyebab masalah dan berada di luar kendali langsung tim. Widget obrolan, pengelola persetujuan, pustaka analitik, alat personalisasi, dan skrip iklan semuanya berjalan pada thread utama dan dapat menggunakannya tepat pada saat pengunjung mencoba berinteraksi. Mengaudit biaya thread utama dari setiap pihak ketiga, idealnya dengan mengukur kinerja halaman dengan dan tanpa pihak ketiga tersebut, menghasilkan daftar konkret tentang biaya yang dikeluarkan setiap vendor dalam hal responsivitas. Angka tersebut membuat pertimbangan untung rugi dapat didiskusikan dengan tim yang meminta setiap alat, yang biasanya merupakan jalur yang lebih produktif daripada mencoba mengoptimalkan kode aplikasi di sekitar skrip yang menghabiskan sebagian besar anggaran yang tersedia.

Karena metrik ini didorong oleh kode aplikasi dan bukan oleh pengiriman aset, memperbaikinya biasanya membutuhkan pekerjaan rekayasa dan bukan konfigurasi. Dalam praktiknya, metrik ini berada di batas antara kinerja web ke pengembangan produkDan hal ini sangat berdampak pada antarmuka perdagangan interaktif dan pemesanan, di mana penyaringan, konfigurasi, dan interaksi keranjang belanja yang tidak responsif menyebabkan pengabaian yang muncul dalam analitik sebagai penurunan biasa tanpa sebab yang jelas.