Hva lazy loading faktisk gjør med Largest Contentful Paint

Lazy loading er en planleggingsbeslutning, ikke en trylleformel for fart

Lazy loading beskrives ofte som en ytelsesforbedring, noe som er sant på samme måte som at det å ikke pakke en koffert er en vektreduksjon. Det hjelper fordi nettleseren gjør mindre arbeid helt i starten.

Det skillet betyr noe for Largest Contentful Paint, vanligvis forkortet til LCP. LCP måler når det største meningsfulle elementet i visningsområdet blir rendret. På mange sider er dette elementet et hero-bilde. På andre er det en stor overskrift, et poster-bilde, et produktfoto eller en innholdsblokk.

Lazy loading endrer når ressurser blir forespurt. Det får ikke et bilde til å dekodes raskere, en server til å svare raskere eller en font til å rendres tidligere. Hvis du bruker lazy loading på feil ting, særlig elementet som blir LCP, ber du nettleseren vente med å hente akkurat det den må vise for å bestå Core Web Vitals.

Derfor er lazy loading både overbrukt og for lite forstått.

Hva nettleseren gjør når du lazy loader et bilde

Native image lazy loading legges vanligvis til slik:

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

Med loading='lazy' kan nettleseren utsette henting av bildet til den mener at bildet sannsynligvis trengs. I praksis bruker nettlesere avstand fra visningsområdet, nettverksforhold, bildedimensjoner og andre heuristikker. De nøyaktige reglene er implementasjonsdetaljer og kan endres.

Med loading='eager', eller uten lazy-attributt i de fleste tilfeller, behandler nettleseren bildet som en del av den normale innlastingsprosessen. Den må fortsatt prioritere mellom CSS, JavaScript, fonter, bilder og andre forespørsler, men bildet kan oppdages umiddelbart.

Dette betyr at lazy loading først og fremst påvirker tre faser:

• Oppdagelse: når nettleseren legger merke til ressursen.
• Forespørselsstart: når nettverkshentingen begynner.
• Rendringstidspunkt: når ressursen endelig kan dekodes og males.

For LCP er den farlige fasen forespørselsstart. Hvis forespørselen om LCP-bildet starter sent, forskyves alt etterpå også.

Den enkle regelen: aldri lazy load LCP-kandidaten

Hvis et bilde er synlig i det innledende visningsområdet og sannsynligvis er det største innholdsfulle elementet, skal du ikke bruke lazy loading på det.

Dette inkluderer:

• hero-bilder
• primære produktbilder over første skjermbilde
• store hovedbilder i artikler
• store bakgrunnslignende bilder implementert som <img>
• video-posterbilder når posteren er det viktigste visuelle elementet

Nettleseren kan ikke rendre LCP-bildet før det er forespurt, overført, dekodet og malt. Lazy loading legger inn usikkerhet før det første trinnet. Selv en liten forsinkelse kan være nok til å flytte LCP fra akseptabel til dårlig på en tregere tilkobling.

Et vanlig feilmønster ser slik ut:

1. Serveren sender HTML.
2. Nettleseren parser et bilde over første skjermbilde.
3. Bildet har loading='lazy'.
4. Nettleseren venter fordi lazy-loading-heuristikken sier at den kan.
5. CSS og JavaScript fortsetter å lastes.
6. Bildeforespørselen starter senere enn den burde.
7. LCP blir sen, selv om bildefilen i seg selv er rimelig optimalisert.

Dette er frustrerende fordi siden kan se ryddig ut i en kodegjennomgang. Problemet er ikke bare filstørrelse. Det er prioritet.

Hvis du leser laboratorieresultater og prøver å finne ut om LCP faktisk er problemet, er guiden vår til å lese en Lighthouse-rapport uten panikk bevisst praktisk: skill mellom feltdata, laboratorietips og rettelser før du begynner å endre kode. (Merk: hvis rutingen din skiller mellom store og små bokstaver, bruk den nøyaktige URL-en fra CMS-et ditt.)

