Apa yang sebenarnya dilakukan lazy loading terhadap largest contentful paint Anda

Lazy loading adalah keputusan penjadwalan, bukan mantra kecepatan

Lazy loading sering digambarkan sebagai peningkatan performa, yang benar dengan cara yang sama seperti tidak mengemas koper berarti mengurangi berat. Ia membantu karena browser melakukan lebih sedikit pekerjaan di awal.

Perbedaan itu penting untuk Largest Contentful Paint, yang biasanya disingkat LCP. LCP mengukur kapan elemen bermakna terbesar di viewport dirender. Di banyak halaman, elemen itu adalah hero image. Di halaman lain, elemen itu bisa berupa heading besar, poster image, foto produk, atau blok konten.

Lazy loading mengubah kapan resource diminta. Ia tidak membuat gambar didekode lebih cepat, server merespons lebih cepat, atau font dirender lebih awal. Jika Anda melakukan lazy load pada hal yang salah, terutama elemen yang menjadi LCP, Anda memberi tahu browser untuk menunggu sebelum mengambil hal yang justru harus ditampilkan agar lolos Core Web Vitals.

Itulah sebabnya lazy loading terlalu sering digunakan sekaligus kurang dipahami.

Apa yang dilakukan browser saat Anda melakukan lazy load pada gambar

Native image lazy loading biasanya ditambahkan seperti ini:

<img src='hero.jpg' loading='lazy' alt='...'>

Dengan loading='lazy', browser diizinkan menunda pengambilan gambar sampai ia memperkirakan gambar tersebut kemungkinan akan dibutuhkan. Dalam praktiknya, browser menggunakan jarak dari viewport, kondisi jaringan, dimensi gambar, dan heuristik lain. Aturan persisnya adalah detail implementasi dan dapat berubah.

Dengan loading='eager', atau tanpa atribut lazy dalam sebagian besar kasus, browser memperlakukan gambar sebagai bagian dari proses pemuatan normal. Browser tetap harus memprioritaskan antara CSS, JavaScript, font, gambar, dan permintaan lain, tetapi gambar dapat ditemukan segera.

Artinya, lazy loading terutama memengaruhi tiga fase:

• Discovery: kapan browser menyadari adanya resource.
• Request start: kapan pengambilan melalui jaringan dimulai.
• Render timing: kapan resource akhirnya dapat didekode dan digambar.

Untuk LCP, bagian yang berbahaya adalah request start. Jika permintaan gambar LCP dimulai terlambat, semua setelahnya ikut bergeser terlambat.

Aturan sederhana: jangan pernah melakukan lazy load pada kandidat LCP

Jika sebuah gambar terlihat di viewport awal dan kemungkinan menjadi elemen contentful terbesar, jangan lakukan lazy load pada gambar tersebut.

Ini mencakup:

• hero images
• foto produk utama di atas lipatan
• gambar pembuka artikel berukuran besar
• gambar besar mirip background yang diimplementasikan sebagai <img>
• video poster images ketika poster adalah elemen visual utama

Browser tidak dapat merender gambar LCP sampai gambar tersebut diminta, ditransfer, didekode, dan digambar. Lazy loading menyisipkan ketidakpastian sebelum langkah pertama. Bahkan penundaan kecil bisa cukup untuk memindahkan LCP dari dapat diterima menjadi buruk pada koneksi yang lebih lambat.

Pola kegagalan yang umum terlihat seperti ini:

1. Server mengirim HTML.
2. Browser mem-parse gambar di atas lipatan.
3. Gambar memiliki loading='lazy'.
4. Browser menunggu karena heuristik lazy-loading mengatakan itu boleh dilakukan.
5. CSS dan JavaScript terus dimuat.
6. Permintaan gambar dimulai lebih lambat dari seharusnya.
7. LCP terlambat, meskipun file gambar itu sendiri sudah cukup dioptimalkan.

Ini menjengkelkan karena halaman bisa terlihat rapi saat code review. Masalahnya bukan hanya ukuran file. Masalahnya adalah prioritas.

Jika Anda membaca output lab dan mencoba mencari tahu apakah LCP benar-benar masalahnya, panduan kami tentang membaca laporan Lighthouse tanpa panik sengaja dibuat praktis: pisahkan data lapangan, petunjuk lab, dan perbaikan sebelum mulai mengubah kode. (Catatan: jika routing Anda case-sensitive, gunakan URL persis dari CMS Anda.)

