Sekitar tahun 2023 awal, saya ingat betul. Waktu itu, euforia optimasi Technical SEO sedang tinggi-tingginya. Saya melihat banyak artikel menyarankan lazy load sebagai ‘solusi ajaib’ untuk kecepatan website. Tentu saja, saya ikut-ikutan. Saya pasang fitur ini di mana-mana. Semua gambar, video, bahkan beberapa komponen JavaScript saya setel lazy.

Apa yang saya yakini saat itu? Dengan lazy load, halaman akan jauh lebih ringan. Pengunjung bisa melihat konten utama lebih cepat. Logikanya, ini pasti bagus untuk SEO, kan?

Ternyata, keyakinan itu keliru besar. Bukannya bagus, skor Core Web Vitals website saya justru anjlok parah. Terutama di metrik LCP (Largest Contentful Paint) dan CLS (Cumulative Layout Shift).

Dulu, Saya Pikir Lazy Load Itu Solusi Sakti Semua Masalah Kecepatan

Dulu, konsep lazy load terdengar sangat menarik. Ide dasarnya sederhana: kenapa harus memuat semua elemen sekaligus? Lebih baik muat yang terlihat di layar saja. Sisanya menyusul saat pengguna scroll.

Di atas kertas, ini memang mengurangi beban awal halaman. Sumber daya server tidak langsung terkuras banyak. Pengguna yang hanya melihat bagian atas halaman pun tidak perlu menunggu seluruh konten selesai dimuat.

Namun, saya lupa satu hal penting. Google, melalui bot-nya, tidak selalu ‘melihat’ halaman seperti mata manusia. Atau lebih tepatnya, cara bot menginterpretasikan ‘apa yang penting’ itu berbeda.

Pengalaman saya waktu itu, setelah mengaktifkan lazy load secara agresif, saya melihat LCP di Google Search Console memburuk. Dari yang tadinya ‘Good’ di bawah 2.5 detik, tiba-tiba banyak URL masuk kategori ‘Needs Improvement’ di atas 4 detik. Ini jelas bukan efek yang diinginkan dari optimasi lazy load.

Ketika Lazy Load Malah Jadi Biang Kerok Core Web Vitals

Masalahnya muncul ketika elemen-elemen penting di ‘atas lipatan’ (above the fold) ikut di-lazy load. Bayangkan sebuah hero image besar, atau judul utama artikel. Jika elemen ini di-lazy load, browser harus menunggu instruksi JavaScript untuk memuatnya.

Ini memperlambat LCP secara signifikan. LCP mengukur waktu elemen terbesar di viewport terlihat oleh pengguna. Kalau elemen terbesar itu malah menunggu giliran dimuat, skor LCP pasti jelek.

Parahnya lagi, kadang elemen lazy load ini memicu CLS. Misalnya, ada ruang kosong yang disiapkan untuk gambar, lalu gambar muncul belakangan. Konten di bawahnya otomatis bergeser. Ini pengalaman pengguna yang buruk. Google tidak suka halaman yang ‘melompat-lompat’.

Saya ingat, di salah satu situs portofolio, ada galeri gambar di bagian atas. Setelah di-lazy load, pengunjung sering mengeluh. Mereka harus menunggu beberapa detik sampai gambarnya muncul, padahal sudah di bagian atas halaman.

Mengejar LCP dan CLS: Mengatur Prioritas Konten di Atas Lipatan

Jadi, bagaimana seharusnya optimasi lazy load dilakukan? Kuncinya ada di prioritas. Elemen yang krusial dan berada di ‘atas lipatan’ harus dimuat secepat mungkin. Mereka tidak boleh di-lazy load.

Ini termasuk gambar utama, judul, paragraf pembuka, atau tombol Call-to-Action yang vital. Google sendiri merekomendasikan untuk tidak menerapkan lazy load pada gambar di atas lipatan. Sejak Chrome 76, ada atribut loading="lazy" bawaan browser. Ini bagus, tapi kita harus pintar mengatur mana yang pakai dan mana yang tidak.

