Apa sebenarnya kesan lazy loading terhadap Largest Contentful Paint anda

Lazy loading ialah keputusan penjadualan, bukan mantera kelajuan

Lazy loading sering digambarkan sebagai peningkatan prestasi, dan itu benar dalam erti yang sama seperti tidak mengemas beg pakaian ialah pengurangan berat. Ia membantu kerana pelayar melakukan kurang kerja pada peringkat awal.

Perbezaan itu penting untuk Largest Contentful Paint, biasanya dipendekkan kepada LCP. LCP mengukur bila elemen bermakna terbesar dalam viewport dirender. Pada banyak halaman, elemen itu ialah imej hero. Pada halaman lain, ia ialah tajuk besar, imej poster, foto produk, atau blok kandungan.

Lazy loading mengubah bila sumber diminta. Ia tidak membuat imej dinyahkod dengan lebih cepat, pelayan membalas dengan lebih cepat, atau fon dirender lebih awal. Jika anda melakukan lazy load pada perkara yang salah, terutamanya elemen yang menjadi LCP, anda sebenarnya menyuruh pelayar menunggu sebelum mengambil perkara yang paling perlu dipaparkan untuk melepasi Core Web Vitals.

Itulah sebabnya lazy loading sering digunakan secara berlebihan dan kurang difahami.

Apa yang dilakukan pelayar apabila anda melakukan lazy load pada imej

Lazy loading imej natif biasanya ditambah seperti ini:

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

Dengan loading='lazy', pelayar dibenarkan untuk menangguhkan pengambilan imej sehingga ia percaya imej itu berkemungkinan diperlukan. Dalam amalan, pelayar menggunakan jarak dari viewport, keadaan rangkaian, dimensi imej, dan heuristik lain. Peraturan tepat ialah butiran pelaksanaan dan boleh berubah.

Dengan loading='eager', atau tanpa atribut lazy dalam kebanyakan kes, pelayar menganggap imej sebagai sebahagian daripada proses pemuatan biasa. Ia masih perlu mengutamakan antara CSS, JavaScript, fon, imej, dan permintaan lain, tetapi imej itu boleh ditemui serta-merta.

Ini bermakna lazy loading terutamanya mempengaruhi tiga fasa:

• Penemuan: bila pelayar menyedari kewujudan sumber.
• Permulaan permintaan: bila pengambilan rangkaian bermula.
• Masa render: bila sumber akhirnya boleh dinyahkod dan dilukis.

Untuk LCP, yang berbahaya ialah permulaan permintaan. Jika permintaan imej LCP bermula lewat, semua selepasnya turut beralih lewat.

Peraturan mudah: jangan sekali-kali melakukan lazy load pada calon LCP

Jika imej kelihatan dalam viewport awal dan berkemungkinan menjadi elemen contentful terbesar, jangan lakukan lazy load padanya.

Ini termasuk:

• imej hero
• foto produk utama di atas lipatan
• imej utama artikel yang besar
• imej besar seperti latar belakang yang dilaksanakan sebagai <img>
• imej poster video apabila poster ialah elemen visual utama

Pelayar tidak boleh merender imej LCP sehingga ia telah diminta, dipindahkan, dinyahkod, dan dilukis. Lazy loading memasukkan ketidakpastian sebelum langkah pertama. Walaupun kelewatan kecil boleh mencukupi untuk mengalihkan LCP daripada boleh diterima kepada buruk pada sambungan yang lebih perlahan.

Corak kegagalan biasa kelihatan seperti ini:

1. Pelayan menghantar HTML.
2. Pelayar menghuraikan imej di atas lipatan.
3. Imej mempunyai loading='lazy'.
4. Pelayar menunggu kerana heuristik lazy-loading mengatakan ia boleh berbuat demikian.
5. CSS dan JavaScript terus dimuatkan.
6. Permintaan imej bermula lebih lewat daripada sepatutnya.
7. LCP lewat, walaupun fail imej itu sendiri telah dioptimumkan dengan munasabah.

Ini mengecewakan kerana halaman boleh kelihatan kemas dalam semakan kod. Masalahnya bukan saiz fail semata-mata. Masalahnya ialah keutamaan.

Jika anda membaca output makmal dan cuba menentukan sama ada LCP benar-benar isu, panduan kami untuk membaca laporan Lighthouse tanpa panik sengaja dibuat praktikal: asingkan data lapangan, petunjuk makmal, dan pembaikan sebelum anda mula menukar kod. (Nota: jika routing anda peka huruf besar/kecil, gunakan URL tepat daripada CMS anda.)