Koreksi: gunakan URL internal yang sebenarnya

URL artikel Wux yang benar adalah Cara membaca laporan Lighthouse tanpa panik. Intinya tetap sama: identifikasi elemen LCP sebelum mengubah perilaku loading.

Kapan lazy loading dapat meningkatkan LCP

Lazy loading dapat meningkatkan LCP secara tidak langsung ketika ia menjauhkan resource yang tidak kritis dari jalur kerja browser.

Bayangkan halaman produk dengan hero product image di bagian atas dan carousel berisi dua belas gambar rekomendasi di bawah lipatan. Jika ketiga belas gambar dimuat secara eager, browser mungkin menghabiskan bandwidth dan slot koneksi untuk gambar yang belum dapat dilihat pengguna. Pada jaringan terbatas, itu bisa bersaing dengan hero image, CSS, atau file font.

Melakukan lazy load pada gambar carousel di bawah lipatan dapat membantu gambar LCP dimuat lebih awal karena lebih sedikit permintaan non-kritis yang bersaing selama pemuatan halaman awal.

Inilah kasus performa yang sah untuk lazy loading:

• muat kandidat LCP di atas lipatan secara eager
• lazy load gambar di bawah viewport awal
• hindari skrip berat yang menyisipkan gambar penting secara terlambat
• pertahankan dimensi gambar di HTML untuk menghindari layout shift

Lazy loading bukan optimasi LCP dengan sendirinya. Ia adalah alat prioritisasi resource. Ia membantu ketika melindungi critical path.

Pola yang lebih baik untuk gambar LCP

Untuk gambar LCP di atas lipatan, tujuannya adalah membuat browser menemukannya lebih awal, memintanya lebih awal, dan merendernya tanpa ketidakstabilan layout.

Baseline yang solid terlihat seperti ini:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Bagian-bagian pentingnya bukan sekadar hiasan:

• loading='eager' mencegah penundaan lazy-loading.
• fetchpriority='high' memberi tahu browser bahwa gambar ini penting.
• width dan height mencadangkan ruang dan mengurangi layout shift.
• srcset dan sizes mencegah unduhan yang terlalu besar.
• Format modern dapat mengurangi waktu transfer jika digunakan dengan hati-hati.

Jika Anda masih menyajikan satu JPEG besar ke setiap layar, format gambar dan ukuran responsif mungkin lebih penting daripada atribut lazy-loading. Untuk decision tree praktis, lihat kapan AVIF mengalahkan WebP dan kapan tidak.

Background images memerlukan perhatian ekstra

CSS background images tidak ditemukan sedini gambar HTML biasa. Browser harus mengambil dan mem-parse CSS sebelum mengetahui keberadaannya. Jika elemen LCP Anda adalah CSS background image, Anda sudah membuat discovery menjadi lebih sulit.

Itu bukan berarti background images dilarang. Artinya, Anda harus sengaja dalam memilihnya.

Untuk gambar dekoratif, CSS backgrounds baik-baik saja. Untuk hero imagery yang bermakna, elemen <img> atau <picture> biasanya lebih baik karena terlihat oleh HTML parser, mendukung alt text, dan bekerja baik dengan atribut gambar responsif.

Jika Anda harus menggunakan CSS background untuk gambar LCP, pertimbangkan untuk melakukan preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload juga bukan tongkat ajaib. Melakukan preload terlalu banyak gambar menciptakan masalah prioritas yang sama dengan kostum berbeda. Gunakan untuk satu gambar yang benar-benar penting, bukan untuk setiap gambar di design system.

JavaScript lazy loading sering membuat keadaan lebih buruk

Sebelum native lazy loading didukung secara luas, banyak situs menggunakan library JavaScript yang menukar data-src menjadi src setelah page load atau setelah intersection observer aktif. Sebagian masih melakukannya.

Ini bisa masuk akal untuk halaman artikel panjang atau galeri yang sarat gambar. Ini adalah pilihan buruk untuk konten di atas lipatan.

