Case Study

Studi Kasus Vetmo: Memperbaiki INP di Halaman Booking

Vito Atmo
Vito Atmo·7 Juni 2026·0 kali dibaca·3 min baca
Studi Kasus Vetmo: Memperbaiki INP di Halaman Booking

TL;DR: INP (Interaction to Next Paint) mengukur seberapa cepat halaman merespons interaksi pengguna seperti klik atau ketukan. Skor baik di bawah 200 ms. Di Vetmo, penyebab utama INP buruk bukan ukuran gambar, melainkan skrip yang memblokir thread utama saat tombol booking ditekan. Memecah pekerjaan berat jadi potongan kecil memperbaiki responsivitas tanpa menulis ulang aplikasi.

Saat membangun Vetmo, layanan pet care, kami menerima keluhan yang spesifik: tombol "Pesan Jadwal" terasa nge-lag saat ditekan, padahal halaman terlihat sudah selesai dimuat. Ini gejala klasik masalah INP, bukan masalah loading.

Banyak marketer mengira halaman lambat selalu soal gambar besar atau server lemot. Padahal sejak INP menggantikan FID sebagai metrik responsivitas di Core Web Vitals pada Maret 2024, masalah seperti ini jadi lebih terukur dan lebih sering ketahuan.

Apa yang Sebenarnya Diukur INP

Core Web Vitals terdiri dari tiga metrik. LCP mengukur kecepatan tampil konten utama, CLS mengukur kestabilan layout, dan INP mengukur responsivitas terhadap interaksi. INP yang buruk berarti ada jeda antara pengguna mengklik dan halaman bereaksi.

Berbeda dengan LCP yang terjadi saat halaman dimuat, INP terjadi sepanjang sesi. Setiap klik, ketukan, dan ketikan dinilai. Skor akhir mengambil interaksi paling lambat, jadi satu tombol yang berat bisa merusak skor keseluruhan.

Diagnosis di Vetmo

Kami pakai panel Performance di Chrome DevTools untuk merekam interaksi tombol booking. Hasilnya jelas: saat tombol ditekan, sebuah skrip validasi form berjalan sinkron dan memblokir thread utama selama ratusan milidetik sebelum halaman sempat menggambar ulang.

TemuanDampak ke INP
Validasi form sinkronMemblokir thread utama saat klik
Listener event berlapisMenunda paint berikutnya
Render ulang komponen besarMemperpanjang waktu respons

Yang menarik, ukuran gambar dan kecepatan server sudah baik. Masalahnya murni di sisi interaktivitas. Ini memperkuat prinsip dari web.dev soal optimasi INP: responsivitas dan kecepatan muat adalah dua hal berbeda yang butuh perbaikan berbeda.

Yang Kami Perbaiki

Kami memecah validasi form jadi potongan kecil dan menundanya agar tidak memblokir paint. Pekerjaan berat dipindahkan ke setelah halaman sempat merespons visual. Pendekatan ini tidak butuh menulis ulang aplikasi, hanya menata ulang kapan kode berjalan.

Setelah perubahan, jeda saat menekan tombol booking turun secara terasa dan skor INP masuk rentang baik. Angka pasti bervariasi tergantung perangkat pengguna, tapi pola perbaikannya konsisten di pengujian kami.

Pertanyaan Umum

Apa beda INP dan LCP?

LCP mengukur kecepatan konten utama tampil saat halaman dimuat. INP mengukur seberapa cepat halaman merespons interaksi sepanjang sesi. Keduanya bagian dari Core Web Vitals tapi mengukur hal berbeda.

Berapa skor INP yang dianggap baik?

Di bawah 200 ms dianggap baik, 200 sampai 500 ms perlu perbaikan, di atas 500 ms buruk. Skor diambil dari interaksi paling lambat dalam sesi.

Apakah memperbaiki INP butuh menulis ulang website?

Sering tidak. Banyak masalah INP berasal dari skrip yang memblokir thread utama. Memecah pekerjaan berat dan menundanya biasanya cukup tanpa perombakan besar.

Pelajaran untuk Marketer

INP mengajarkan bahwa "cepat dimuat" tidak sama dengan "terasa cepat". Sebelum menyalahkan gambar atau hosting, rekam dulu interaksi kunci seperti tombol konversi. Sering kali pelakunya adalah satu skrip yang berjalan di waktu yang salah.

Bagikan

Artikel Terkait

#core-web-vitals#inp#web-performance#case-study#website-bisnis

Butuh website yang benar-benar bekerja?

Hubungi Vito untuk konsultasi gratis 15 menit.

WhatsApp Sekarang