Korrigering: bruk den faktiske interne URL-en

Den korrekte Wux-artikkel-URL-en er Slik leser du en Lighthouse-rapport uten panikk. Poenget står fast: identifiser LCP-elementet før du endrer innlastingsatferd.

Når lazy loading kan forbedre LCP

Lazy loading kan forbedre LCP indirekte når det holder ikke-kritiske ressurser unna nettleserens vei.

Se for deg en produktside med et hero-produktbilde øverst og en karusell med tolv anbefalingsbilder under første skjermbilde. Hvis alle tretten bildene lastes ivrig, kan nettleseren bruke båndbredde og tilkoblingsspor på bilder brukeren ennå ikke kan se. På et begrenset nettverk kan det konkurrere med hero-bildet, CSS eller fontfiler.

Lazy loading av karusellbildene under første skjermbilde kan hjelpe LCP-bildet å laste tidligere fordi færre ikke-kritiske forespørsler konkurrerer under den innledende sidelastingen.

Dette er det legitime ytelsestilfellet for lazy loading:

• last LCP-kandidaten over første skjermbilde eager
• lazy load bilder under det innledende visningsområdet
• unngå tunge skript som injiserer viktige bilder sent
• behold bildedimensjoner i HTML for å unngå layout shifts

Lazy loading er ikke en LCP-optimalisering i seg selv. Det er et verktøy for ressursprioritering. Det hjelper når det beskytter den kritiske stien.

Det bedre mønsteret for LCP-bilder

For et LCP-bilde over første skjermbilde er målet å få nettleseren til å oppdage det tidlig, forespørre det tidlig og rendre det uten layoutustabilitet.

Et solid utgangspunkt ser slik ut:

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

De viktige delene er ikke dekorative:

• loading='eager' hindrer lazy-loading-forsinkelse.
• fetchpriority='high' forteller nettleseren at dette bildet er viktig.
• width og height reserverer plass og reduserer layout shift.
• srcset og sizes hindrer overdimensjonerte nedlastinger.
• Et moderne format kan redusere overføringstid når det brukes med omhu.

Hvis du fortsatt serverer én stor JPEG til alle skjermer, kan bildeformat og responsiv dimensjonering bety mer enn lazy-loading-attributtet. For et praktisk beslutningstre, se når AVIF slår WebP og når det ikke gjør det.

Bakgrunnsbilder krever ekstra omtanke

CSS-bakgrunnsbilder oppdages ikke like tidlig som vanlige HTML-bilder. Nettleseren må hente og parse CSS før den vet om dem. Hvis LCP-elementet ditt er et CSS-bakgrunnsbilde, har du allerede gjort oppdagelsen vanskeligere.

Det betyr ikke at bakgrunnsbilder er forbudt. Det betyr at du bør være bevisst.

For dekorative bilder er CSS-bakgrunner helt greit. For meningsfulle hero-bilder er et <img>- eller <picture>-element vanligvis bedre fordi det er synlig for HTML-parseren, støtter alt-tekst og fungerer godt med attributter for responsive bilder.

Hvis du må bruke en CSS-bakgrunn for et LCP-bilde, bør du vurdere å preloade det:

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

Preload er heller ikke en tryllestav. Hvis du preloader for mange bilder, skaper du det samme prioriteringsproblemet i en annen drakt. Bruk det for det ene bildet som virkelig betyr noe, ikke for hvert bilde i designsystemet.

JavaScript-basert lazy loading gjør ofte ting verre

Før native lazy loading hadde bred støtte, brukte mange nettsteder JavaScript-biblioteker som byttet data-src inn i src etter sidelasting eller etter at en intersection observer ble utløst. Noen gjør det fortsatt.

Dette kan være rimelig for lange artikkelsider eller bildetunge gallerier. Det er et dårlig valg for innhold over første skjermbilde.

