Hvad lazy loading faktisk gør ved din Largest Contentful Paint

Lazy loading er en planlægningsbeslutning, ikke en trylleformular for hastighed

Lazy loading beskrives ofte som en ydelsesforbedring, hvilket er sandt på samme måde som det er en vægtreduktion ikke at pakke en kuffert. Det hjælper, fordi browseren laver mindre arbejde fra starten.

Den skelnen betyder noget for Largest Contentful Paint, som normalt forkortes til LCP. LCP måler, hvornår det største meningsfulde element i viewporten er renderet. På mange sider er det element et hero-billede. På andre er det en stor overskrift, et poster-billede, et produktfoto eller en indholdsblok.

Lazy loading ændrer, hvornår ressourcer bliver anmodet om. Det får ikke et billede til at decode hurtigere, en server til at svare hurtigere eller en font til at rendere tidligere. Hvis du lazy loader det forkerte, især det element der bliver til LCP, beder du browseren om at vente med at hente netop det, den skal vise for at bestå Core Web Vitals.

Det er derfor, lazy loading både bruges for meget og forstås for lidt.

Hvad browseren gør, når du lazy loader et billede

Native lazy loading af billeder tilføjes normalt sådan:

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

Med loading='lazy' får browseren lov til at udsætte hentningen af billedet, indtil den vurderer, at billedet sandsynligvis snart bliver nødvendigt. I praksis bruger browsere afstand fra viewporten, netværksforhold, billeddimensioner og andre heuristikker. De præcise regler er implementeringsdetaljer og kan ændre sig.

Med loading='eager', eller uden lazy-attribut i de fleste tilfælde, behandler browseren billedet som en del af den normale indlæsningsproces. Den skal stadig prioritere mellem CSS, JavaScript, fonte, billeder og andre anmodninger, men billedet kan opdages med det samme.

Det betyder, at lazy loading primært påvirker tre faser:

• Opdagelse: hvornår browseren opdager ressourcen.
• Anmodningsstart: hvornår netværkshentningen begynder.
• Renderingstidspunkt: hvornår ressourcen endelig kan decodes og males.

For LCP er den farlige fase anmodningsstart. Hvis anmodningen om LCP-billedet starter sent, bliver alt efter den også forskudt.

Den enkle regel: lazy load aldrig LCP-kandidaten

Hvis et billede er synligt i den første viewport og sandsynligvis er det største contentful element, skal du ikke lazy loade det.

Det omfatter:

• hero-billeder
• primære produktfotos over folden
• store lead-billeder i artikler
• store baggrundslignende billeder implementeret som <img>
• video-poster-billeder, når posteren er det primære visuelle element

Browseren kan ikke rendere LCP-billedet, før det er blevet anmodet om, overført, decoded og malet. Lazy loading indsætter usikkerhed før det første trin. Selv en lille forsinkelse kan være nok til at flytte LCP fra acceptabel til dårlig på en langsommere forbindelse.

Et almindeligt fejlmønster ser sådan ud:

1. Serveren sender HTML.
2. Browseren parser et billede over folden.
3. Billedet har loading='lazy'.
4. Browseren venter, fordi lazy-loading-heuristikken siger, at den kan.
5. CSS og JavaScript fortsætter med at indlæse.
6. Billedanmodningen starter senere, end den burde.
7. LCP bliver sen, selvom selve billedfilen er rimeligt optimeret.

Det er frustrerende, fordi siden kan se ordentlig ud i et code review. Problemet er ikke kun filstørrelse. Det er prioritet.

Hvis du læser lab-output og forsøger at finde ud af, om LCP faktisk er problemet, er vores guide til at læse en Lighthouse-rapport uden panik bevidst praktisk: adskil feltdata, lab-hints og rettelser, før du begynder at ændre kode. (Bemærk: Hvis din routing skelner mellem store og små bogstaver, skal du bruge den præcise URL fra dit CMS.)

Rettelse: brug den faktiske interne URL

Den korrekte Wux-artikel-URL er Sådan læser du en Lighthouse-rapport uden panik. Pointen står fast: identificér LCP-elementet, før du ændrer indlæsningsadfærd.

Hvornår lazy loading kan forbedre LCP

Lazy loading kan forbedre LCP indirekte, når det holder ikke-kritiske ressourcer ude af browserens vej.

Forestil dig en produktside med et hero-produktbillede øverst og en karrusel med tolv anbefalingsbilleder under folden. Hvis alle tretten billeder indlæses eager, kan browseren bruge båndbredde og forbindelsespladser på billeder, brugeren endnu ikke kan se. På et begrænset netværk kan det konkurrere med hero-billedet, CSS eller fontfiler.

Lazy loading af karruselbillederne under folden kan hjælpe LCP-billedet med at indlæse tidligere, fordi færre ikke-kritiske anmodninger konkurrerer under den indledende sideindlæsning.

Dette er det legitime ydelsestilfælde for lazy loading:

• eager load LCP-kandidaten over folden
• lazy load billeder under den første viewport
• undgå tunge scripts, der indsætter vigtige billeder sent
• behold billeddimensioner i HTML for at undgå layout shifts

Lazy loading er ikke en LCP-optimering i sig selv. Det er et værktøj til ressourceprioritering. Det hjælper, når det beskytter den kritiske sti.

Det bedre mønster for LCP-billeder

For et LCP-billede over folden er målet at få browseren til at opdage det tidligt, anmode om det tidligt og rendere det uden layout-ustabilitet.

Et solidt udgangspunkt ser sådan ud:

<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 vigtige dele er ikke pynt:

• loading='eager' forhindrer lazy-loading-forsinkelse.
• fetchpriority='high' fortæller browseren, at billedet er vigtigt.
• width og height reserverer plads og reducerer layout shift.
• srcset og sizes forhindrer overdimensionerede downloads.
• Et moderne format kan reducere overførselstiden, når det bruges omhyggeligt.

