Lazy loading — Udskyd indlæsning af billeder og ressourcer
Lazy loading udskyder indlæsning af off-screen billeder — loading=lazy er en browser-native attribut der forbedrer LCP og pageload-tid.
Lazy loading er en performance-teknik der udskyder indlæsning af billeder og ressourcer til de er ved at blive synlige i brugerens viewport. For SEO er lazy loading relevant fordi det reducerer den initiale sideindlæsningstid og forbedrer LCP — men fejlagtig lazy loading af LCP-billedet er en hyppig årsag til dårlige Core Web Vitals. HTML5’s native loading=lazy-attribut er den anbefalede implementering og understøttes af alle moderne browsere.
Hvad er lazy loading?
Lazy loading er en performance-teknik der udskyder indlæsning af ressourcer — typisk billeder og iframes — til de faktisk er nødvendige. I stedet for at downloade alle billeder på en side ved indlæsning, ventes der til brugeren scroller tæt på dem.
Resultatet: færre bytes downloadet ved sideindlæsning, hurtigere Time to First Byte, bedre Largest Contentful Paint og lavere dataforbrug for brugeren.
Native lazy loading — loading=“lazy”
Browser-native lazy loading er den enkleste implementering og kræver blot en HTML-attribut:
<img src="billede.jpg" alt="Beskrivelse" loading="lazy">
Browseren beslutter selv hvornår billedet skal hentes baseret på viewport-afstand. Understøttet i alle moderne browsere siden 2019-2020.
Det samme gælder iframes:
<iframe src="https://maps.google.com/..." loading="lazy"></iframe>
Lazy loading og LCP — den kritiske undtagelse
Her er den vigtigste regel for lazy loading og SEO:
Above-the-fold billeder og LCP-billedet bør ALDRIG have loading=“lazy”.
LCP (Largest Contentful Paint) måler hvornår det største synlige element er loadet. Hvis det primære hero-billede lazy loades, forsinkes LCP direkte — fordi browseren ikke starter download af billedet før det er “tæt nok” på viewport, og dermed er siden synlig men billedet mangler.
Korrekt strategi:
- Above-the-fold billeder:
loading="eager"(eller slet ingen loading-attribut, da eager er standard) - Below-the-fold billeder:
loading="lazy"
<!-- Forsidebillede — IKKE lazy -->
<img src="hero.jpg" alt="..." loading="eager" fetchpriority="high">
<!-- Produktbilleder nederst på siden -->
<img src="produkt-5.jpg" alt="..." loading="lazy">
JavaScript-baseret lazy loading — Intersection Observer
Inden browser-native lazy loading eksisterede, brugte udviklere JavaScript og Intersection Observer API:
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
observer.unobserve(img);
}
});
});
document.querySelectorAll('img[data-src]').forEach(img => {
observer.observe(img);
});
HTML med data-src:
<img data-src="billede.jpg" alt="...">
JavaScript-lazy loading er stadig relevant for mere komplekse scenarier og legacy-support, men native loading="lazy" er den foretrukne løsning.
Lazy loading af scripts og iframes
Scripts kan lazy loades ved at bruge defer og async attributter, eller ved dynamisk at tilføje script-tags til DOM’en:
// Indlæs chat-widget kun når brugeren ruller til bunden
window.addEventListener('scroll', () => {
if (scrollNearBottom()) {
const script = document.createElement('script');
script.src = '/chat-widget.js';
document.body.appendChild(script);
}
}, { once: true });
Tunge iframes (YouTube-videoer, Google Maps) er fremragende kandidater til lazy loading — en enkelt YouTube-iframe kan tilføje hundredvis af KB til sideindlæsningen.
Googlebot og lazy loading
Googlebot understøtter loading="lazy" og indlæser lazy-loadede ressourcer under rendering. Men der er en vigtig detalje:
Googlebot scroller ikke sider ved rendering. Det simulerer viewport-indlæsning men scroller ikke manuelt ned. Googles rendering er dog forbedret, og Googlebot indlæser nu typisk lazy-loadede ressourcer.
For at være sikker på at indhold i billeder (alt-tekst, filnavne) og tekst nær lazy-loadede billeder indexeres korrekt, bør HTML-strukturen ikke afhænge af at JavaScript-lazy loading er kørt.
Lazy loading og CLS
Lazy-loadede billeder uden angivne dimensions (width og height) kan forårsage Cumulative Layout Shift — sideindholdet hopper når billedet loades og fylder pladsen. Angiv altid dimensions:
<img src="billede.jpg" alt="..." loading="lazy" width="800" height="600">
Browseren reserverer plads til billedet og undgår layout shift.
Ofte stillede spørgsmål
Skal alle billeder have loading=“lazy”?
Nej. Above-the-fold billeder og LCP-billedet bør ikke lazy loades. Brug lazy loading på billeder der er under folden — typisk alt andet end hero- og topbilleder.
Kan lazy loading skade SEO?
Forkert implementeret lazy loading kan skade LCP (hvis det bruges på above-the-fold billeder) eller føre til at Googlebot ikke ser billeder. Korrekt implementering forbedrer performance og skader ikke SEO.
Er loading=“lazy” understøttet i alle browsere?
Alle moderne browsere understøtter loading="lazy". IE understøtter det ikke, men IE har ingen signifikant markedsandel i 2026.
Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- Core Web Vitals regressioner — Når LCP, INP og CLS pludselig forværres
- CSS — Cascading Style Sheets og SEO
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- RUM vs. syntetisk monitoring — To syn på web performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi
Ofte stillede spørgsmål
- Hvad er lazy loading?
- Lazy loading er en teknik der udskyder indlæsning af ressourcer — typisk billeder og iframes — indtil de er nær den synlige del af siden (viewporten). Frem for at downloade alle billeder på siden ved den initiale sideindlæsning, downloades kun de billeder brugeren faktisk er ved at se. HTML5 implementerer lazy loading nativt via loading-attributten: <img src=billede.jpg loading=lazy alt=beskrivelse>. Det reducerer den initiale sideindlæsningstid og databrug markant.
- Hvad bør ikke have lazy loading — og hvad er LCP-problemet?
- Det vigtigste element der ikke bør have lazy loading er LCP-elementet — det største synlige indhold i viewporten ved sideindlæsning. Hvis LCP-billedet har loading=lazy, instruerer du browseren om at udskyde indlæsningen af det allermost prioriterede element, hvilket forringer Largest Contentful Paint direkte. Brug aldrig lazy loading på hero-billeder, overskriftsbilleder eller andre elementer der er synlige above the fold ved sideindlæsning. Brug kun loading=lazy på billeder der starter udenfor viewporten.
- Hvad er forskellen på native lazy loading og JavaScript lazy loading?
- Native lazy loading bruger HTML-attributten loading=lazy direkte på <img> og <iframe> elementer og er understøttet af alle moderne browsere uden JavaScript. Det er den anbefalede løsning: enkel, fejlsikker og fungerer selv hvis JavaScript er deaktiveret eller fejler. JavaScript lazy loading (via Intersection Observer API eller biblioteker som lazysizes) er en ældre tilgang der giver mere kontrol men kræver JavaScript-eksekvering. Brug native lazy loading til billeder og native iframe-embedding.
- Hvad er loading=eager og hvornår bør det bruges?
- loading=eager er HTML-attributten der eksplicit instruerer browseren om at indlæse en ressource straks — det er standard browser-adfærd, så det er sjældent nødvendigt at angive det. Det er dog relevant som eksplicit override på CMS-platforme der automatisk tilføjer loading=lazy til alle billeder: sæt loading=eager på LCP-billedet for at fortryde den automatiske lazy loading og sikre at hero-billedet indlæses med høj prioritet. Kombiner med fetchpriority=high for maksimal LCP-forbedring.
- Hvad er Intersection Observer API og hvornår er det bedre end native lazy loading?
- Intersection Observer API er en JavaScript-API der lader dig reagere præcist når et element er ved at blive synligt i viewporten. Det er mere fleksibelt end native lazy loading fordi du kan kontrollere margin, threshold og adfærd ved synlighed. Intersection Observer er bedre end native lazy loading i disse situationer: du vil lazy-loade indhold der ikke er billeder (fx React-komponenter, charts, animationer), du vil styre præcist hvor langt fra viewport indlæsning skal starte, og du vil implementere virtuel scrolling med dynamisk indhold.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- Core Web Vitals regressioner — Når LCP, INP og CLS pludselig forværres
- CSS — Cascading Style Sheets og SEO
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- RUM vs. syntetisk monitoring — To syn på web performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi