Kecepatan dan responsivitas halaman web menjadi faktor penting dalam menentukan kenyamanan pengunjung saat berinteraksi dengan elemen antarmuka, seperti tombol navigasi, formulir, atau menu dropdown. Ketika pengguna mengklik atau mengetuk elemen di layar, mereka mengharapkan umpan balik visual yang cepat tanpa jeda yang mengganggu.

Google mengukur responsivitas interaksi tersebut melalui metrik Interaction to Next Paint (INP). Artikel ini menguraikan konsep dasar INP, mekanisme pengukurannya, metode teknis untuk mengelola beban pemrosesan skrip JavaScript, serta cara memantau performa halaman menggunakan data lapangan dan simulasi laboratorium.

Mengenal Metrik Core Web Vitals dan Peran INP pada Website

Berdasarkan dokumentasi resmi PageSpeed Insights, Core Web Vitals adalah sekumpulan sinyal performa umum yang penting untuk semua pengalaman web. Inisiatif ini berfokus pada tiga aspek utama pengalaman pengguna: kecepatan pemuatan konten terbesar, stabilitas visual tata letak, dan responsivitas terhadap interaksi pengguna.

Tiga metrik utama yang menyusun Core Web Vitals meliputi:

• Largest Contentful Paint (LCP): Mengukur durasi pemuatan elemen konten visual terbesar pada layar.
• Cumulative Layout Shift (CLS): Mengukur stabilitas tata letak visual untuk mendeteksi pergeseran elemen yang tidak terduga.
• Interaction to Next Paint (INP): Mengukur responsivitas halaman secara menyeluruh terhadap semua interaksi klik, ketukan, atau penekanan tombol keyboard sepanjang kunjungan pengguna.

Untuk mengklasifikasikan kualitas pengalaman pengguna, Google menetapkan ambang batas evaluasi data lapangan (field data) yang dinilai pada persentil ke-75 dari distribusi kunjungan:

Metrik	Kategori Baik	Perlu Peningkatan	Kategori Buruk
INP	0 md hingga 200 md	Lebih dari 200 md hingga 500 md	Lebih dari 500 md
LCP	0 md hingga 2.500 md	Lebih dari 2.500 md hingga 4.000 md	Lebih dari 4.000 md
CLS	0 hingga 0,1	Lebih dari 0,1 hingga 0,25	Lebih dari 0,25
FCP	0 md hingga 1.800 md	Lebih dari 1.800 md hingga 3.000 md	Lebih dari 3.000 md
TTFB (Eksperimental)	0 md hingga 800 md	Lebih dari 800 md hingga 1.800 md	Lebih dari 1.800 md

Sebuah halaman web atau origin dinilai lulus evaluasi Core Web Vitals jika persentil ke-75 dari ketiga metrik utama (INP, LCP, dan CLS) berada dalam kategori Baik. Apabila data INP pada URL tertentu belum mencukupi di set data publik, kelulusan ditentukan berdasarkan nilai persentil LCP dan CLS.

Cara Kerja Interaction to Next Paint dalam Mengukur Responsivitas Halaman

Menurut panduan teknis Understanding Interaction to Next Paint di Google Codelabs, INP mengamati latensi seluruh interaksi yang dilakukan pengguna selama berada di halaman. Pengukuran interaksi dimulai sejak pengguna memberikan input hingga frame visual berikutnya (next paint) berhasil digambar oleh browser pada layar.

Durasi total satu interaksi terdiri dari tiga fase utama:

• Input Delay: Waktu tunggu sejak pengguna melakukan aksi fisik (klik/ketukan) hingga browser siap mengeksekusi fungsi penanganan event (event listener). Jeda ini sering kali disebabkan oleh thread utama yang sedang sibuk memproses tugas lain (long tasks).
• Event Processing Duration: Waktu yang dihabiskan oleh JavaScript untuk mengeksekusi kode di dalam event listener yang bersangkutan.
• Presentation Delay: Waktu yang diperlukan browser untuk menghitung ulang gaya (style recalculation), menyusun tata letak (layout), menggambar elemen (paint), dan mengomposisikan piksel visual ke layar.

Pengukuran interaksi berakhir tepat saat frame berikutnya diizinkan untuk dirender ke layar, bahkan jika browser menentukan bahwa tidak ada perubahan visual baru yang perlu ditampilkan. Apabila thread utama diblokir oleh tugas JavaScript yang berat, browser tidak dapat memproses frame berikutnya secara tepat waktu, sehingga nilai latensi INP membengkak.

Kondisi responsivitas yang lambat sering memicu perilaku klik berulang kali oleh pengguna (rage clicks). Klik bertubi-tubi pada elemen yang lambat merespons akan menumpuk antrean tugas baru di thread utama, yang pada akhirnya memperburuk latensi interaksi berikutnya.

