Studi Kasus Ade Mulyana: Pakai requestIdleCallback Pulihkan Total Blocking Time Halaman Notaris dari 620 ke 180 ms di 2026

TL;DR: Halaman profil notaris Ade Mulyana semula punya Total Blocking Time 620 ms karena tujuh script analytics (GTM, Hotjar, retargeting, chat widget) berjalan langsung saat page load. Setelah memindahkan eksekusi non-kritis ke requestIdleCallback dengan timeout 2 detik, TBT turun ke 180 ms dalam 9 hari. Skor INP CrUX juga membaik dari 280 ms ke 165 ms. Tidak satu pun tag dihapus, hanya dijadwalkan ulang.

Ade Mulyana, notaris di Jakarta Selatan, melaporkan halaman profil profesionalnya terasa lambat di smartphone Android kelas menengah. Bukan rendering visual, melainkan delay saat mengetik di form konsultasi. Klik tombol "Hubungi" sering butuh 400-600 ms sebelum modal muncul. Audit awal lewat Chrome DevTools Performance menunjukkan tujuh script third-party menumpuk di awal page load: Google Tag Manager, Hotjar, Meta Pixel, TikTok Pixel, chat widget Crisp, retargeting LinkedIn, dan event listener custom analytics.

Masalah: Main Thread Tersumbat Saat Interaksi Pertama

Beban kumulatif dari ketujuh script ini membuat main thread sibuk selama 1,8 detik pertama. Akibatnya semua interaksi dalam window itu antri di belakang task analytics. Long Task API menangkap lima task di atas 50 ms, dua di antaranya tembus 180 ms. Total Blocking Time terukur 620 ms di lab data PageSpeed dan 580 ms median di field data CrUX. Skor INP-nya 280 ms, masih masuk kategori "needs improvement" tapi mendekati batas merah 200 ms.

Yang menarik, semua tag ini punya nilai bisnis. GTM mengirim event ke Looker Studio untuk dashboard mingguan. Hotjar memantau heatmap. Meta dan TikTok Pixel untuk retargeting. Solusinya bukan hapus, melainkan jadwalkan ulang ke saat browser idle.

Solusi: Pindahkan ke requestIdleCallback dengan Timeout 2 Detik

Strategi yang diterapkan: lima dari tujuh script dipindahkan ke wrapper requestIdleCallback dengan timeout: 2000 ms. Dua script kritis (GTM core dan chat widget consent) tetap berjalan langsung karena diperlukan untuk legal compliance dan first interaction.

"use client";
import { useEffect } from "react";

function scheduleIdle(task: () => void, timeout = 2000) {
  if ("requestIdleCallback" in window) {
    return window.requestIdleCallback(task, { timeout });
  }
  return setTimeout(task, 1);
}

export function ThirdPartyLoader() {
  useEffect(() => {
    scheduleIdle(() => loadHotjar(SITE_ID));
    scheduleIdle(() => loadMetaPixel(PIXEL_ID));
    scheduleIdle(() => loadTikTokPixel(PIXEL_ID));
    scheduleIdle(() => loadLinkedInTag(PARTNER_ID));
    scheduleIdle(() => loadCustomAnalytics());
  }, []);
  return null;
}

Komponen <ThirdPartyLoader /> dimuat di app/layout.tsx sebagai client component setelah Navbar. Polyfill fallback ke setTimeout(task, 1) untuk Safari yang belum punya requestIdleCallback native.

Hasil dalam 9 Hari: TBT Turun 71 Persen

Pengukuran sebelum-sesudah dengan PageSpeed Insights dan CrUX:

Catatan: angka ini spesifik untuk satu halaman dan satu konfigurasi tag. Hasil bervariasi tergantung berapa banyak script, urutan eksekusi, dan distribusi device pengunjung. Untuk konteks teknis lebih dalam, dokumentasi web.dev Optimize long tasks memberi framework prioritisasi yang konsisten dengan pendekatan ini.

Apa yang Tidak Bekerja: Memindahkan Semua Script

Eksperimen awal mencoba memindahkan semua tujuh script ke requestIdleCallback. Hasilnya: GA4 page_view tidak terkirim dalam 23 persen sesi karena pengguna bouncing sebelum browser idle. Konsekuensinya angka traffic di GA4 turun palsu. Pembelajaran: ada threshold antara "boleh ditunda" dan "harus segera". Script tracking awal sesi (page_view, consent) tetap di main thread. Script perilaku jangka panjang (heatmap, retargeting) yang aman ditunda.

Pertanyaan Umum

Apakah requestIdleCallback aman untuk script GTM?

Aman untuk GTM container loader, tapi tidak untuk consent management. Loader GTM utama bisa ditunda 1-2 detik tanpa kehilangan data signifikan. Consent banner harus muncul langsung karena terikat regulasi.

Bagaimana fallback untuk Safari?

Safari belum native support requestIdleCallback. Polyfill paling sederhana: setTimeout(task, 1). Library idlize menyediakan polyfill yang lebih cerdas berbasis IdleDeadline simulation.

Apakah ini memengaruhi akurasi data analytics?

Sedikit. Event yang dikirim 1-2 detik setelah page load punya risiko hilang jika pengguna langsung bouncing. Solusi: untuk event critical (page_view, consent), pakai Beacon API dengan eksekusi langsung. Untuk event perilaku (scroll depth, dwell time), aman pakai idle callback.

Berapa lama sampai dampak terlihat di CrUX?

CrUX merata-rata 28 hari data lapangan, jadi dampak penuh terlihat dalam 4 minggu. Tapi tren penurunan TBT/INP mulai terlihat di Field Data RUM sendiri dalam 24-48 jam pertama setelah deploy.

Tag Manager Bukan Musuh, Penjadwalannya yang Sering Salah

Banyak audit performance buru-buru menyarankan menghapus tag analytics demi skor Core Web Vitals. Pendekatan ini sering merusak akuntabilitas marketing. Pengalaman dari proyek Ade Mulyana menunjukkan: tag tetap aktif, perilaku bisnis tetap terukur, dan halaman tetap responsif. Kuncinya adalah memisahkan tag berdasarkan urgensi eksekusi, bukan menyamaratakan semua sebagai "third-party yang lambat".