Ano talaga ang ginagawa ng lazy loading sa iyong largest contentful paint

Ang lazy loading ay desisyon sa pag-iskedyul, hindi mahikang pampabilis

Madalas ilarawan ang lazy loading bilang pagpapahusay sa performance, na totoo sa parehong paraan na ang hindi pag-empake ng maleta ay pagbabawas ng bigat. Nakakatulong ito dahil mas kaunti ang ginagawa ng browser sa simula.

Mahalaga ang pagkakaibang iyon para sa Largest Contentful Paint, na karaniwang pinaikli bilang LCP. Sinusukat ng LCP kung kailan na-render ang pinakamalaking makabuluhang elemento sa viewport. Sa maraming page, ang elementong iyon ay hero image. Sa iba, ito ay malaking heading, poster image, product photo, o content block.

Binabago ng lazy loading kung kailan hinihingi ang mga resource. Hindi nito pinapabilis ang pag-decode ng image, ang pagtugon ng server, o ang pag-render ng font. Kung mali ang iyong ila-lazy load, lalo na ang elementong nagiging LCP, sinasabi mo sa browser na maghintay bago kunin ang mismong bagay na kailangan nitong ipakita para pumasa sa Core Web Vitals.

Iyan ang dahilan kung bakit ang lazy loading ay parehong sobrang ginagamit at kulang sa pagkaunawa.

Ano ang ginagawa ng browser kapag nag-lazy load ka ng image

Karaniwang idinadagdag ang native image lazy loading nang ganito:

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

Sa loading='lazy', pinapayagan ang browser na ipagpaliban ang pagkuha ng image hanggang sa maisip nitong malamang na kakailanganin ang image. Sa praktika, gumagamit ang mga browser ng layo mula sa viewport, kundisyon ng network, sukat ng image, at iba pang heuristics. Ang eksaktong mga panuntunan ay mga detalye ng implementation at maaaring magbago.

Sa loading='eager', o kapag walang lazy attribute sa karamihan ng kaso, tinatrato ng browser ang image bilang bahagi ng normal na proseso ng loading. Kailangan pa rin nitong mag-prioritize sa pagitan ng CSS, JavaScript, fonts, images, at iba pang request, ngunit agad na nadidiskubre ang image.

Ibig sabihin, pangunahing naaapektuhan ng lazy loading ang tatlong yugto:

• Discovery: kung kailan napapansin ng browser ang resource.
• Request start: kung kailan nagsisimula ang network fetch.
• Render timing: kung kailan sa wakas nade-decode at naipipinta ang resource.

Para sa LCP, ang mapanganib ay ang request start. Kung huli magsimula ang request para sa LCP image, lahat ng kasunod nito ay mahuhuli rin.

Ang simpleng panuntunan: huwag kailanman i-lazy load ang LCP candidate

Kung ang isang image ay nakikita sa initial viewport at malamang na ito ang pinakamalaking contentful element, huwag itong i-lazy load.

Kabilang dito ang:

• hero images
• pangunahing product photos sa itaas ng fold
• malalaking article lead images
• malalaking background-like images na ipinatupad bilang <img>
• video poster images kapag ang poster ang pangunahing visual element

Hindi ma-render ng browser ang LCP image hangga't hindi ito nahihiling, naililipat, nade-decode, at naipipinta. Naglalagay ang lazy loading ng kawalan ng katiyakan bago ang unang hakbang. Kahit maliit na delay ay maaaring sapat para ilipat ang LCP mula katanggap-tanggap tungo sa mahina sa mas mabagal na koneksyon.

Ganito ang karaniwang pattern ng failure:

1. Nagpapadala ang server ng HTML.
2. Pina-parse ng browser ang image na nasa itaas ng fold.
3. May loading='lazy' ang image.
4. Naghihintay ang browser dahil sinasabi ng lazy-loading heuristic na maaari ito.
5. Patuloy na naglo-load ang CSS at JavaScript.
6. Mas huli kaysa dapat nagsisimula ang image request.
7. Huli ang LCP, kahit makatwirang optimized ang image file mismo.

Nakakainis ito dahil maaaring magmukhang maayos ang page sa code review. Hindi lang file size ang problema. Priority ito.

Kung nagbabasa ka ng lab output at sinusubukang alamin kung LCP nga ba ang isyu, sadyang praktikal ang aming gabay sa pagbabasa ng Lighthouse report nang hindi nagpapanic: paghiwalayin ang field data, lab hints, at fixes bago ka magsimulang magbago ng code. (Tandaan: kung case-sensitive ang iyong routing, gamitin ang eksaktong URL mula sa iyong CMS.)

