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.
Uangnya salah sasaran.
Diagnosisnya salah dari awal.
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.
1. 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.
Tiga Fase INP yang Perlu Anda Pahami
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.
Di Mana Script Pihak Ketiga Menyusup
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 <head> 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.
2. 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.
Mulai dari Data Lapangan, Bukan Skor Lighthouse
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.
Reproduksi di Chrome DevTools
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.
Verifikasi Sebelum Menuduh
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?
Cara paling murah membuktikannya adalah blokir script itu lewat Network request blocking di DevTools, lalu ulangi rekaman yang sama. Kalau input delay anjlok, Anda punya bukti yang bisa dibawa ke rapat.
3. Peta Keputusan: Nilai Bisnis vs Biaya Main Thread
Tidak semua script pihak ketiga layak dibunuh. Beberapa memang menghasilkan uang. Yang Anda butuhkan bukan pembantaian massal, melainkan matriks keputusan yang bisa dipertanggungjawabkan ke tim marketing. Tabel berikut adalah kerangka yang biasa kami pakai saat memetakan script pihak ketiga INP pada situs bisnis.
| Kategori Script | Contoh Umum | Dampak Khas ke INP | Rekomendasi Penanganan |
|---|---|---|---|
| Analitik dasar | GA4, server-side tagging | Rendahβsedang; listener global bisa menambah input delay | Pertahankan, pindahkan ke server-side tagging bila memungkinkan |
| Tag manager | GTM dengan banyak tag aktif | Sedangβtinggi; efek menumpuk per tag | Audit isi container tiap kuartal, hapus tag kampanye mati |
| Widget chat | Live chat, chatbot vendor | Tinggi; sering dimuat sinkron dan memasang listener luas | Muat setelah interaksi pertama atau setelah load
|
| Embed media | YouTube, Google Maps, feed sosial | Tinggi; iframe membawa bundle JS sendiri | Ganti dengan facade (klik-untuk-muat) |
| Pixel iklan | Meta Pixel, TikTok Pixel | Sedangβtinggi; sering ada duplikasi tanpa disadari | Konsolidasi, hapus pixel kampanye yang sudah berhenti |
| A/B testing | Tool eksperimen sisi klien | Tinggi; kerap render-blocking secara sengaja | Batasi ke halaman yang benar-benar diuji |
| Cookie consent | CMP banner | Sedang; sering merusak CLS sekaligus INP | Reservasi ruang layout, muat sedini mungkin tapi seringan mungkin |
Aturan praktisnya: kalau sebuah script tidak bisa Anda kaitkan dengan satu angka pendapatan atau satu keputusan produk, script itu kandidat penghapusan.
4. Empat Teknik Menjinakkan yang Terbukti di Produksi
Setelah pelakunya teridentifikasi, sebagian besar perbaikan tidak membutuhkan rewrite. Yang dibutuhkan adalah mengubah kapan dan di mana kode itu berjalan. Empat pola berikut menutup mayoritas kasus yang saya temui.
Facade Pattern untuk Embed Berat
Alih-alih memuat iframe YouTube saat halaman dibuka, tampilkan thumbnail statis dan baru muat iframe saat diklik.
<div class="yt-facade" data-id="VIDEO_ID">
<img src="/thumb.webp" width="800" height="450" alt="Pratinjau video" loading="lazy">
<button type="button" aria-label="Putar video">βΆ</button>
</div>
<script type="module">
document.querySelectorAll('.yt-facade').forEach((el) => {
el.addEventListener('click', () => {
const iframe = document.createElement('iframe');
iframe.src = `https://www.youtube-nocookie.com/embed/${el.dataset.id}?autoplay=1`;
iframe.allow = 'accelerometer; autoplay; encrypted-media; picture-in-picture';
iframe.loading = 'lazy';
iframe.width = 800;
iframe.height = 450;
el.replaceChildren(iframe);
}, { once: true });
});
</script>
Satu embed YouTube bisa membawa ratusan kilobyte JavaScript. Facade menundanya sampai pengunjung benar-benar menginginkannya. Sambil menangani resource eksternal seperti ini, atribut rel juga layak diperiksa ulang β Tomasz Εakomy menulis penjelasan ringkas soal nofollow, noopener, dan noreferrer yang berguna sebagai pelengkap sisi keamanannya.
Memecah Long Task dengan scheduler.yield()
Kalau handler Anda sendiri yang panjang, serahkan kembali kendali ke browser di tengah jalan.
async function prosesBerat(items) {
for (const item of items) {
hitung(item);
if (navigator.scheduling?.isInputPending?.()) {
await yieldToMain();
}
}
}
function yieldToMain() {
if ('scheduler' in window && 'yield' in scheduler) {
return scheduler.yield();
}
return new Promise((r) => setTimeout(r, 0));
}
Polanya: kerjakan sepotong, cek apakah ada input menunggu, mengalah, lanjutkan.
Memindahkan Script ke Web Worker
Untuk tag analitik yang tidak butuh akses langsung ke DOM, Partytown memindahkan eksekusinya ke web worker sehingga main thread tetap bebas. Ini bukan peluru perak β beberapa vendor akan rusak β tapi untuk GA4 dan pixel sederhana, hasilnya sering dramatis.
Menunda Widget sampai Ada Niat Pengguna
Widget chat tidak perlu ada di milidetik pertama. Muat ketika pengunjung menunjukkan niat.
const muatChat = () => {
const s = document.createElement('script');
s.src = 'https://vendor.example/widget.js';
s.async = true;
document.body.appendChild(s);
};
['scroll', 'pointermove', 'keydown'].forEach((evt) =>
window.addEventListener(evt, muatChat, { once: true, passive: true })
);
setTimeout(muatChat, 8000);
Di tim kami di Masbadar, pola ini masuk ke checklist wajib sebelum serah terima setiap proyek company profile dan toko online β karena widget chat adalah penyebab regresi INP paling sering setelah situs diserahkan ke klien.
5. Protokol Audit Tujuh Hari
Perbaikan performa gagal bukan karena tekniknya sulit, tapi karena tidak punya urutan. Protokol berikut sengaja dibatasi satu minggu supaya bisa masuk ke satu sprint tanpa mengganggu roadmap fitur.
Urutan Kerjanya
- Hari 1 β Inventarisasi. Daftar semua domain pihak ketiga yang dimuat. Gunakan tab Network, kelompokkan per domain.
- Hari 2 β Ukur baseline. Catat INP p75 dari CrUX dan hasil rekaman DevTools untuk tiga halaman terpenting.
- Hari 3 β Klasifikasi. Petakan tiap script ke tabel nilai-vs-biaya di bab 3. Minta tim marketing membenarkan setiap baris.
- Hari 4 β Hapus yang mati. Cabut tag kampanye tidak aktif dan pixel duplikat. Ini perbaikan tanpa risiko.
- Hari 5 β Tunda dan facade. Terapkan lazy-load pada widget serta facade pada embed.
- Hari 6 β Isolasi. Pindahkan analitik yang memenuhi syarat ke web worker atau server-side tagging.
- Hari 7 β Pasang pengawas. Aktifkan Real User Monitoring supaya regresi berikutnya ketahuan dalam hitungan jam, bukan 28 hari.
Schema HowTo
Dev.to menghapus tag <script>, jadi tempelkan blok ini di versi canonical artikel pada situs Anda sendiri:
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "Cara Mengaudit dan Menjinakkan Script Pihak Ketiga yang Merusak INP",
"description": "Protokol tujuh hari untuk mengidentifikasi dan memitigasi script pihak ketiga yang menyebabkan skor INP buruk pada situs bisnis.",
"totalTime": "P7D",
"tool": [
{ "@type": "HowToTool", "name": "Google Search Console" },
{ "@type": "HowToTool", "name": "Chrome DevTools" },
{ "@type": "HowToTool", "name": "Real User Monitoring" }
],
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Inventarisasi script pihak ketiga",
"text": "Daftar seluruh domain pihak ketiga yang dimuat halaman menggunakan panel Network di Chrome DevTools."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Ukur baseline INP",
"text": "Catat nilai INP persentil ke-75 dari data lapangan CrUX dan hasil rekaman Performance untuk tiga halaman terpenting."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Klasifikasi nilai versus biaya",
"text": "Petakan setiap script ke matriks nilai bisnis dan biaya main thread bersama tim marketing."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Hapus tag tidak aktif",
"text": "Cabut pixel duplikat dan tag kampanye yang sudah berhenti berjalan."
},
{
"@type": "HowToStep",
"position": 5,
"name": "Tunda pemuatan dan pasang facade",
"text": "Terapkan lazy-load pada widget chat dan pola facade pada embed video serta peta."
},
{
"@type": "HowToStep",
"position": 6,
"name": "Isolasi script analitik",
"text": "Pindahkan analitik yang memenuhi syarat ke web worker atau server-side tagging."
},
{
"@type": "HowToStep",
"position": 7,
"name": "Pasang Real User Monitoring",
"text": "Aktifkan pemantauan pengguna nyata agar regresi INP terdeteksi lebih cepat daripada siklus data CrUX."
}
]
}
6. Pertanyaan yang Paling Sering Muncul
Bagian ini merangkum pertanyaan yang hampir selalu diajukan klien setelah presentasi hasil audit. Jawabannya sengaja dibuat pendek agar bisa dipakai ulang saat Anda menjelaskan ke stakeholder non-teknis.
Apakah INP benar-benar memengaruhi peringkat Google?
Ya, INP adalah bagian dari Core Web Vitals yang menjadi sinyal page experience. Tapi jangan berharap lompatan drastis: perannya lebih mirip tie-breaker antara dua halaman dengan kualitas konten setara, bukan pengganti konten yang bagus.
Berapa lama sampai perbaikan terlihat di Search Console?
CrUX memakai jendela bergulir 28 hari, jadi perubahan biasanya baru tercermin penuh dalam empat sampai enam minggu. Gunakan ekstensi Web Vitals atau RUM untuk verifikasi instan setelah deploy.
Apakah semua script pihak ketiga INP harus dihapus?
Tidak. Tujuannya bukan nol pihak ketiga, melainkan pihak ketiga yang bisa dipertanggungjawabkan. Script yang menghasilkan pendapatan terukur layak dipertahankan β asalkan dimuat pada waktu yang tepat.
Bagaimana kalau vendor menolak mengoptimalkan script-nya?
Anda punya tiga opsi: isolasi lewat web worker, tunda pemuatannya sampai ada niat pengguna, atau ganti vendor. Dalam beberapa kasus, opsi ketiga adalah yang paling murah dalam jangka panjang.
Apakah pindah ke Next.js atau framework modern otomatis memperbaiki INP?
Tidak otomatis. Framework modern membantu LCP lewat SSR dan streaming, tapi hidrasi yang berat justru bisa memperburuk INP. Arsitektur menentukan, bukan nama framework.
Responsivitas Adalah Janji yang Anda Buat ke Setiap Pengunjung
Pada akhirnya, seluruh pembahasan teknis di atas bermuara ke satu hal yang jauh lebih tua daripada Core Web Vitals: batas kesabaran manusia. Ambang 200 milidetik yang ditetapkan Google bukan angka arbitrer dari tim marketing Chrome, melainkan turunan dari riset psikologi interaksi yang sudah stabil selama puluhan tahun.
Jakob Nielsen merumuskannya paling jelas. Dalam kerangka batas waktu responsnya yang klasik, ia menyebut satu detik sebagai "the limit for the user's flow of thought to stay uninterrupted" β batas ketika alur pikiran pengguna masih utuh. Lewat dari itu, perhatian pecah dan rasa kendali hilang.
Nielsen adalah peneliti humanβcomputer interaction asal Denmark dan salah satu pendiri Nielsen Norman Group, sosok yang oleh The New York Times pernah disebut sebagai rujukan utama soal usabilitas web. Relevansinya di sini langsung: INP pada dasarnya adalah upaya Google mengukur, secara massal dan otomatis, hal yang sudah Nielsen definisikan secara manual sejak awal 1990-an. Ketika Anda memangkas script pihak ketiga INP dari 480 ms menjadi 120 ms, Anda tidak sedang mengejar angka hijau di dasbor β Anda sedang mengembalikan rasa kendali kepada orang yang sedang mencoba menghubungi bisnis Anda.
Dan itu, pada akhirnya, adalah pekerjaan yang jauh lebih layak dibayar daripada upgrade RAM.
Ditulis dari pengalaman menangani optimasi teknis lintas industri β interior, konstruksi, engineering, hingga jasa lokal. Untuk konteks proyek dan layanan pengembangan situs bisnis selengkapnya, lihat Masbadar.
Punya pengalaman berbeda? Script pihak ketiga apa yang paling merusak INP di proyek Anda? Tulis di kolom komentar β saya baca semuanya.
