Audit INP Website: Langkah Praktis Sebelum Lapor ke Klien

TL;DR: Audit INP yang efektif dimulai dari data lapangan, bukan tebakan. Urutannya: ambil data INP riil dari Core Web Vitals, reproduksi interaksi terlambat di DevTools, identifikasi long task penyebabnya, lalu pecah atau tunda kode berat. Pendekatan ini menurunkan skor INP tanpa menulis ulang aplikasi.

Banyak laporan audit performa berhenti di angka kecepatan loading. Padahal sejak Interaction to Next Paint menggantikan First Input Delay sebagai metrik resmi pada 2024, halaman yang cepat dimuat tetap bisa gagal jika terasa lambat saat diklik. Dalam beberapa proyek antarmuka yang saya tangani, keluhan klien hampir selalu sama: "kok klik tombolnya delay?" padahal skor kecepatan halaman terlihat hijau.

Artikel ini menyusun urutan audit Interaction to Next Paint yang bisa diikuti sebelum mengirim laporan ke klien, supaya temuan berbasis bukti, bukan asumsi.

Mulai dari Data Lapangan, Bukan Lab

Kesalahan paling umum adalah langsung membuka DevTools di laptop kencang dan menyimpulkan "tidak ada masalah". Pengukuran lab di perangkat cepat sering menyembunyikan masalah yang dialami pengguna sungguhan di ponsel kelas menengah.

Mulailah dari data lapangan lewat laporan Core Web Vitals di Google Search Console atau CrUX. Cari halaman dengan INP di atas 200 ms. Inilah daftar prioritas audit yang sebenarnya, karena mencerminkan perangkat dan jaringan pengguna nyata.

Reproduksi dan Temukan Long Task

Setelah tahu halaman bermasalah, langkah berikutnya adalah mereproduksi interaksi yang lambat sambil merekam di tab Performance Chrome DevTools. Aktifkan throttling CPU 4x agar mendekati perangkat pengguna Indonesia pada umumnya.

Long task adalah tugas JavaScript yang memblokir thread utama. Detail teknik pemecahannya saya bahas terpisah di glosarium soal INP debugging. Panduan resmi tersedia di web.dev tentang optimasi INP.

Studi Kasus: Halaman Layanan yang Terasa Berat

Saat menata ulang halaman layanan untuk salah satu klien personal branding, skor kecepatan loading sudah baik tetapi tombol kontak terasa tertunda hampir setengah detik. Rekaman DevTools menunjukkan dua skrip pihak ketiga berjalan bersamaan saat halaman selesai dimuat, menahan thread utama tepat ketika pengguna pertama kali mengetuk.

Solusinya tidak dramatis: menunda pemuatan kedua skrip itu sampai interaksi pertama, lalu memecah satu fungsi inisialisasi panjang menjadi beberapa bagian. Setelah perubahan, respons tombol membaik secara nyata. Pelajaran utamanya, INP buruk jarang berasal dari satu bug besar, melainkan akumulasi kerja kecil yang menumpuk di waktu yang salah.

Pertanyaan Umum

Apakah audit INP butuh tools berbayar?

Tidak. Google Search Console untuk data lapangan dan Chrome DevTools untuk diagnosa sudah cukup untuk mayoritas kasus. Tools berbayar membantu pemantauan berkelanjutan, bukan syarat audit awal.

Berapa lama biasanya perbaikan INP terlihat di Search Console?

Data lapangan Core Web Vitals bergerak berdasarkan jendela 28 hari, jadi perbaikan biasanya mulai terlihat dalam beberapa minggu, bukan langsung.

Apakah INP hanya masalah situs React?

Tidak. INP relevan untuk semua situs yang punya interaksi JavaScript. Situs dengan banyak skrip pihak ketiga, apa pun frameworknya, rentan terhadap long task.

Audit yang Baik Menjual Kepercayaan

Laporan audit yang menyertakan data lapangan, rekaman penyebab, dan langkah perbaikan konkret jauh lebih meyakinkan klien daripada sekadar angka skor. Mulailah dari pengalaman pengguna nyata, buktikan penyebabnya, lalu tunjukkan perbaikannya. Itu yang membedakan audit performa yang dipercaya dari yang sekadar formalitas.