Pagwawasto: gamitin ang aktuwal na internal URL

Ang tamang Wux article URL ay Paano magbasa ng Lighthouse report nang hindi nagpapanic. Nananatili ang punto: tukuyin ang LCP element bago baguhin ang loading behavior.

Kailan mapapahusay ng lazy loading ang LCP

Maaaring mapahusay ng lazy loading ang LCP nang hindi direkta kapag iniiwas nito ang mga hindi kritikal na resource sa daanan ng browser.

Isipin ang isang product page na may hero product image sa itaas at carousel ng labindalawang recommendation images sa ibaba ng fold. Kung lahat ng labintatlong image ay eager na maglo-load, maaaring gumugol ang browser ng bandwidth at connection slots sa mga image na hindi pa nakikita ng user. Sa limitadong network, maaari itong makipag-agawan sa hero image, CSS, o font files.

Makakatulong ang pag-lazy load sa below-fold carousel images para mas maagang mag-load ang LCP image dahil mas kaunting hindi kritikal na request ang nakikipagkumpitensya sa initial page load.

Ito ang lehitimong performance case para sa lazy loading:

• eager load ang above-the-fold LCP candidate
• lazy load ang images sa ibaba ng initial viewport
• iwasan ang mabibigat na script na huling nag-i-inject ng mahahalagang image
• panatilihin ang image dimensions sa HTML para maiwasan ang layout shifts

Ang lazy loading ay hindi LCP optimization sa sarili nito. Isa itong tool para sa resource prioritization. Nakakatulong ito kapag pinoprotektahan nito ang critical path.

Ang mas mahusay na pattern para sa LCP images

Para sa above-the-fold LCP image, ang layunin ay maaga itong madiskubre ng browser, maaga itong ma-request, at ma-render ito nang walang layout instability.

Ganito ang matibay na baseline:

<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'
>

Hindi dekorasyon ang mahahalagang bahagi:

• loading='eager' ay pumipigil sa lazy-loading delay.
• fetchpriority='high' ay nagsasabi sa browser na mahalaga ang image na ito.
• width at height ay naglalaan ng espasyo at nagpapababa ng layout shift.
• srcset at sizes ay pumipigil sa sobrang laking downloads.
• Maaaring magpababa ng transfer time ang modernong format kapag maingat na ginamit.

Kung naghahatid ka pa rin ng isang malaking JPEG sa bawat screen, maaaring mas mahalaga ang image format at responsive sizing kaysa sa lazy-loading attribute. Para sa praktikal na decision tree, tingnan ang kailan mas mahusay ang AVIF kaysa WebP at kailan hindi.

Kailangan ng dagdag na ingat ang background images

Hindi nadidiskubre ang CSS background images nang kasing-aga ng normal na HTML images. Kailangang kunin at i-parse ng browser ang CSS bago nito malaman ang tungkol sa mga ito. Kung ang iyong LCP element ay CSS background image, pinahirap mo na ang discovery.

Hindi ibig sabihin nito ay bawal ang background images. Ibig sabihin, dapat mong gamitin ang mga ito nang may intensyon.

Para sa decorative images, ayos lang ang CSS backgrounds. Para sa meaningful hero imagery, karaniwang mas mainam ang <img> o <picture> element dahil nakikita ito ng HTML parser, sumusuporta sa alt text, at mahusay gumana kasama ng responsive image attributes.

Kung kailangan mong gumamit ng CSS background para sa LCP image, isaalang-alang ang pag-preload nito:

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

Hindi rin magic wand ang preload. Ang pag-preload ng sobrang daming image ay lumilikha ng parehong priority problem sa ibang anyo. Gamitin ito para sa iisang image na tunay na mahalaga, hindi para sa bawat image sa design system.

Madalas mas pinapalala ng JavaScript lazy loading ang sitwasyon

Bago malawakang suportahan ang native lazy loading, maraming site ang gumamit ng JavaScript libraries na nagpapalit ng data-src papunta sa src pagkatapos ng page load o pagkatapos mag-fire ang intersection observer. Ginagawa pa rin ito ng ilan.

Maaari itong makatwiran para sa mahahabang article page o image-heavy galleries. Mahina itong pagpili para sa above-the-fold content.

