Studi Kasus Ade Mulyana: Pakai INP Sub-parts Pulihkan Score Interaction dari 380 ke 140 ms di 2026

TL;DR: Site personal brand Ade Mulyana stuck di INP 380 ms (kategori "needs improvement") meski LCP dan CLS sudah hijau. Pakai INP sub-parts breakdown dari web-vitals.js v4, kami isolasi penyebab ke satu komponen filter tag yang me-render 240 item sekaligus. Setelah virtualisasi dan defer pekerjaan render ke requestIdleCallback, INP turun ke 140 ms dalam 5 hari kerja.

Banyak audit Core Web Vitals masih berhenti di "INP buruk" tanpa breakdown akar masalahnya. Padahal sejak web-vitals.js v4, breakdown INP ke tiga sub-parts (input delay, processing time, presentation delay) sudah jadi standar industri.

Tulisan ini mencatat proses audit yang Vito Atmo jalankan untuk site personal brand Ade Mulyana periode April 2026. Fokus pada metodologi, bukan klaim ajaib.

Konteks Masalah

Site Ade Mulyana (Next.js 15, static export) sudah lulus LCP (2,1 detik) dan CLS (0,04). Tapi INP terdeteksi 380 ms di lapangan dari data CrUX. Halaman utama: portfolio listing dengan 240 tag filter aktif. Setiap klik filter butuh sekitar 0,4 detik sebelum visual berubah, terutama di perangkat Android mid-range.

Pendekatan Audit

Kami pasang web-vitals.js v4 dengan attribution payload, kirim hasil ke endpoint kustom. Dalam 72 jam terkumpul 1.840 sample interaksi dari pengguna nyata. Breakdown agregat:

Processing time mendominasi. Itu artinya event handler atau callback JavaScript-nya berat, bukan masalah render atau main thread blocking dari luar. Pendekatan ini sejalan dengan rekomendasi Core Web Vitals Attribution.

Diagnosa Komponen

Pakai Long Animation Frames API (LoAF), kami tag interaksi paling lambat. Hasilnya menunjuk ke satu komponen <TagFilter> yang melakukan Array.filter() di 240 item lalu setState array baru ke React. Re-render menyentuh 240 elemen DOM sekaligus.

Selengkapnya tentang metrik ini ada di Long Animation Frames (LoAF) API. Referensi resmi di web.dev Optimize INP.

Solusi yang Diterapkan

Saat membangun perbaikan, kami pilih tiga langkah konservatif (tanpa ubah desain visual):

1. Virtualisasi list: pakai react-window, render hanya 20 item terlihat. Sisanya placeholder.
2. Defer state update: filter logic dibungkus startTransition (React 18) supaya non-urgent.
3. Idle pre-compute: hasil filter populer di-cache di requestIdleCallback saat halaman idle.

Hasil

Angka di atas berbasis 14 hari data CrUX dan GA4 internal. Bukan klaim universal: profil traffic site personal brand berbeda dari e-commerce.

Pertanyaan Umum

Apakah INP sub-parts wajib pakai web-vitals.js v4?

Tidak wajib, tapi paling mudah. v4 sudah include attribution payload tanpa konfigurasi tambahan. Versi lama hanya memberi nilai INP agregat.

Apakah virtualisasi list selalu solusi?

Tidak. Virtualisasi berguna saat list lebih dari 50-100 item. Untuk list pendek, optimasi event handler dan memoization biasanya cukup.

Berapa lama hasil INP terlihat di Search Console?

CrUX update bulanan (data 28 hari). Sinyal di Search Console biasanya muncul 4-6 minggu setelah perbaikan deploy.

Apakah perlu Lighthouse untuk verifikasi?

Lighthouse memberi data lab (simulasi). Untuk INP, data lapangan dari CrUX atau RUM jauh lebih akurat karena INP hanya valid pada interaksi nyata.

Penutup

Audit INP yang efektif berhenti bertanya "berapa angkanya" dan mulai bertanya "sub-part mana yang dominan". Pendekatan ini membuat optimasi terarah, hemat waktu, dan menghindari over-engineering. Untuk site dengan traffic kecil-menengah, breakdown 72 jam sudah cukup untuk mengisolasi penyebab utama.