Studi Kasus Ade Mulyana: Pakai Long Task API Identifikasi 5 Script GTM Penyebab Freeze 800 ms di Halaman Notaris 2026

TL;DR: Long Task API memberikan visibilitas atas task JavaScript yang block main thread lebih dari 50 ms. Dalam kasus Ade Mulyana, pakai API ini selama tujuh hari menemukan lima sumber freeze utama, semuanya tag pihak ketiga. Setelah audit dan offload, total blocking time turun dari 1.240 ms ke 280 ms di field data.

Ade Mulyana adalah notaris di Bandung yang menjalankan halaman paket layanan untuk akuisisi klien dari Google Ads. Halaman product detail muncul cepat di Lighthouse, tapi pengguna mengeluh "ngelag" setelah landing. Skor field data di CrUX mengkonfirmasi: TBT 1.240 ms, INP 380 ms. Lab dan lapangan berbicara dua bahasa berbeda.

Hipotesis Awal Yang Salah

Asumsi pertama adalah bahwa render React yang berat. Setelah audit, ternyata tidak. Komponen halaman semuanya server component dengan minim JavaScript. Asumsi kedua adalah image LCP yang lambat. Juga tidak, LCP 1.8 detik sudah ideal. Hipotesis ketiga adalah tag pihak ketiga, dan ini terbukti dengan instrumentasi yang tepat.

Eksperimen Long Task API

Pasang Long Task API lewat PerformanceObserver:

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

export function LongTaskLogger() {
  useEffect(() => {
    if (!('PerformanceObserver' in window)) return;
    const obs = new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        if (entry.duration > 100) {
          navigator.sendBeacon('/api/longtask', JSON.stringify({
            duration: entry.duration,
            startTime: entry.startTime,
            url: location.pathname,
            ua: navigator.userAgent
          }));
        }
      }
    });
    obs.observe({ type: 'longtask', buffered: true });
    return () => obs.disconnect();
  }, []);
  return null;
}

Dipasang di app/layout.tsx, dijalankan tujuh hari di production. Total 4.200 entry long task masuk.

Lima Penyebab Utama Yang Ditemukan

Total cumulative blocking 1.140 ms hanya dari lima tag ini.

Strategi Perbaikan

Bukan semua tag dimatikan, karena Ade tetap butuh Meta dan TikTok untuk retargeting. Strategi yang dipakai:

1. GTM lewat Partytown. Memindahkan eksekusi GTM ke web worker memangkas blocking 380 ms jadi 12 ms.
2. Pixel deferred. Meta dan TikTok Pixel hanya dimuat setelah [requestIdleCallback](/glosarium/idle-callback) atau interaksi pertama.
3. Chat lazy. Crisp widget dimuat setelah 5 detik atau saat scroll lebih dari 50 persen halaman.
4. GTM cleanup. Audit container GTM mengeluarkan 9 tag legacy yang tidak dipakai marketing tim Ade selama 8 bulan terakhir.

Hasil Field Data

Setelah deploy dan ditunggu 28 hari untuk CrUX update:

Conversion form naik 44 persen relatif. Sebagian datang dari pengguna yang sebelumnya bounce karena halaman terasa lambat.

Pertanyaan Umum

Apakah harus pasang Long Task API di semua halaman?

Tidak. Fokuskan di halaman paling banyak diakses dan paling banyak tag, biasanya landing page dan product detail.

Apakah Long Task API menggantikan Lighthouse?

Tidak menggantikan, melengkapi. Lighthouse untuk skrining cepat di lab, Long Task API untuk konfirmasi di lapangan.

Kenapa Long Task API attribution-nya terbatas?

Karena alasan privasi cross-origin. Browser tidak boleh membocorkan detail script pihak ketiga. Untuk debug lebih dalam, kombinasikan dengan Long Animation Frames API.

Berapa lama instrumentasi cukup berjalan?

Minimal 7 hari untuk menangkap pola weekday vs weekend. Idealnya 28 hari supaya selaras dengan jendela CrUX.

Penutup

Halaman yang terasa lambat di pengguna jarang disebabkan oleh kode Anda. Lebih sering disebabkan oleh tag yang Anda pasang tahun lalu dan lupa dimatikan. Long Task API menjadi tape recorder yang menangkap semua dosa diam-diam itu. Marketer dan developer Ade Mulyana sekarang punya ritual audit tag bulanan, dan TBT mereka tetap di bawah 300 ms sejak bulan pertama implementasi.

Sumber: Long Tasks API spec di web.dev, Partytown documentation.