Saya mulai menganalisis setiap halaman menggunakan Lighthouse dan PageSpeed Insights. Saya identifikasi elemen terbesar yang jadi kandidat LCP. Lalu, saya pastikan elemen itu tidak di-lazy load. Untuk gambar, saya bisa pakai atribut loading="eager". Atau, saya hapus saja atribut loading="lazy" dari elemen tersebut.

Untuk menghindari CLS, penting juga untuk menentukan dimensi gambar secara eksplisit (width dan height) bahkan sebelum gambarnya dimuat. Ini agar browser bisa mereservasi ruang. Jadi, saat gambar muncul, tidak ada pergeseran tata letak.

Bukan Sekadar Pasang Plugin: Memahami Batasan dan Trade-off Optimasi Lazy Load

Banyak yang berpikir optimasi lazy load cuma soal pasang plugin. Saya juga dulu begitu. Padahal, ada batasan dan trade-off yang harus dipahami.

Misalnya, terlalu banyak skrip JavaScript yang menangani lazy load bisa menambah beban CPU pengguna. Ini terutama berlaku untuk implementasi lazy load lama yang masih mengandalkan JavaScript murni, bukan atribut loading="lazy" bawaan browser.

Googlebot sekarang jauh lebih canggih. Ia bisa me-render JavaScript. Jadi, sebagian besar konten yang di-lazy load akan tetap terindeks. Namun, jika implementasinya terlalu agresif atau salah, ini bisa menunda deteksi konten penting. Terutama jika konten tersebut adalah bagian dari konten utama yang ingin kita ranking.

Saya sempat mencoba berbagai skenario. Ada satu situs yang fokus pada fotografi. Gambar adalah segalanya. Setelah saya nonaktifkan lazy load untuk gambar pertama di setiap galeri, LCP-nya langsung membaik. Namun, total ukuran halaman jadi lebih besar. Ini adalah trade-off yang harus diterima: antara kecepatan awal (LCP) dengan total beban halaman.

Pengalaman Memilah Mana yang Boleh Nunggu, Mana yang Harus Tampil Duluan

Proses ini memang trial and error. Tidak ada satu resep pasti. Setiap website punya karakteristiknya sendiri. Ada yang dominan teks, ada yang kaya gambar atau video.

Saya belajar untuk selalu memprioritaskan pengalaman pengguna secara holistik. Ya, kecepatan itu penting, tapi bukan satu-satunya faktor. Kalau pengguna harus menunggu elemen penting muncul, itu bukan pengalaman yang baik, meskipun ‘secara teknis’ halaman jadi lebih cepat diukur.

Saya sering menggunakan Chrome DevTools untuk simulasi. Dengan fitur ‘Disable cache’ dan ‘Slow 3G’, saya bisa melihat bagaimana halaman dimuat di kondisi jaringan lambat. Di sana, akan terlihat jelas elemen mana yang memakan waktu paling lama untuk muncul.

Dari sana, saya bisa memutuskan: apakah elemen ini bisa di-lazy load? Atau justru harus dimuat secepatnya? Jika elemen itu berada di bagian bawah halaman, jauh di luar pandangan awal pengguna, lazy load adalah pilihan yang tepat. Tapi untuk elemen di bagian atas, pikirkan dua kali. Ada baiknya membaca juga: WordPress Lazy Load: When It Helps and When It Breaks untuk konteks implementasi di WordPress.

Setelah semua drama ini, saya menyadari satu hal. Lazy load itu alat. Sama seperti pisau. Di tangan yang tepat, dia bisa sangat membantu. Di tangan yang salah, bisa melukai. Terutama dalam konteks SEO, di mana setiap milidetik dan setiap pergeseran tata letak bisa dihitung oleh Google.

Mulai saat itu, setiap kali saya berencana menerapkan lazy load, saya selalu mulai dengan analisis menyeluruh terhadap critical rendering path dan prediksi dampak pada Core Web Vitals.