Nettleserens preload scanner er rask, men den kan ikke forespørre et bilde hvis URL-en er skjult i et egendefinert attributt før JavaScript kjører. Hvis hero-bildet ditt starter som data-src='hero.jpg', har du forsinket oppdagelsen bak skriptnedlasting, parsing, kjøring og framework-hydrering.

Det er en dårlig byttehandel for LCP. Legg kritiske bilde-URL-er i ekte HTML. La nettleseren gjøre jobben sin.

LCP er ikke alltid et bildeproblem

På noen sider er LCP-elementet tekst. I så fall kan lazy loading av bilder ha liten direkte effekt. Flaskehalsen kan være render-blokkerende CSS, treg serverrespons, klientbasert rendring eller webfonter.

Fonter er verdt å trekke frem fordi de ofte er en skjult årsak til sen tekstrendring. En stor overskrift kan bli LCP, og fontinnlastingsatferd kan forsinke eller endre når den overskriften males. Hvis bildearbeidet ditt ikke flytter metrikken, inspiser LCP-elementet direkte i stedet for å anta. Artikkelen vår om webfonter som en ytelsesgevinst dekker de kjedelige rettelsene som ofte virker: færre vekter, moderne formater, fornuftige fallbacks.

Slik tester du endringer i lazy loading uten å lure deg selv

Ikke test ved å stirre på siden din på kontorets Wi-Fi. Du må se tidspunktet for forespørsler.

Bruk denne arbeidsflyten:

1. Åpne Chrome DevTools og registrer en Performance-sporing.
2. Aktiver nettverksstruping, for eksempel Fast 4G eller Slow 4G.
3. Last inn siden på nytt med cache deaktivert.
4. Finn LCP-markøren.
5. Identifiser LCP-elementet.
6. I Network-panelet, sjekk når den ressursen begynte å laste.

Hvis LCP-ressursen starter sent, spør hvorfor:

• Ble den lazy loaded?
• Ble den injisert av JavaScript?
• Var den skjult i CSS?
• Ble den nedprioritert bak andre bilder?
• Var serveren treg til å svare?

Gjør deretter én endring og test på nytt. Ytelsesarbeid blir rotete når team endrer bildeformat, lazy loading, preloading, JavaScript-bundles og CDN-innstillinger i samme utrulling. Du kan forbedre siden, men du vet ikke hvilken endring som betydde noe.

Feltdata betyr også noe. Laboratorieverktøy er nyttige for diagnose, men LCP varierer etter enhet, nettverk, visningsområde, cache-tilstand og geografi. Bruk real-user monitoring eller Chrome User Experience Report-data når du kan.

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

💡 Prøv dette: Hold LCP-bildet ditt lite og eager-loaded ved å kjøre det gjennom Image Compressor, slik at det vises raskt uten behov for lazy loading.

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

En praktisk policy for de fleste nettsteder

For de fleste markedsføringssider, netthandelssider, dokumentasjonssider og publiseringssider er denne policyen nok:

• Primærbilde over første skjermbilde: last eager, vurder høy fetch priority.
• Innholdsbilder under første skjermbilde: lazy load.
• Ikoner og små UI-ressurser: vanligvis ikke verdt å tenke på enkeltvis.
• CSS-bakgrunns-hero: vurder på nytt som HTML-bilde eller preload forsiktig.
• JavaScript-injisert hero-bilde: fiks rendringsarkitekturen hvis mulig.
• Karuseller: last bare den første synlige sliden eager; lazy load resten.

Det finnes randtilfeller. Nettleserheuristikker blir bedre. Frameworks legger til automatiske bildekomponenter. Noen plattformer unngår nå lazy loading av bilder som oppdages nær visningsområdet. Likevel endres ikke prinsippet: kritiske ressurser bør være tidlige og tydelige; ikke-kritiske ressurser bør vente.

Lazy loading er verdifullt når det uttrykker dette skillet. Det er skadelig når det skjuler det viktigste innholdet for nettleseren til etter at siden allerede har begynt å tape LCP-løpet.