Hvis du stadig serverer én stor JPEG til alle skærme, kan billedformat og responsiv størrelsestilpasning betyde mere end lazy-loading-attributten. For et praktisk beslutningstræ, se hvornår AVIF slår WebP, og hvornår det ikke gør.

Baggrundsbilleder kræver ekstra omtanke

CSS-baggrundsbilleder opdages ikke lige så tidligt som normale HTML-billeder. Browseren skal hente og parse CSS, før den kender til dem. Hvis dit LCP-element er et CSS-baggrundsbillede, har du allerede gjort opdagelsen sværere.

Det betyder ikke, at baggrundsbilleder er forbudte. Det betyder, at du bør være bevidst.

Til dekorative billeder er CSS-baggrunde fine. Til meningsfulde hero-billeder er et <img>- eller <picture>-element normalt bedre, fordi det er synligt for HTML-parseren, understøtter alt-tekst og fungerer godt med responsive billedattributter.

Hvis du skal bruge en CSS-baggrund til et LCP-billede, bør du overveje at preloade det:

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

Preload er heller ikke en tryllestav. Hvis du preloader for mange billeder, skaber du det samme prioritetsproblem i en anden forklædning. Brug det til det ene billede, der virkelig betyder noget, ikke til hvert billede i design systemet.

JavaScript lazy loading gør ofte tingene værre

Før native lazy loading havde bred support, brugte mange sites JavaScript-biblioteker, der skiftede data-src ind i src efter sideindlæsning eller efter en intersection observer blev aktiveret. Nogle gør det stadig.

Det kan være rimeligt for lange artikelsider eller billedtunge gallerier. Det er et dårligt valg for indhold over folden.

Browserens preload scanner er hurtig, men den kan ikke anmode om et billede, hvis URL er skjult i en brugerdefineret attribut, før JavaScript kører. Hvis dit hero-billede starter som data-src='hero.jpg', har du forsinket opdagelsen bag script-download, parsing, eksekvering og framework-hydration.

Det er en dårlig byttehandel for LCP. Læg kritiske billed-URL'er i rigtig HTML. Lad browseren gøre sit arbejde.

LCP er ikke altid et billedproblem

På nogle sider er LCP-elementet tekst. I det tilfælde har lazy loading af billeder måske kun lille direkte effekt. Din flaskehals kan være render-blokerende CSS, langsom serverrespons, client-side rendering eller webfonte.

Fonte fortjener at blive fremhævet, fordi de ofte er en skjult årsag til sen tekst-rendering. En stor overskrift kan blive LCP, og fontindlæsningsadfærd kan forsinke eller ændre, hvornår den overskrift males. Hvis dit billedarbejde ikke flytter metrikken, så inspicér LCP-elementet direkte i stedet for at antage. Vores artikel om webfonte som en ydelsesgevinst dækker de kedelige rettelser, der ofte virker: færre weights, moderne formater, fornuftige fallbacks.

Sådan tester du ændringer i lazy loading uden at narre dig selv

Test ikke ved at stirre på din side på kontorets Wi-Fi. Du skal se anmodningstidspunkter.

Brug denne arbejdsgang:

1. Åbn Chrome DevTools, og optag en Performance trace.
2. Aktivér netværksbegrænsning, f.eks. Fast 4G eller Slow 4G.
3. Genindlæs siden med cache deaktiveret.
4. Find LCP-markøren.
5. Identificér LCP-elementet.
6. Tjek i Network-panelet, hvornår den ressource begyndte at indlæse.

Hvis LCP-ressourcen starter sent, så spørg hvorfor:

• Blev den lazy loaded?
• Blev den indsat af JavaScript?
• Var den skjult i CSS?
• Blev den nedprioriteret bag andre billeder?
• Var serveren langsom til at svare?

Lav derefter én ændring, og test igen. Ydelsesarbejde bliver rodet, når teams ændrer billedformat, lazy loading, preloading, JavaScript-bundles og CDN-indstillinger i samme deployment. Du kan forbedre siden, men du ved ikke, hvilken ændring der betød noget.

Feltdata betyder også noget. Lab-værktøjer er nyttige til diagnose, men LCP varierer efter enhed, netværk, viewport, cachetilstand og geografi. Brug real-user monitoring eller Chrome User Experience Report-data, når du kan.

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

💡 Prøv dette: Hold dit LCP-billede lille og eager-loaded ved at køre det gennem Image Compressor, så det vises hurtigt uden behov for lazy loading.

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

En praktisk politik for de fleste websites

For de fleste marketingsites, ecommerce-sider, dokumentationssites og udgiversider er denne politik nok:

• Primært billede over folden: eager load, overvej høj fetch-prioritet.
• Indholdsbilleder under folden: lazy load.
• Ikoner og små UI-assets: normalt ikke værd at tænke på individuelt.
• CSS-baggrunds-hero: genovervej som HTML-billede, eller preload omhyggeligt.
• JavaScript-indsat hero-billede: ret renderingsarkitekturen, hvis det er muligt.
• Karruseller: eager load kun det første synlige slide; lazy load resten.

Der findes edge cases. Browserheuristikker bliver bedre. Frameworks tilføjer automatiske billedkomponenter. Nogle platforme undgår nu lazy loading af billeder, der registreres nær viewporten. Alligevel ændrer princippet sig ikke: kritiske ressourcer skal være tidlige og tydelige; ikke-kritiske ressourcer skal vente.

Lazy loading er værdifuldt, når det udtrykker den skelnen. Det er skadeligt, når det skjuler det vigtigste indhold for browseren, indtil siden allerede er begyndt at tabe LCP-løbet.