Setiap kali skor Core Web Vitals memerah, percakapan di ruang rapat hampir selalu berbelok ke arah yang sama. Ganti hosting. Naikkan RAM. Pindah ke VPS. Padahal setelah migrasi selesai dan tagihan naik dua kali lipat, angka INP di Search Console tetap merah. Saya melihat pola ini berulang di proyek interior, konstruksi, sampai jasa lokal. Panduan audit langkah demi langkah yang diterbitkan Search Engine Journal menegaskan hal yang sama: penyebabnya sering bukan server, melainkan kode yang berjalan di browser pengunjung. Dan dari puluhan audit, satu pola paling sering muncul — script pihak ketiga INP-killer yang tidak pernah dihitung ulang sejak hari situs itu diluncurkan.
Ini bukan sekadar firasat lapangan. Riset adPerf yang membedah biaya performa konten pihak ketiga menemukan bahwa iklan menyumbang lebih dari 15% beban pemuatan halaman di browser, dan sekitar 88% beban itu habis di JavaScript. Angka tersebut penting karena JavaScript adalah satu-satunya hal yang benar-benar memblokir main thread — tempat INP dihitung. Kami mengangkat tema ini karena terlalu banyak pemilik bisnis membayar mahal untuk infrastruktur yang sebenarnya baik-baik saja, sementara tiga tag marketing gratisan diam-diam menghabiskan seluruh anggaran responsivitas mereka.
Dan yang paling menyakitkan: masalahnya bisa diperbaiki dalam satu sprint, tanpa memindahkan satu byte pun ke server baru.
Intinya: INP mengukur seberapa cepat halaman merespons interaksi, bukan seberapa cepat server mengirim HTML. Selama tag manager, widget chat, pixel iklan, dan embed video masih bebas menyerobot main thread, upgrade infrastruktur hanya memindahkan bottleneck — tidak menghapusnya. Audit script pihak ketiga adalah pekerjaan dengan rasio biaya-manfaat tertinggi di seluruh optimasi Core Web Vitals. Kenapa Upgrade Hosting Tidak Menyelamatkan Skor INP Anda
Kesalahpahaman terbesar soal Core Web Vitals adalah menganggap ketiga metriknya mengukur hal yang sama. Padahal LCP dan INP hidup di dunia yang berbeda. LCP sebagian besar adalah masalah jaringan dan aset; INP hampir seluruhnya masalah arsitektur JavaScript. Server yang lebih cepat mengirim HTML lebih awal, tapi tidak membuat main thread berhenti sibuk. Di sinilah masalah script pihak ketiga INP mulai terlihat jelas begitu Anda membedah datanya.
INP bukan satu angka tunggal. Ia adalah penjumlahan tiga fase, dan tiap fase punya penyebab berbeda: Input delay — jeda sebelum event handler Anda sempat berjalan. Biasanya karena main thread sedang mengerjakan tugas lain. Ini wilayah favorit script pihak ketiga. Processing duration — waktu yang dihabiskan handler Anda sendiri. Ini kode Anda: validasi form, filter, kalkulasi. Presentation delay — waktu browser melukis ulang layar setelah handler selesai. DOM raksasa dan layout thrashing bermain di sini.
Kalau breakdown Anda menunjukkan input delay yang dominan, berhenti mengutak-atik server. Masalahnya ada di antrean tugas, bukan di kecepatan respons origin.
Yang membuat kategori ini licin adalah cara masuknya: tidak lewat pull request, tapi lewat rapat marketing.
Satu container Google Tag Manager. Di dalamnya sepuluh tag. Tiga di antaranya memasang listener global di seluruh dokumen.
Widget chat yang dimuat sinkron di karena begitu yang tertulis di dokumentasi vendor.
Pixel remarketing dari kampanye yang sudah berhenti delapan bulan lalu, tapi tidak pernah dicabut.
Tidak ada satu pun dari ini yang muncul di laporan uptime hosting Anda. Audit: Menemukan Script yang Sebenarnya Bersalah
Menuduh tanpa bukti adalah cara tercepat merusak hubungan dengan tim marketing. Jadi audit script pihak ketiga INP harus dimulai dari data, bukan asumsi. Prinsipnya sederhana: identifikasi halaman terburuk lewat data lapangan, lalu reproduksi masalahnya di lab untuk menemukan pelakunya.
Skor Lighthouse adalah simulasi. Yang memengaruhi peringkat adalah CrUX — data pengunjung nyata pada persentil ke-75 dalam jendela 28 hari.
Buka Search Console → Core Web Vitals → INP. Jangan berhenti di grup URL; klik masuk sampai Anda menemukan URL spesifik yang punya data. Halaman kontak, halaman katalog dengan filter, dan halaman checkout hampir selalu jadi tersangka utama karena di situlah interaksi terjadi.
Setelah punya URL target, buka DevTools dan lakukan ini: Panel Performance → aktifkan CPU throttling 4×–6× untuk meniru perangkat kelas menengah. Rekam, lalu klik elemen yang paling sering dipakai pengunjung. Buka Main thread dan cari long task — blok berdurasi lebih dari 50 ms. Aktifkan filter Third-party untuk memisahkan aktivitas milik domain eksternal. Catat nama script dan domainnya.
Filter Third-party itu kunci. Ia memisahkan "kode saya lambat" dari "kode orang lain menumpang di situs saya" dalam hitungan detik.
Satu long task tidak otomatis berarti script itu bersalah atas INP. Yang perlu Anda buktikan adalah korelasi: apakah long task tersebut terjadi tepat ketika pengunjung berinteraksi?