Long Task: Cara Diagnosa Penyebab Tersembunyi INP Buruk di Website Bisnis

TL;DR: Long Task adalah eksekusi JavaScript yang memblokir main thread browser lebih dari 50 ms dan menjadi penyebab utama INP buruk. Diagnosa dilakukan dengan PerformanceObserver atau Chrome DevTools Performance panel. Solusi praktisnya: pecah task panjang, pindahkan komputasi ke web worker, dan kontrol kapan tag pihak ketiga dieksekusi.

Banyak tim panik melihat skor INP merah di Search Console, lalu berasumsi server lambat atau hosting kurang. Kenyataannya, penyebab paling umum bukan di server, melainkan di main thread browser pengguna sendiri.

Dalam audit performa beberapa proyek client tahun lalu, polanya berulang: server respons cepat, gambar dioptimasi, tapi INP tetap di atas 500 ms. Setelah dibuka di Performance panel, biang keladi terlihat: blok skrip 200-400 ms yang berjalan tepat saat pengguna mau klik tombol.

Apa itu Long Task

Long Task adalah istilah resmi W3C untuk eksekusi JavaScript yang memakan waktu lebih dari 50 ms di main thread. Browser memproses JavaScript di thread yang sama dengan rendering dan input, sehingga ketika satu blok kode berjalan terlalu lama, klik dan scroll pengguna ikut tertahan.

Per April 2026, INP sudah menjadi metrik resmi Core Web Vitals. Long Task adalah penyebab teknis paling sering dari INP yang buruk.

Penyebab Paling Umum di Situs Indonesia

Yang menarik, sumber pertama hampir selalu disebabkan oleh tim marketing yang menambah tag tanpa audit. Yang kedua biasanya keputusan arsitektur frontend.

Cara Diagnosa Cepat

Buka Chrome DevTools, pilih panel Performance, lalu rekam interaksi yang dirasa lambat. Long Task akan muncul sebagai blok merah di flame chart. Klik bloknya untuk melihat fungsi mana yang memakan waktu.

Untuk monitoring kontinu di production, pakai PerformanceObserver dengan tipe longtask. Hasilnya bisa dikirim ke RUM tools untuk analisis pola. Praktik standar di industri menyarankan target Long Task di bawah 200 ms total selama 5 detik pertama halaman.

Untuk panduan teknis lengkap, web.dev: Optimize long tasks menyediakan studi kasus dan kode contoh.

Studi Kasus: Atmo dan Vetmo

Saat menangani performa Atmo (LMS), kami menemukan satu skrip third-party untuk video player yang berjalan 350 ms setiap halaman pelajaran dimuat. Dampaknya: peserta yang mengklik tombol "Mulai" dalam 2 detik pertama mengalami delay terlihat. Solusinya bukan ganti player, tapi menunda inisialisasi sampai event idle. INP turun dari 480 ms ke 180 ms tanpa mengubah pengalaman fitur.

Pada Vetmo, masalahnya berbeda: hydration komponen produk menyebabkan blok 250 ms. Solusi yang dipakai adalah memecah komponen menjadi server component dengan island hydration di bagian interaktif saja.

Tiga Langkah Praktis untuk Tim

Pertama, audit semua tag pihak ketiga yang aktif. Banyak tag legacy masih terpasang padahal kampanyenya sudah selesai. Hapus yang tidak dipakai. Kedua, pakai pola yielding (scheduler.yield() atau setTimeout(fn, 0)) untuk loop besar di JavaScript. Ketiga, pertimbangkan Partytown untuk skrip pihak ketiga yang tidak butuh akses DOM langsung.

Untuk perbaikan jangka panjang, Web Worker adalah cara memindahkan komputasi berat ke thread terpisah. Cocok untuk parsing data besar atau enkripsi di sisi klien.

Pertanyaan Umum

Apakah Long Task selalu masalah developer?

Tidak selalu. Tim marketing yang menambah tag tracking tanpa audit performa kerap menjadi penyebab tidak langsung. Audit tag manager rutin menjadi tanggung jawab bersama.

Berapa target ideal untuk INP?

Google menetapkan ambang baik di 200 ms, perlu perbaikan 200-500 ms, buruk di atas 500 ms. Targetnya: 75% pengukuran berada di kategori baik.

Apakah memindahkan kode ke server menyelesaikan Long Task?

Sebagian, tidak semuanya. Server component mengurangi JavaScript yang harus dijalankan klien, tapi interaksi tetap butuh hydration. Kombinasi pendekatan biasanya lebih efektif.

Apakah perangkat low-end lebih rentan kena Long Task?

Ya. Skrip yang butuh 100 ms di flagship bisa menjadi 400 ms di perangkat entry-level. Audit performa wajib menyertakan device throttling.

Penutup

INP yang buruk jarang punya satu penyebab tunggal. Long Task biasanya datang dari kombinasi tag pihak ketiga, hydration besar, dan komputasi sinkron. Pendekatan diagnostik berbasis data, bukan tebakan, adalah cara paling efisien menyelesaikannya. Bagi pemilik bisnis, pertanyaannya bukan "apakah kita perlu memperbaiki INP" melainkan "berapa banyak konversi yang hilang setiap minggunya karena halaman terasa lag".