Mabilis ang browser preload scanner, ngunit hindi nito ma-request ang image na nakatago ang URL sa custom attribute hangga't hindi tumatakbo ang JavaScript. Kung ang hero image mo ay nagsisimula bilang data-src='hero.jpg', naantala mo ang discovery sa likod ng script download, parsing, execution, at framework hydration.

Masamang trade iyon para sa LCP. Ilagay ang critical image URLs sa tunay na HTML. Hayaan ang browser na gawin ang trabaho nito.

Hindi palaging image problem ang LCP

Sa ilang page, text ang LCP element. Sa kasong iyon, maaaring kakaunti ang direktang epekto ng lazy loading images. Ang bottleneck mo ay maaaring render-blocking CSS, mabagal na server response, client-side rendering, o web fonts.

Mahalagang banggitin ang fonts dahil madalas silang nakatagong sanhi ng late text rendering. Maaaring maging LCP ang malaking heading, at maaaring ma-delay o mabago ng font loading behavior kung kailan naipipinta ang heading na iyon. Kung hindi gumagalaw ang metric dahil sa image work mo, direktang suriin ang LCP element sa halip na magpalagay. Sinasaklaw ng aming artikulo tungkol sa web fonts bilang performance win ang mga boring na fix na madalas gumana: mas kaunting weights, modernong formats, makatuwirang fallbacks.

Paano subukan ang mga pagbabago sa lazy loading nang hindi niloloko ang sarili

Huwag mag-test sa pamamagitan ng pagtitig sa page mo sa office Wi-Fi. Kailangan mong makita ang request timing.

Gamitin ang workflow na ito:

1. Buksan ang Chrome DevTools at mag-record ng Performance trace.
2. I-enable ang network throttling, tulad ng Fast 4G o Slow 4G.
3. I-reload ang page na naka-disable ang cache.
4. Hanapin ang LCP marker.
5. Tukuyin ang LCP element.
6. Sa Network panel, tingnan kung kailan nagsimulang mag-load ang resource na iyon.

Kung huli magsimula ang LCP resource, itanong kung bakit:

• Na-lazy load ba ito?
• Na-inject ba ito ng JavaScript?
• Nakatago ba ito sa CSS?
• Na-deprioritize ba ito sa likod ng ibang images?
• Mabagal bang tumugon ang server?

Pagkatapos, gumawa ng isang pagbabago at mag-retest. Nagiging magulo ang performance work kapag sabay-sabay binabago ng mga team ang image format, lazy loading, preloading, JavaScript bundles, at CDN settings sa iisang deployment. Maaaring mapahusay mo ang page, ngunit hindi mo malalaman kung aling pagbabago ang mahalaga.

Mahalaga rin ang field data. Kapaki-pakinabang ang lab tools para sa diagnosis, ngunit nag-iiba ang LCP ayon sa device, network, viewport, cache state, at geography. Gumamit ng real-user monitoring o Chrome User Experience Report data kapag kaya.

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

💡 Subukan ito: Panatilihing maliit at agad na na-load ang iyong LCP image sa pamamagitan ng pagdaan nito sa Image Compressor, para mabilis itong ma-render nang hindi nangangailangan ng lazy loading.

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

Isang praktikal na policy para sa karamihan ng websites

Para sa karamihan ng marketing sites, ecommerce pages, documentation sites, at publisher pages, sapat ang policy na ito:

• Above-the-fold primary image: eager load, isaalang-alang ang high fetch priority.
• Below-the-fold content images: lazy load.
• Icons at maliliit na UI assets: karaniwang hindi kailangang pag-isipan nang paisa-isa.
• CSS background hero: muling isaalang-alang bilang HTML image o mag-preload nang maingat.
• JavaScript-injected hero image: ayusin ang rendering architecture kung posible.
• Carousels: eager load lang ang unang visible slide; lazy load ang natitira.

May mga edge case. Gumaganda ang browser heuristics. Nagdaragdag ang frameworks ng automatic image components. Iniiwasan na ngayon ng ilang platform ang lazy loading sa images na nadedetect malapit sa viewport. Gayunpaman, hindi nagbabago ang prinsipyo: ang critical resources ay dapat maaga at malinaw; ang non-critical resources ay dapat maghintay.

Mahalaga ang lazy loading kapag ipinapahayag nito ang pagkakaibang iyon. Nakakasama ito kapag itinatago nito ang pinakamahalagang content mula sa browser hanggang matapos magsimulang matalo ang page sa LCP race.