Website yang cepat bukan hanya website yang segera menampilkan halaman. Pengguna juga berharap tombol langsung merespons, menu tidak tersendat, dan perubahan tampilan muncul tanpa jeda yang mengganggu. Inilah alasan Interaction to Next Paint atau INP penting diperhatikan: metrik ini mengukur seberapa cepat halaman menanggapi interaksi pengguna selama kunjungan, bukan hanya saat halaman pertama kali dibuka.
INP merupakan salah satu Core Web Vitals. Nilai INP yang dianggap baik adalah 200 milidetik atau kurang, sedangkan di atas 500 milidetik masuk kategori buruk. Penilaiannya biasanya dilihat pada persentil ke-75, dipisahkan antara perangkat mobile dan desktop. Dengan kata lain, targetnya bukan membuat satu perangkat pengembang terasa cepat, melainkan memastikan sebagian besar pengguna mendapatkan respons yang baik.
Masalahnya sering tidak terlihat dari skor kecepatan awal. Halaman dapat menampilkan konten utama dengan cepat, tetapi tombol pencarian, filter produk, modal, atau formulir baru merespons setelah beberapa ratus milidetik. Bagi pengguna, pengalaman ini terasa seperti tombol macet.
INP mengukur bagian mana dari interaksi?
Setiap interaksi memiliki tiga bagian utama. Pertama, input delay, yaitu waktu sebelum kode penanganan interaksi mulai berjalan. Kedua, processing duration, yaitu waktu yang dibutuhkan JavaScript untuk menjalankan pekerjaan setelah klik atau sentuhan diterima. Ketiga, presentation delay, yaitu waktu sampai browser menampilkan frame berikutnya yang memperlihatkan hasil interaksi.
Misalnya, pengguna menekan tombol “Tampilkan Filter”. Browser mungkin sedang menjalankan JavaScript lain yang berat sehingga klik harus menunggu. Setelah itu, kode tombol membuka panel, menghitung ulang daftar produk, dan mengubah banyak elemen HTML. Jika semua pekerjaan dilakukan dalam satu rangkaian panjang, browser belum sempat menggambar perubahan ke layar. Pengguna melihat tombol ditekan, tetapi panel baru muncul belakangan.
Menurut dokumentasi web.dev, INP memperhitungkan keseluruhan jeda tersebut dan mengamati interaksi sepanjang siklus hidup halaman. Jadi, mempercepat tampilan awal saja belum tentu menyelesaikan masalah responsivitas.
Kenapa JavaScript sering menjadi penyebab?
Browser memiliki main thread, jalur kerja utama yang menangani banyak tugas penting seperti memproses JavaScript, menghitung layout, dan menyiapkan tampilan. Jika jalur ini sibuk mengerjakan tugas panjang, interaksi pengguna harus menunggu.
Penyebab yang umum antara lain:
- File JavaScript terlalu besar dan harus diproses saat halaman mulai digunakan.
- Event handler melakukan terlalu banyak pekerjaan sekaligus.
- Perubahan DOM dalam jumlah besar setelah pengguna berinteraksi.
- Kode membaca ukuran elemen setelah mengubah style dalam tugas yang sama, sehingga memicu layout ulang secara sinkron.
- Timer berulang seperti
setInterval()menjalankan pekerjaan berat ketika pengguna sedang mencoba berinteraksi.
Ini sebabnya menambah CPU server atau memasang cache baru tidak selalu memperbaiki INP. Caching membantu mengurangi waktu pengiriman halaman, tetapi tidak otomatis membuat JavaScript di browser menjadi lebih ringan.
Cara menemukan interaksi yang paling lambat
Jangan mulai dengan menebak. Cari dulu interaksi yang paling sering bermasalah dan ukur bagian mana yang paling lama.
- Periksa data pengguna nyata. Gunakan laporan Core Web Vitals, PageSpeed Insights, atau pengukuran berbasis web-vitals untuk melihat apakah masalah terutama terjadi di mobile atau desktop. Data lapangan membantu menunjukkan kondisi perangkat dan jaringan yang benar-benar dipakai pengunjung.
- Reproduksi masalah di Chrome DevTools. Buka panel Performance, mulai perekaman, lalu lakukan tindakan seperti membuka menu, memakai filter, atau mengirim formulir. Perhatikan tugas panjang, aktivitas scripting, dan bagian yang bertanda Layout atau Recalculate Style.
- Uji interaksi yang bermakna. Jangan hanya menguji halaman beranda. Halaman detail produk, pencarian, dashboard, checkout, dan editor biasanya memiliki interaksi yang lebih berat.
- Bandingkan perangkat. Interaksi yang terasa cepat di laptop pengembang bisa lambat di ponsel kelas menengah. Simulasikan CPU dan jaringan yang lebih terbatas agar hasil pengujian lebih realistis.
Perbaikan praktis yang bisa dicoba
1. Kerjakan hanya yang dibutuhkan untuk frame berikutnya
Ketika pengguna mengklik tombol, prioritaskan perubahan visual yang harus segera terlihat. Pekerjaan lain—seperti menyimpan log, menghitung statistik, atau memperbarui elemen sekunder—dapat dijadwalkan setelah tampilan utama berubah.
button.addEventListener('click', () => {
panel.classList.add('is-open');
requestAnimationFrame(() => {
setTimeout(() => {
simpanLogAktivitas();
perbaruiDataTambahan();
}, 0);
});
});Pola ini bukan resep untuk semua kasus. Gunakan dengan hati-hati, terutama jika pekerjaan yang ditunda sebenarnya dibutuhkan sebelum pengguna dapat melanjutkan.
2. Pecah pekerjaan besar menjadi tugas kecil
Jika event handler harus memproses banyak data, jangan memaksa seluruh pekerjaan selesai dalam satu tugas panjang. Pecah pekerjaan menjadi beberapa bagian agar browser memiliki kesempatan untuk memproses input lain dan menggambar tampilan.
Pada daftar produk yang panjang, misalnya, tampilkan hasil awal terlebih dahulu lalu proses bagian berikutnya secara bertahap. Untuk aplikasi besar, pertimbangkan virtualisasi daftar, yaitu hanya merender item yang sedang terlihat di layar.
3. Hindari pola baca-tulis layout yang berulang
Masalah yang sering muncul adalah kode mengubah style lalu langsung membaca ukuran elemen, kemudian mengubah style lagi. Pola ini dapat memaksa browser menghitung ulang layout berkali-kali. Kelompokkan pembacaan ukuran terlebih dahulu, lalu lakukan perubahan tampilan setelahnya.
Periksa kode yang sering menggunakan properti seperti offsetWidth, offsetHeight, atau getBoundingClientRect() di antara perubahan class dan style. Tidak semua penggunaan properti tersebut bermasalah, tetapi rangkaian baca-tulis yang berulang patut dicurigai.
4. Kurangi pekerjaan saat halaman mulai aktif
Halaman yang sudah menampilkan konten belum tentu selesai bekerja. JavaScript masih dapat diparse, dikompilasi, dan dijalankan setelah tampilan awal muncul. Jika pengguna langsung menekan tombol ketika proses startup masih berlangsung, input delay dapat meningkat.
Mulailah dengan menghapus kode yang tidak diperlukan di halaman tersebut. Setelah itu, gunakan pemisahan bundle berdasarkan halaman atau fitur, tunda modul yang belum dibutuhkan, dan evaluasi kembali script pihak ketiga yang berjalan otomatis.
Apa artinya bagi pemilik website?
INP bukan sekadar angka untuk laporan teknis. Ia menunjukkan apakah website terasa siap diajak berinteraksi. Toko online dengan filter yang lambat dapat membuat pengguna berhenti mencari produk. Formulir yang terlambat merespons bisa membuat orang mengklik tombol berkali-kali. Dashboard yang tersendat membuat pekerjaan terasa lebih berat daripada seharusnya.
Prioritas perbaikannya sebaiknya mengikuti alur bisnis. Cari interaksi yang paling dekat dengan pendaftaran, pencarian, pembelian, atau pekerjaan utama pengguna. Setelah itu, ukur ulang dengan data lapangan—bukan hanya satu kali pengujian di laptop.
Yang bisa dilakukan sekarang
- Catat tiga interaksi paling penting di website.
- Uji ketiganya pada perangkat mobile dengan CPU terbatas.
- Gunakan DevTools Performance untuk mencari tugas panjang.
- Pisahkan pekerjaan visual yang mendesak dari pekerjaan tambahan.
- Ukur kembali INP setelah setiap perubahan, bukan setelah sepuluh perubahan sekaligus.
Website yang responsif tidak selalu membutuhkan arsitektur baru. Sering kali, hasil besar datang dari keputusan kecil: menghapus pekerjaan yang tidak perlu, merender lebih sedikit elemen, dan memberi browser kesempatan untuk menggambar perubahan lebih cepat.
Rujukan teknis: panduan optimasi INP di web.dev, dokumentasi Web Vitals, dan metodologi metrik Chrome UX Report.
Sumber & bacaan lebih lanjut
- Optimize Interaction to Next Paint
- Web Vitals
- Optimize input delay
- Chrome UX Report metrics methodology
– Rio Yotto @rioyotto