Ironi PageSpeed Insights: Saat Google Saling Senggol, Web Kita Kena Getahnya
Menembus skor 100 di PageSpeed Insights adalah impian setiap web developer. Tapi bagaimana jadinya jika satu-satunya penghalang kesempurnaan itu justru berasal dari kode usang milik Google sendiri?
Pernahkah kamu menghabiskan waktu berjam-jam, menyeduh bergelas-gelas kopi, hanya demi melihat deretan angka hijau paripurna di alat uji coba performa web? Kamu sudah memeras otak untuk mengoptimasi gambar, membersihkan file CSS yang tidak terpakai, menunda eksekusi JavaScript yang berat, dan hasilnya sungguh memuaskan: Performa nyaris menyentuh 100, Aksesibilitas sempurna 100, dan SEO juga mantap di angka 100.
Namun, di tengah euforia kesempurnaan teknis itu, matamu tertuju pada satu noda peringatan berwarna kuning yang cukup menyebalkan. Skor Praktik Terbaik (Best Practices) tertahan di angka 81. Saat dicek lebih teliti, peringatannya berbunyi: "Pemroses peristiwa penghapusan muatan tidak digunakan lagi" atau "Menggunakan API yang tidak digunakan lagi".
Laporan PageSpeed Insights menampilkan peringatan API kadaluarsa.Mengenal Sang Biang Kerok: Script Iklan lidar.js
Siapa pelakunya? Apakah plugin pihak ketiga yang kurang terurus? Atau tema website yang usianya sudah puluhan tahun? Ternyata bukan keduanya. Jika kita membedah log peringatan tersebut secara teknis, URL yang ditunjuk oleh mesin audit PageSpeed adalah pagead2.googlesyndication.com, lebih spesifiknya pada pemanggilan aset bernama lidar.js.
Bagi para pengelola blog atau website yang memasang monetisasi, URL raksasa ini pasti sudah sangat tidak asing lagi. Ya, itu adalah baris kode pelacak inti milik Google AdSense (yang juga terafiliasi dengan DoubleClick Ads). Sumpah, ini adalah salah satu ironi paling jenaka di dunia pengembangan web modern.
Akar masalah teknisnya sebenarnya cukup lurus: file lidar.js masih secara aktif menggunakan fungsi event listener bernama unload di dalam JavaScript. Di era penjelajahan web saat ini, browser modern—terutama Google Chrome—sedang gencar-gencarnya melakukan pembersihan untuk membunuh API unload ini.
Alasannya sangat logis dan berpusat pada pengalaman pengguna. Penggunaan event tersebut sering kali merusak kapabilitas fitur Back/Forward Cache (bfcache). Jika fitur bfcache rusak atau dinonaktifkan gara-gara script ini, maka saat pengunjung menekan tombol kembali (Back) atau maju (Forward) di browser ponsel mereka, halaman harus memuat ulang seluruh aset dari nol. Tentu saja, ini membuat pengalaman berselancar terasa lambat dan patah-patah.
Analogi Kocak: Divisi A vs Divisi B
Kenyataan ini melahirkan sebuah komedi birokrasi. Coba bayangkan di dalam markas besar Google, terdapat dua divisi raksasa yang saling bekerja secara terisolasi dan kurang koordinasi.
Di satu sisi, ada Tim Lighthouse dan PageSpeed (kita sebut saja Divisi A). Mereka bertindak sebagai wasit yang sangat perfeksionis. Tugas utama mereka adalah mendikte standar web masa depan yang super cepat. Mesin audit yang mereka ciptakan bekerja seratus persen objektif dan buta huruf terhadap toleransi. Jika ada kode yang melanggar standar web modern, algoritma mereka akan langsung memberikan rapor merah, tanpa peduli apakah kode itu buatan tetangga sebelah atau buatan saudara sendiri.
Di sisi lain gedung, ada Tim Google Ads (kita sebut Divisi B). Ini adalah kapal induk pengeruk keuntungan raksasa yang pergerakannya sangat lambat. Mereka memiliki tanggung jawab berat memastikan script iklan mereka kompatibel dan berjalan mulus di jutaan website di seluruh pelosok bumi, merentang dari website berteknologi mutakhir hingga server usang peninggalan satu dekade lalu.
Faktanya, skor Performa utama tetap sukses menyentuh angka 99 di perangkat desktop.Jadi, narasi singkat yang terjadi di layar PageSpeed kita adalah: Google Divisi A sedang mengomel dan menyentil Google Divisi B, tetapi website kitalah yang dijadikan samsak tinju dan kehilangan skor sempurna seratus.
Misteri Keterlambatan Update Tim Google Ads
Melihat betapa mudahnya mendeteksi kesalahan tersebut, sebuah pertanyaan besar muncul: Mengapa jajaran engineer jenius di Tim Ads tidak langsung saja memperbarui kode lidar.js mereka ke fungsi yang jauh lebih modern?
Beban Triliunan Rupiah di Balik Sepotong Kode
Jawaban atas pertanyaan tersebut bermuara pada satu alasan klasik: stabilitas uang. Ekosistem iklan milik Google adalah mesin pencetak laba bernilai triliunan rupiah setiap tahunnya. Melakukan perombakan pada core tracking script—sekalipun hanya mengganti satu baris event listener—membawa risiko bisnis berskala global yang masif.
Sebagai perbandingan teknis, praktik masa kini menyarankan para pengembang untuk beralih menggunakan event yang bersahabat dengan bfcache. Berikut adalah perbedaan mendasarnya:
// Praktek Usang yang Masih Dipakai AdSense (Merusak bfcache)
window.addEventListener('unload', function(event) {
// Kirim data pelacakan terakhir ke server Google
navigator.sendBeacon('/log', analyticsData);
});
// Praktek Modern yang Direkomendasikan Chrome
window.addEventListener('pagehide', function(event) {
if (event.persisted === false) {
// Halaman benar-benar ditutup, aman kirim data
navigator.sendBeacon('/log', analyticsData);
}
});Proses Pengujian yang Sangat Alot
Bila script iklan yang baru ternyata gagal dieksekusi pada peramban tertentu, atau secara keliru gagal melacak klik tayangan secara presisi, kerugian pendapatan yang ditimbulkan bisa luar biasa menghancurkan. Kerugian ini tidak hanya dirasakan oleh para pencipta konten (publisher), tetapi juga menghantam margin laba Google secara langsung.
Oleh sebab itu, tahapan Jaminan Kualitas (Quality Assurance) untuk pembaruan script selevel AdSense membutuhkan durasi yang sangat panjang. Mereka secara logis akan lebih memilih mempertahankan kode warisan yang sudah terbukti puluhan tahun keandalannya dalam menghasilkan uang, alih-alih mengejar skor warna hijau di mesin audit buatan kolega mereka sendiri.
Ujian Sadis Mobile dan Bukti Ketangguhan Web
Jika kamu berpikir kelucuan sistem ini hanya berlaku di lingkungan PC, kamu keliru. Konsistensi birokrasi Google ini merambat hingga ke pengujian ranah seluler. Karena kode lidar.js tersebut diunduh dan dipanggil di semua jenis penampang layar, perayap PageSpeed versi perangkat bergerak (mobile) pasti akan menemukan dosa API yang sama.
Bahkan di simulasi jaringan yang diperlambat, perangkat seluler sanggup menembus skor 98.Namun, justru di situlah letak keajaibannya. Meraih skor Performa 98 pada simulasi perangkat bergerak sembari membawa beban eksternal berupa script iklan pihak ketiga adalah sebuah pencapaian yang bisa disejajarkan dengan menemukan unicorn. Ini sangat luar biasa gila.
Perlu diingat, ujian versi seluler dari Google dirancang dengan tingkat kekejaman yang tinggi. Mereka tidak mengeksekusi tes web kamu menggunakan koneksi nirkabel tingkat dewa atau telepon pintar kelas atas. Mereka sengaja mengatur simulasi pemuatan menggunakan kondisi jaringan seluler 4G yang diperlambat secara paksa, dipadukan dengan prosesor ponsel cerdas kelas menengah ke bawah. Bisa menembus angka nyaris sempurna di bawah tekanan seketat itu membuktikan bahwa fondasi teknis struktur kodemu memang sudah dibangun dengan sangat efisien dan berkinerja tinggi.
Ignorance is Bliss: Biarkan Saja
Pada konklusi akhirnya, peringatan menakutkan tentang API kadaluarsa ini tidak lebih dari sekadar teguran operasional standar. Peringatan tersebut bersarang secara eksklusif di dalam kategori Praktik Terbaik, bukan pada matrik kecepatan utama. Ini berarti teguran itu tidak memiliki dampak destruktif secara langsung terhadap nilai Core Web Vitals milikmu (seperti Largest Contentful Paint atau Total Blocking Time).
Mesin pencari utama tetap akan memandang situsmu sebagai entitas digital yang sangat cepat, andal, dan ramah pengguna. Mengorbankan potensi pemasukan finansial atau merusak pelacakan iklan hanya demi menambal satu skor kuning murni bukanlah keputusan bisnis yang rasional.
Terkadang, sebagai seorang pengembang dan kreator, ada momen di mana kita harus berdamai dengan sedikit ketidaksempurnaan. Biarlah insinyur Google menyelesaikan benang kusut birokrasi internal mereka pada waktunya sendiri. Bagi kita? Matikan alat penganalisis kecepatan itu sesekali, kembalilah ke layar penulisan, dan berfokuslah meracik kembali tulisan-tulisan bernas yang memang dinantikan oleh audiens setiamu.