Strategi Pengelolaan Beban Pemrosesan untuk Mengoptimalkan Respons Interaksi

Untuk menekan nilai INP ke batas aman (di bawah 200 milidetik), beban pemrosesan skrip pada thread utama perlu dikelola secara terstruktur. Kode yang tidak esensial harus dipindahkan ke luar jalur eksekusi kritis interaksi atau dipecah menjadi unit kerja yang lebih kecil.

1. Penerapan Pola Debounce pada Interaksi Beruntun

Pola debounce berfungsi menunda eksekusi operasi komputasi atau permintaan jaringan yang berat ketika serangkaian interaksi terjadi dalam waktu singkat. Pola ini umum diterapkan pada kolom pencarian otomatis (autocomplete) atau tombol dengan frekuensi penekanan tinggi.

Alih-alih menjalankan fungsi berat pada setiap penekanan tombol, sistem memasang pewaktu (misalnya 500 hingga 1.000 milidetik). Jika interaksi baru masuk sebelum batas waktu tercapai, pewaktu sebelumnya dibatalkan menggunakan fungsi pembersih pewaktu dan diatur ulang kembali. Dengan metode ini, pemrosesan berat hanya dijalankan satu kali setelah aktivitas pengguna berhenti sementara.

2. Pemecahan Tugas Berat (Yielding to Main Thread)

Tugas JavaScript yang membutuhkan waktu eksekusi panjang (long tasks) harus dipecah menjadi potongan-potongan tugas kecil agar browser memiliki kesempatan memproses input pengguna di sela-sela eksekusi. Pemecahan tugas dapat dilakukan dengan memberikan titik jeda (yield point) menggunakan API penjadwalan seperti scheduler.yield() atau polyfill berbasis setTimeout.

Dengan menyisipkan perintah jeda di antara tahapan komputasi, browser dapat memprioritaskan penanganan event interaksi baru yang masuk. Kendati demikian, pemberian titik jeda perlu diterapkan secara terukur pada blok tugas yang relevan, karena pembagian tugas yang terlalu granular pada setiap baris kode justru dapat menurunkan efisiensi throughput CPU secara keseluruhan.

3. Pembatalan Tugas yang Tidak Lagi Relevan dengan AbortController

Ketika interaksi baru terjadi saat pemrosesan tugas dari interaksi sebelumnya masih berjalan dalam beberapa potongan tugas, pekerjaan lama yang sedang berlangsung sebaiknya dihentikan. Memanfaatkan antarmuka AbortController memungkinkan pengembang menandai dan membatalkan sisa iterasi tugas lama ketika input baru diterima, sehingga sumber daya thread utama tidak terbuang sia-sia.

Selain optimasi logika komputasi internal, kebersihan skrip pihak ketiga juga memengaruhi ketersediaan thread utama. Tata kelola eksekusi skrip eksternal dapat diperkuat melalui aturan pembatasan sumber daya, misalnya dengan menerapkan konfigurasi HTTP Content Security Policy guna memastikan hanya skrip tepercaya dan terverifikasi yang berjalan di peramban.

Pemantauan dan Analisis Metrik Performa Web Menggunakan PageSpeed Insights

Untuk mengevaluasi efektivitas optimasi performa web, pengembang dapat memanfaatkan PageSpeed Insights yang menyajikan dua jenis data komprehensif:

• Data Pengalaman Pengguna Nyata (Field Data): Bersumber dari set data Chrome User Experience Report (CrUX) yang mencakup metrik historis selama periode pengumpulan 28 hari sebelumnya dari pengguna riil. Data ini mencerminkan kondisi perangkat keras dan jaringan yang beragam di dunia nyata pada persentil ke-75.
• Diagnostik Simulasi (Lab Data): Didukung oleh mesin Lighthouse yang menjalankan simulasi pemuatan pada lingkungan terkendali. Pada pengujian seluler, Lighthouse menyimulasikan pemuatan perangkat kelas menengah di jaringan seluler, serta desktop teremulasi berkabel untuk pengujian komputer desktop.

Perbedaan nilai antara data lapangan dan data laboratorium wajar terjadi karena data lab beroperasi pada satu kondisi perangkat dan jaringan tetap, sedangkan data lapangan menangkap variasi koneksi serta perilaku interaksi nyata pengguna. Selain menjaga performa skrip interaktif, pemilik situs juga disarankan menjaga konsistensi perayapan indeks mesin telusur, salah satunya dengan memastikan konfigurasi canonical tag duplikasi URL terpasang secara tepat pada struktur halaman.

Langkah tindak lanjut yang dapat dilakukan untuk mempertahankan kualitas interaksi web adalah melakukan audit berkala pada URL penting, mengidentifikasi fungsi JavaScript yang memblokir render frame visual, serta memantau laporan CrUX bulanan dan harian guna memastikan persentil ke-75 metrik INP tetap berada di bawah ambang batas 200 milidetik.