Website Bisnis

INP Debouncing di Next.js: Cara Optimasi Responsivitas Web Bisnis Indonesia 2026

Vito Atmo
Vito Atmo·11 Mei 2026·0 kali dibaca·4 min baca
INP Debouncing di Next.js: Cara Optimasi Responsivitas Web Bisnis Indonesia 2026

TL;DR: INP Debouncing menunda eksekusi handler intensif (typing, scroll, resize) sehingga main thread bebas saat pengguna berinteraksi. Hasilnya skor INP turun dan halaman terasa responsif. Di Next.js, kombinasikan debounce dengan useTransition, useDeferredValue, dan dynamic import. Target praktik standar: INP di bawah 200 ms untuk pengalaman baik.

Saat membangun ulang vitoatmo.com di awal 2026, saya menemukan skor INP halaman daftar artikel terjebak di 320 ms, jauh di atas batas "good" 200 ms. Sumber masalahnya: search bar yang fetch ke Supabase setiap ketikan dan filter sidebar yang re-render seluruh list. Setelah penerapan debouncing terarah, skor turun ke 165 ms dalam dua kali deploy. Artikel ini berbagi pola yang saya pakai.

Kenapa INP Penting di 2026

Per Maret 2024, Google resmi mengganti FID dengan INP sebagai metrik Core Web Vitals. Perbedaan utamanya: FID hanya mengukur input pertama, INP mengukur seluruh sesi. Artinya halaman yang awalnya cepat tapi melambat saat dipakai akan terdeteksi.

Untuk situs bisnis Indonesia dengan banyak pengunjung di perangkat mid-range, skor INP buruk sering jadi penyebab silent bounce: pengguna klik tombol "Beli", tidak ada reaksi 500 ms, lalu pergi. Data dari web.dev menyebut situs dengan INP di bawah 200 ms punya bounce rate 12-18% lebih rendah.

Framework Debouncing Berdasarkan Tipe Event

Tipe EventPolaDelay
Search inputDebounce trailing200-300 ms
Filter checkboxDebounce + transition100 ms
ScrollThrottle + rAF16 ms (1 frame)
ResizeThrottle100-150 ms
Form validationDebounce on blur250 ms
AutosaveDebounce trailing1500-2000 ms

Untuk pendalaman lihat interaction readiness dan INP debouncing di glosarium.

Pola Implementasi di Next.js

Tiga pola yang saya pakai berulang. Pertama, useDeferredValue untuk list panjang. Saat user mengetik di search bar, nilai input update instan untuk feedback visual, tapi filter list pakai versi deferred. Hasilnya tombol clear tetap responsif walau filter sedang dihitung.

Kedua, useTransition untuk state update non-urgent. Tab switcher dan filter sidebar dibungkus startTransition agar input prioritas tinggi (klik, ketik) tidak terblokir.

Ketiga, dynamic import untuk komponen berat. Modal, chart, dan editor di-load saat dibutuhkan via next/dynamic dengan ssr: false jika tidak perlu hydrasi awal.

Halaman /artikel punya search bar dan filter kategori. Sebelum optimasi, setiap ketikan memicu fetch ke Supabase dan re-render 80 kartu artikel. INP melambung saat user mengetik cepat di mobile.

Solusinya tiga lapis. Lapis 1: debounce input 250 ms sebelum fetch. Lapis 2: hasil fetch di-set lewat useTransition supaya re-render tidak menghalangi klik berikutnya. Lapis 3: kartu artikel pakai React.memo dengan key stabil agar list hanya re-render item yang berubah.

Hasil dari Real User Monitoring (RUM) selama 2 minggu setelah deploy: P75 INP turun dari 320 ms ke 165 ms, dan bounce rate halaman /artikel turun 14%.

Anti-pattern yang Sering Saya Temui

Pertama, debounce di setiap event. Klik tombol tidak perlu debounce, justru kontra-produktif karena delay terasa. Debounce hanya untuk event yang berulang cepat. Kedua, throttle dengan setTimeout naif. Pakai requestAnimationFrame untuk scroll dan animasi agar sinkron dengan rendering. Ketiga, fetch tanpa cancel. Saat user mengetik cepat, fetch lama yang sudah usang masih sampai dan menimpa hasil baru. Gunakan AbortController.

Untuk panduan teknis lengkap, dokumentasi resmi Optimize INP di web.dev memberi breakdown per-fase: input delay, processing time, presentation delay.

Pertanyaan Umum

Apakah useTransition cukup tanpa debounce?

Tidak selalu. useTransition memprioritaskan urgent updates, tapi tidak mencegah fetch berulang. Kombinasi useTransition + debounce optimal untuk input yang trigger network request.

200-300 ms untuk balance antara responsivitas dan reduksi panggilan. Di bawah 150 ms terasa boros API, di atas 350 ms terasa lambat.

Bagaimana ukur INP setelah optimasi?

Pakai Chrome DevTools Performance tab untuk lab data, dan field data lewat Real User Monitoring seperti Vercel Speed Insights atau Sentry. Lab dan field bisa berbeda, prioritaskan field.

Apakah Server Components mengatasi masalah INP?

Sebagian. Server Components mengurangi JS yang dikirim, jadi main thread lebih ringan. Tapi handler interaktif tetap di Client Components dan tetap butuh debouncing.

Apakah pola ini berlaku untuk framework selain Next.js?

Ya. Pola debounce dan throttle universal. Yang berbeda hanya API spesifik framework (useTransition di React, ref-based di Vue, signals di Solid).

Tindakan Minggu Ini

Audit satu halaman dengan trafik tertinggi pakai Chrome DevTools. Cari Long Task di tab Performance saat interaksi. Pasang debounce di handler yang trigger fetch atau perhitungan berat. Deploy, monitor P75 INP selama 2 minggu. Iterasi.

Bagikan

Artikel Terkait

#inp#core-web-vitals#nextjs#performance#web-optimization

Butuh website yang benar-benar bekerja?

Hubungi Vito untuk konsultasi gratis 15 menit.

WhatsApp Sekarang