LoAF: Cara Baru Menemukan Script Perusak INP Website Anda

TL;DR: Long Animation Frames (LoAF) adalah API browser yang mencatat frame lambat beserta script penyebabnya, langsung dari pengguna nyata. Berbeda dari Long Task API lama yang hanya melaporkan durasi, LoAF memberi tahu file dan fungsi mana yang menahan halaman. Untuk website dengan INP buruk, ini memangkas proses debugging dari menebak menjadi menunjuk.

Skor INP buruk adalah salah satu masalah performa paling menjengkelkan: angkanya jelas terlihat di Search Console, tapi penyebabnya tidak. Pengujian Lighthouse di laptop kencang sering menunjukkan hasil hijau, sementara data pengguna nyata berkata sebaliknya.

Jurang antara lab dan lapangan ini biasanya diisi oleh hal-hal yang tidak muncul di pengujian: script tag manager yang menumpuk, chat widget, pixel iklan, atau ekstensi analytics yang dipasang bertahun-tahun lalu dan dilupakan.

Dari Long Task ke LoAF

Sebelumnya, alat standar untuk masalah ini adalah Long Task API, yang saya bahas di artikel diagnosa INP lewat Long Task. Kelemahannya: Long Task hanya berkata "ada tugas 300 ms", tanpa menyebut pelakunya.

Long Animation Frames menutup kelemahan itu. Setiap frame yang lebih dari 50 ms dicatat lengkap dengan atribusi: sumber script, fungsi yang dipanggil, durasi eksekusi, dan waktu style-layout. Dokumentasi teknisnya tersedia di web.dev dan spesifikasinya sudah stabil di Chromium sejak Chrome 123.

Perbedaan praktisnya: Long Task memberi tahu Anda bahwa ada masalah, LoAF memberi tahu Anda siapa masalahnya.

Cara Mengumpulkan Data LoAF

Tiga langkah dasar yang bisa didiskusikan dengan developer Anda:

1. Pasang PerformanceObserver dengan type long-animation-frame di layout utama
2. Filter entri signifikan, misalnya blocking duration di atas 100 ms, supaya data tidak bising
3. Kirim ke analytics (GA4 event atau endpoint sendiri) beserta atribusi script-nya

Dari sana, laporan mingguan cukup menjawab satu pertanyaan: script mana yang paling sering muncul sebagai penyebab frame lambat di perangkat pengguna nyata, bukan di laptop developer.

Studi Kasus: Widget yang Tidak Dicurigai

Saat mengaudit performa Vetmo, platform pet care, INP di halaman booking berada di kisaran 350-400 ms pada perangkat Android kelas menengah. Pengujian lab tidak menunjukkan masalah berarti. Setelah data LoAF dari pengguna nyata terkumpul dua minggu, penyebab terbesarnya bukan kode aplikasi, melainkan script widget pihak ketiga yang melakukan inisialisasi berat setiap kali user menyentuh form.

Solusinya tidak dramatis: inisialisasi widget ditunda sampai interaksi pertama selesai. INP turun ke kisaran 150-200 ms tanpa menghapus fungsionalitas apa pun. Tanpa atribusi LoAF, kandidat tersangka kami ada belasan script dan proses coba-cobanya bisa berminggu-minggu.

Untuk langkah perbaikan setelah penyebab ditemukan, pola-polanya sama dengan optimasi INP pada umumnya: pecah tugas panjang, tunda script non-kritis, dan pindahkan komputasi berat keluar dari thread utama.

Pertanyaan Umum

Apakah marketer perlu memahami LoAF sedetail developer?

Tidak. Yang penting marketer paham konsepnya: data ini menunjukkan script penyebab halaman tersendat. Dengan begitu diskusi dengan developer berbasis data, bukan saling menebak.

Apakah LoAF menggantikan Lighthouse?

Tidak, keduanya saling melengkapi. Lighthouse menguji di kondisi lab yang terkontrol, LoAF merekam pengalaman pengguna nyata dengan perangkat dan jaringan beragam.

Bagaimana dengan pengguna Safari dan Firefox?

LoAF baru tersedia di browser Chromium. Untuk Indonesia hal ini masih representatif karena mayoritas trafik mobile memakai Chrome, tapi tetap perlakukan datanya sebagai sampel, bukan gambaran utuh.

Mulai dari Satu Halaman

Tidak perlu langsung memasang LoAF di seluruh website. Pilih satu halaman dengan INP terburuk di Search Console, kumpulkan data dua minggu, perbaiki satu script teratas, lalu ukur lagi. Siklus kecil yang berulang seperti ini hampir selalu mengalahkan proyek optimasi besar yang tidak pernah selesai.