Pembetulan: gunakan URL dalaman sebenar

URL artikel Wux yang betul ialah Cara membaca laporan Lighthouse tanpa panik. Intinya masih sama: kenal pasti elemen LCP sebelum menukar tingkah laku pemuatan.

Bila lazy loading boleh meningkatkan LCP

Lazy loading boleh meningkatkan LCP secara tidak langsung apabila ia menghalang sumber tidak kritikal daripada mengganggu kerja pelayar.

Bayangkan halaman produk dengan imej produk hero di bahagian atas dan karusel dua belas imej cadangan di bawah lipatan. Jika kesemua tiga belas imej dimuatkan secara eager, pelayar mungkin menggunakan lebar jalur dan slot sambungan pada imej yang pengguna belum dapat lihat. Pada rangkaian terhad, itu boleh bersaing dengan imej hero, CSS, atau fail fon.

Melakukan lazy load pada imej karusel di bawah lipatan boleh membantu imej LCP dimuatkan lebih awal kerana lebih sedikit permintaan tidak kritikal bersaing semasa pemuatan halaman awal.

Inilah kes prestasi yang sah untuk lazy loading:

• muatkan calon LCP di atas lipatan secara eager
• lakukan lazy load pada imej di bawah viewport awal
• elakkan skrip berat yang menyuntik imej penting lewat
• kekalkan dimensi imej dalam HTML untuk mengelakkan anjakan susun atur

Lazy loading bukan pengoptimuman LCP dengan sendirinya. Ia ialah alat pengutamaan sumber. Ia membantu apabila ia melindungi laluan kritikal.

Corak yang lebih baik untuk imej LCP

Untuk imej LCP di atas lipatan, matlamatnya ialah memastikan pelayar menemukannya awal, memintanya awal, dan merendernya tanpa ketidakstabilan susun atur.

Asas yang kukuh kelihatan 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'
>

Bahagian penting ini bukan sekadar hiasan:

• loading='eager' menghalang kelewatan lazy-loading.
• fetchpriority='high' memberitahu pelayar bahawa imej ini penting.
• width dan height menempah ruang dan mengurangkan anjakan susun atur.
• srcset dan sizes mengelakkan muat turun bersaiz berlebihan.
• Format moden boleh mengurangkan masa pemindahan apabila digunakan dengan teliti.

Jika anda masih menyajikan satu JPEG besar kepada setiap skrin, format imej dan penskalaan responsif mungkin lebih penting daripada atribut lazy-loading. Untuk pepohon keputusan praktikal, lihat bila AVIF mengatasi WebP dan bila ia tidak.

Imej latar belakang memerlukan perhatian tambahan

Imej latar belakang CSS tidak ditemui seawal imej HTML biasa. Pelayar mesti mengambil dan menghuraikan CSS sebelum ia tahu tentang imej tersebut. Jika elemen LCP anda ialah imej latar belakang CSS, anda sudah menjadikan penemuan lebih sukar.

Itu tidak bermakna imej latar belakang dilarang. Ia bermakna anda perlu bertindak dengan sengaja.

Untuk imej hiasan, latar belakang CSS tidak menjadi masalah. Untuk imejan hero yang bermakna, elemen <img> atau <picture> biasanya lebih baik kerana ia kelihatan kepada penghuraian HTML, menyokong teks alt, dan berfungsi baik dengan atribut imej responsif.

Jika anda mesti menggunakan latar belakang CSS untuk imej LCP, pertimbangkan untuk melakukan preload padanya:

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

Preload juga bukan tongkat sakti. Melakukan preload pada terlalu banyak imej mewujudkan masalah keutamaan yang sama dalam bentuk berbeza. Gunakannya untuk satu imej yang benar-benar penting, bukan untuk setiap imej dalam sistem reka bentuk.

Lazy loading JavaScript sering memburukkan keadaan

Sebelum lazy loading natif disokong secara meluas, banyak laman menggunakan pustaka JavaScript yang menukar data-src kepada src selepas halaman dimuatkan atau selepas intersection observer dicetuskan. Ada yang masih melakukannya.

Ini boleh munasabah untuk halaman artikel panjang atau galeri yang sarat imej. Ia pilihan yang buruk untuk kandungan di atas lipatan.

Pengimbas preload pelayar adalah pantas, tetapi ia tidak boleh meminta imej yang URL-nya tersembunyi dalam atribut tersuai sehingga JavaScript berjalan. Jika imej hero anda bermula sebagai data-src='hero.jpg', anda telah melengahkan penemuan di belakang muat turun skrip, penghuraian, pelaksanaan, dan hydration framework.

Itu pertukaran yang buruk untuk LCP. Letakkan URL imej kritikal dalam HTML sebenar. Biarkan pelayar melakukan tugasnya.

LCP tidak selalu masalah imej

Pada sesetengah halaman, elemen LCP ialah teks. Dalam kes itu, lazy loading imej mungkin mempunyai sedikit kesan langsung. Bottleneck anda mungkin CSS yang menyekat render, respons pelayan yang perlahan, rendering sisi klien, atau fon web.

Fon wajar diberi perhatian kerana ia sering menjadi punca tersembunyi rendering teks yang lewat. Tajuk besar boleh menjadi LCP, dan tingkah laku pemuatan fon boleh melengahkan atau mengubah bila tajuk itu dilukis. Jika kerja imej anda tidak menggerakkan metrik, periksa elemen LCP secara langsung dan bukannya membuat andaian. Artikel kami tentang fon web sebagai kemenangan prestasi merangkumi pembaikan membosankan yang sering berkesan: kurang weight, format moden, fallback yang munasabah.

Cara menguji perubahan lazy loading tanpa memperdaya diri sendiri

Jangan uji dengan sekadar merenung halaman anda pada Wi-Fi pejabat. Anda perlu melihat masa permintaan.

Gunakan aliran kerja ini:

1. Buka Chrome DevTools dan rekod Performance trace.
2. Dayakan network throttling, seperti Fast 4G atau Slow 4G.
3. Muat semula halaman dengan cache dinyahdayakan.
4. Cari penanda LCP.
5. Kenal pasti elemen LCP.
6. Dalam panel Network, semak bila sumber itu mula dimuatkan.

Jika sumber LCP bermula lewat, tanya sebabnya:

• Adakah ia di-lazy load?
• Adakah ia disuntik oleh JavaScript?
• Adakah ia tersembunyi dalam CSS?
• Adakah keutamaannya diturunkan di belakang imej lain?
• Adakah pelayan lambat memberi respons?

Kemudian buat satu perubahan dan uji semula. Kerja prestasi menjadi berserabut apabila pasukan menukar format imej, lazy loading, preloading, berkas JavaScript, dan tetapan CDN dalam deployment yang sama. Anda mungkin menambah baik halaman, tetapi anda tidak akan tahu perubahan mana yang benar-benar penting.

Data lapangan juga penting. Alat makmal berguna untuk diagnosis, tetapi LCP berbeza mengikut peranti, rangkaian, viewport, keadaan cache, dan geografi. Gunakan pemantauan pengguna sebenar atau data Chrome User Experience Report apabila boleh.

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

💡 Cuba ini: Pastikan imej LCP anda kecil dan dimuatkan secara eager dengan menjalankannya melalui Image Compressor, supaya ia dipaparkan dengan cepat tanpa memerlukan lazy loading.

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

Dasar praktikal untuk kebanyakan laman web

Untuk kebanyakan laman pemasaran, halaman ecommerce, laman dokumentasi, dan halaman penerbit, dasar ini sudah mencukupi:

• Imej utama di atas lipatan: muatkan secara eager, pertimbangkan keutamaan fetch yang tinggi.
• Imej kandungan di bawah lipatan: lazy load.
• Ikon dan aset UI kecil: biasanya tidak berbaloi difikirkan satu demi satu.
• Hero latar belakang CSS: pertimbangkan semula sebagai imej HTML atau preload dengan teliti.
• Imej hero yang disuntik JavaScript: betulkan seni bina rendering jika boleh.
• Karusel: muatkan hanya slaid pertama yang kelihatan secara eager; lazy load selebihnya.

Ada kes pinggiran. Heuristik pelayar bertambah baik. Framework menambah komponen imej automatik. Sesetengah platform kini mengelakkan lazy loading imej yang dikesan berhampiran viewport. Namun, prinsipnya tidak berubah: sumber kritikal harus awal dan jelas; sumber tidak kritikal harus menunggu.

Lazy loading bernilai apabila ia menyatakan perbezaan itu. Ia memudaratkan apabila ia menyembunyikan kandungan paling penting daripada pelayar sehingga selepas halaman sudah mula kalah dalam perlumbaan LCP.