INP Optimization: Cara Website Bisnis Indonesia Menurunkan Latensi Interaksi di Bawah 200 ms

TL;DR: INP (Interaction to Next Paint) adalah metrik Core Web Vitals yang mengukur responsivitas halaman terhadap interaksi pengguna. Skor baik di bawah 200 ms, perlu diperbaiki di 200-500 ms, buruk di atas 500 ms. Untuk website bisnis Indonesia, sumber utama INP buruk biasanya script tracking pihak ketiga, hydration berat, dan event handler yang tidak di-debounce.

Pada audit Web Vitals untuk beberapa klien e-commerce di Q1 2026, satu pola muncul berulang. LCP sudah hijau, CLS terkendali, namun INP merah di mobile. Skor 380-650 ms di banyak halaman katalog. Penyebab paling umum bukan logic aplikasi, melainkan script analitik dan chat widget yang dipasang berlapis tanpa orkestrasi.

INP menggantikan FID sebagai metrik responsivitas resmi sejak Maret 2024. Berbeda dengan FID yang hanya mengukur interaksi pertama, INP mengambil persentil ke-98 dari semua interaksi dalam satu sesi. Artinya, satu interaksi berat di tengah sesi cukup untuk menghancurkan skor.

Mengapa INP Sering Lebih Sulit dari LCP

LCP bisa diperbaiki lewat preload gambar, LCP image optimization, atau CDN. INP menuntut perbaikan pada kode JavaScript yang berjalan saat user mengetuk. Pemicunya tersebar: tracking pixel, A/B testing tools, hydration komponen interaktif, listener yang diikat ke window.

Berdasarkan praktik Web Vitals yang saya pakai, urutan dampak di website bisnis Indonesia biasanya: pertama script pihak ketiga, kedua hydration React/Next, ketiga event handler bermasalah, keempat layout shifting akibat interaksi.

Empat Sumber INP Buruk dan Solusinya

Saat menangani halaman koleksi Nalesha (e-commerce parfum), pemindahan tracking ke web worker plus debouncing pada filter harga menurunkan INP dari 510 ms ke 180 ms di mobile dalam waktu 2 sprint pengembangan. Pengukuran memakai data lapangan dari CrUX bukan lab.

Praktik Pengukuran yang Benar

INP dari Lighthouse di lab tidak selalu sama dengan INP nyata pengguna. Untuk website bisnis Indonesia, gunakan kombinasi: data CrUX untuk kondisi nyata, RUM untuk per-halaman, dan Lighthouse hanya untuk regresi developer. Web.dev menjelaskan praktik ini lengkap di panduan INP resmi.

Hindari kebiasaan mengandalkan satu run Lighthouse di laptop kantor. Mobile pengguna Indonesia umumnya 3-5 kali lebih lambat dari laptop developer.

Studi Kasus Singkat: Atmo LMS

Saat mengoptimalkan Atmo (LMS), interaksi yang paling berat adalah submit kuis multi-select. Sebelum optimasi, INP pengguna mobile sekitar 430 ms karena re-render seluruh komponen kuis. Setelah memecah komponen, memakai useTransition di React, dan menunda kalkulasi skor ke microtask, INP turun ke 165 ms. Tidak ada perubahan visual, hanya orkestrasi rendering.

Pelajaran utamanya, INP tidak menuntut React versi terbaru atau library mahal, tapi disiplin memecah kerja yang sebelumnya synchronous. Anda bisa kombinasikan dengan edge functions bila personalisasi diperlukan tanpa menambah beban client.

Pertanyaan Umum

Apa beda INP dengan FID?

FID hanya mengukur interaksi pertama. INP mengambil persentil ke-98 dari semua interaksi sehingga lebih realistis menggambarkan pengalaman penuh sesi.

Apakah INP berpengaruh ke ranking SEO?

Ya. Sejak Maret 2024, INP adalah salah satu sinyal Core Web Vitals yang dipakai Google sebagai faktor peringkat halaman.

Berapa target INP untuk e-commerce Indonesia?

Target operasional di bawah 200 ms di mobile. Untuk halaman katalog dan checkout, target ideal 150 ms karena interaksinya intensif.

Apakah cukup memakai Lighthouse untuk audit?

Tidak cukup. Lighthouse berjalan di lingkungan lab. Validasi akhir wajib pakai data CrUX atau RUM dari pengguna asli.

Penutup

INP buruk jarang disebabkan oleh satu komponen besar. Ia adalah akumulasi dari banyak script kecil yang menumpuk di main thread. Yang membedakan website cepat dan lambat di Indonesia bukan framework, melainkan disiplin tim memutuskan apa yang boleh berjalan di main thread dan apa yang harus dipindahkan.