Browser preload scanner cepat, tetapi tidak dapat meminta gambar yang URL-nya tersembunyi di atribut kustom sampai JavaScript berjalan. Jika hero image Anda dimulai sebagai data-src='hero.jpg', Anda telah menunda discovery di belakang unduhan skrip, parsing, eksekusi, dan framework hydration.

Itu pertukaran yang buruk untuk LCP. Letakkan URL gambar kritis di HTML yang nyata. Biarkan browser melakukan pekerjaannya.

LCP tidak selalu masalah gambar

Di beberapa halaman, elemen LCP adalah teks. Dalam kasus itu, lazy loading gambar mungkin hanya memiliki sedikit efek langsung. Bottleneck Anda mungkin CSS yang render-blocking, respons server yang lambat, client-side rendering, atau web fonts.

Font layak disebutkan karena sering menjadi penyebab tersembunyi dari rendering teks yang terlambat. Heading besar dapat menjadi LCP, dan perilaku loading font dapat menunda atau mengubah kapan heading tersebut digambar. Jika pekerjaan Anda pada gambar tidak menggerakkan metrik, inspeksi elemen LCP secara langsung alih-alih berasumsi. Artikel kami tentang web fonts sebagai kemenangan performa membahas perbaikan membosankan yang sering berhasil: lebih sedikit weight, format modern, fallback yang masuk akal.

Cara menguji perubahan lazy loading tanpa menipu diri sendiri

Jangan menguji dengan menatap halaman Anda di Wi-Fi kantor. Anda perlu melihat timing permintaan.

Gunakan workflow ini:

1. Buka Chrome DevTools dan rekam Performance trace.
2. Aktifkan network throttling, seperti Fast 4G atau Slow 4G.
3. Reload halaman dengan cache dinonaktifkan.
4. Temukan penanda LCP.
5. Identifikasi elemen LCP.
6. Di panel Network, periksa kapan resource tersebut mulai dimuat.

Jika resource LCP dimulai terlambat, tanyakan mengapa:

• Apakah ia di-lazy load?
• Apakah ia disisipkan oleh JavaScript?
• Apakah ia tersembunyi di CSS?
• Apakah ia dideprioritaskan di belakang gambar lain?
• Apakah server lambat merespons?

Lalu buat satu perubahan dan uji ulang. Pekerjaan performa menjadi berantakan ketika tim mengubah format gambar, lazy loading, preloading, bundle JavaScript, dan pengaturan CDN dalam deployment yang sama. Anda mungkin memperbaiki halaman, tetapi Anda tidak akan tahu perubahan mana yang penting.

Data lapangan juga penting. Tools lab berguna untuk diagnosis, tetapi LCP bervariasi berdasarkan perangkat, jaringan, viewport, status cache, dan geografi. Gunakan real-user monitoring atau data Chrome User Experience Report jika memungkinkan.

<!-- tool-cta:start -->

💡 Coba ini: Jaga gambar LCP Anda tetap kecil dan dimuat secara eager dengan menjalankannya melalui Image Compressor, agar cepat tampil tanpa memerlukan lazy loading.

<!-- tool-cta:end -->

Kebijakan praktis untuk sebagian besar website

Untuk sebagian besar situs marketing, halaman ecommerce, situs dokumentasi, dan halaman publisher, kebijakan ini sudah cukup:

• Gambar utama di atas lipatan: muat secara eager, pertimbangkan high fetch priority.
• Gambar konten di bawah lipatan: lazy load.
• Ikon dan aset UI kecil: biasanya tidak perlu dipikirkan satu per satu.
• CSS background hero: pertimbangkan ulang sebagai gambar HTML atau preload dengan hati-hati.
• Hero image yang disisipkan JavaScript: perbaiki arsitektur rendering jika memungkinkan.
• Carousels: muat slide pertama yang terlihat secara eager saja; lazy load sisanya.

Ada edge case. Heuristik browser membaik. Framework menambahkan komponen gambar otomatis. Sebagian platform kini menghindari lazy loading gambar yang terdeteksi dekat viewport. Namun, prinsipnya tidak berubah: resource kritis harus muncul lebih awal dan jelas; resource non-kritis harus menunggu.

Lazy loading bernilai ketika ia mengekspresikan perbedaan itu. Ia merugikan ketika menyembunyikan konten paling penting dari browser sampai halaman sudah mulai kalah dalam perlombaan LCP.