Hvad er lazy load – og hvornår skal du (ikke) bruge det?

Lazy load gør siden hurtigere ved at vente med billeder længere nede. Her er reglerne for, hvornår du skal bruge det, hvornår du ikke skal, og hvordan det virker i WordPress.


Læsetid: 7 minutter


Lazy load betyder, at billeder og indlejret indhold længere nede på siden først hentes, når den besøgende scroller tæt på dem, så siden bliver hurtigere at vise og bruger mindre data.

Det lyder som noget, du bare skal slå til overalt. Det skal du ikke. Lazy load på det forkerte billede gør faktisk din side langsommere. Her får du forklaringen, reglerne for hvornår du skal (og ikke skal) bruge det, og hvordan det fungerer i WordPress.

Det korte svar

  • Hvad: Billeder og iframes uden for skærmen venter med at blive hentet, til brugeren nærmer sig dem.
  • Hvordan: Med HTML-attributten loading="lazy", som alle moderne browsere understøtter. Du behøver ikke JavaScript.
  • WordPress: Har haft indbygget lazy loading siden version 5.5. Du behøver ikke et ekstra plugin til det.
  • Undtagelsen: Det største billede øverst på siden (LCP-billedet) må aldrig lazy loades. Det skal have fetchpriority="high" i stedet.
  • Husk dimensioner: Billeder skal have width og height, ellers hopper layoutet, når de dukker op.

Hvad er lazy load helt præcist?

Når en browser åbner en side, læser den HTML-koden og begynder at hente alt, den finder: stylesheets, scripts, skrifttyper og billeder. Uden lazy load henter den også billeder, som ligger langt nede på siden, og som brugeren måske aldrig scroller ned til.

Med lazy load (på dansk “doven indlæsning”) udskyder browseren de billeder. Den henter dem først, når brugeren scroller tæt nok på. Siden kan sagtens vises, før alle billeder er hentet. Gevinsten er, at båndbredden i starten bruges på det, brugeren rent faktisk ser.

Browseren venter ikke, til billedet er helt inde på skærmen. Den starter i god tid, så billedet typisk er klar, når brugeren når derned. Afstanden afhænger af browseren og forbindelsen. I Chrome er den på en hurtig forbindelse omkring 1.250 pixels under skærmkanten, og du kan ikke selv ændre den.

Sådan ser det ud i koden

<img src="vaerksted.webp" width="1200" height="800"
     alt="Mekaniker skifter dæk på en varebil" loading="lazy">

<iframe src="https://www.youtube.com/embed/..." loading="lazy"></iframe>

Attributten virker på <img> og <iframe>, fx indlejrede YouTube-videoer og kort. Den virker ikke på baggrundsbilleder, der sættes med CSS. Browsere, der ikke kender attributten, ignorerer den bare og henter billedet som normalt.

Hvad betyder lazy load for Core Web Vitals?

Google måler sidens brugeroplevelse med tre Core Web Vitals. Lazy load påvirker dem forskelligt, og det er her, mange tager fejl.

MålingHvad den målerGod værdiEffekt af lazy load
LCP (Largest Contentful Paint)Hvor hurtigt det største element øverst vises≤ 2,5 sekunderBedre, når billeder længere nede venter. Meget værre, hvis selve LCP-billedet lazy loades.
INP (Interaction to Next Paint)Hvor hurtigt siden reagerer på klik og tryk≤ 200 millisekunderLille. Kan hjælpe lidt, fordi browseren har mindre at lave i starten.
CLS (Cumulative Layout Shift)Hvor meget layoutet hopper≤ 0,1Værre, hvis billederne mangler width og height. Neutral, hvis de har dem.
Grænseværdier fra Googles Core Web Vitals. INP erstattede FID i marts 2024.

Ser du stadig artikler, der forbinder lazy load med FID eller “Time to Interactive”, så er de forældede. Begge målinger er udgået. Lazy load er først og fremmest et værktøj til at få LCP ned og spare data.

Hvornår skal du ikke bruge lazy load?

Den vigtigste regel: Lazy load aldrig billeder, der er synlige, når siden åbner. Især ikke LCP-billedet, som typisk er dit hero-billede, dit første produktbillede eller billedet øverst i et blogindlæg.

Grunden er enkel. Med loading="lazy" venter browseren med at hente billedet, til den har regnet layoutet ud og kan se, at billedet er på skærmen. Det koster tid på præcis det element, Google bruger til at måle, hvor hurtigt din side føles.

Pas på

Mange ældre lazy load-plugins og nogle sidebyggere sætter lazy load på alle billeder, også logoet og hero-billedet. Har du både WordPress’ indbyggede lazy load og et plugin, der gør det samme med JavaScript, kan billederne øverst ende med at blive hentet sent. Brug én løsning, ikke tre.

Giv i stedet LCP-billedet høj prioritet:

<img src="hero.webp" width="1600" height="900"
     alt="Butikkens facade i Slagelse" fetchpriority="high">

fetchpriority="high" fortæller browseren, at billedet skal hentes før andre billeder. Kombinér det ikke med loading="lazy". Det giver ingen mening at bede browseren om både at vente og skynde sig.

Andre steder, hvor du skal være varsom

  • Slidere og karruseller øverst: Første slide skal hentes med det samme. De næste må gerne vente.
  • Logoet i headeren: Er altid synligt og bør ikke lazy loades.
  • Små ikoner: Er så små, at lazy load ikke giver noget. Brug hellere SVG.
  • Mobil vs. desktop: Et billede, der er under folden på mobil, kan være over folden på desktop. Test begge.

Hvordan fungerer lazy load i WordPress?

WordPress har lavet det meste af arbejdet for dig. Siden version 5.5 sætter WordPress automatisk loading="lazy" på billeder i indhold, uddrag, widgets og på billeder, temaet henter via WordPress’ egne funktioner. Det kræver, at billedet har width og height, og dem tilføjer WordPress selv på billeder fra mediebiblioteket.

Siden er det blevet klogere. I WordPress 6.3 begyndte WordPress at springe lazy load over på de første billeder og at sætte fetchpriority="high" på det billede, den gætter på er LCP-billedet. Gættet er godt, men ikke perfekt. Temaer og sidebyggere kan placere billeder på måder, WordPress ikke kan forudse.

Skal du så bruge et plugin?

Ikke kun til lazy load. Men et godt performance-plugin gør det mere præcist end WordPress alene. Vi bruger FlyingPress på vores egne og kundernes WordPress-sider. Det lazy loader billeder, iframes og baggrundsbilleder, lader dig udelukke de første billeder øverst, tilføjer manglende dimensioner, preloader de vigtige billeder og står også for billedoptimering. Så slipper du for at have flere plugins, der kæmper om det samme.

Webtos erfaring

Når vi overtager en langsom WordPress-side, er lazy load sjældent det, der mangler. Det typiske problem er det modsatte: Et gammelt plugin lazy loader hero-billedet, eller tre plugins gør det samme oven i hinanden. Vi rydder op, så der kun er én løsning, og sørger for, at billedet øverst hentes med det samme. Det er en af de hurtigste forbedringer af LCP, vi kender.

Sådan tjekker du, om lazy load virker rigtigt

  • Kør siden gennem PageSpeed Insights. Advarslen “Largest Contentful Paint-billedet blev indlæst med lazy loading” betyder, at dit LCP-billede skal undtages.
  • Højreklik på billedet øverst og vælg “Inspicér”. Der må ikke stå loading="lazy" eller en lazy-klasse fra et plugin.
  • Åbn fanen Netværk i udviklerværktøjerne, filtrér på billeder, og scroll ned. Billederne længere nede skal først dukke op i listen, når du scroller.
  • Tjek, at billederne har width og height, så layoutet ikke hopper (CLS).
  • Test på mobil, hvor folden ligger et andet sted end på desktop.

Lazy load er kun én del af en hurtig side. Store, ukomprimerede billeder er stadig store, når de endelig hentes. Start med billedoptimering: rigtige formater som WebP og AVIF, rigtige størrelser og gode ALT-tekster. Og står du med en langsom side på en WordPress-hjemmeside, er serveren ofte den største bremse.

Er din WordPress-side for langsom?

Vi hoster WordPress på danske servere med FlyingPress sat rigtigt op, så billeder, cache og lazy load spiller sammen.

Ofte stillede spørgsmål

Ja, når det bruges rigtigt. Det kan forbedre LCP, som er en del af Core Web Vitals, fordi browseren bruger båndbredden på det, der er synligt først. Googlebot kan godt se billeder, der lazy loades med loading=”lazy”. Brugt forkert på billedet øverst gør det LCP dårligere.

Ja. Siden WordPress 5.5 får billeder automatisk loading=”lazy”, og siden 6.3 forsøger WordPress selv at undtage de første billeder og give LCP-billedet fetchpriority=”high”. Du behøver altså ikke et separat lazy load-plugin.

I mange performance-plugins, fx FlyingPress, kan du undtage et antal billeder øverst på siden eller bestemte filnavne og klasser. I koden kan du fjerne loading-attributten eller sætte loading=”eager”. Udvikleren kan også bruge WordPress-filteret wp_img_tag_add_loading_attr.

Ikke med den indbyggede loading-attribut. Den virker kun på img og iframe. Baggrundsbilleder sat med CSS kræver JavaScript, og det klarer de fleste performance-plugins, herunder FlyingPress.

Ja, især indlejrede YouTube- eller Vimeo-videoer, som henter meget kode. Sæt loading=”lazy” på iframen, eller brug en løsning, der først viser et billede og henter afspilleren, når brugeren klikker.

Kilder: web.dev: Browser-level image lazy loading · Make WordPress Core: Lazy-loading images in 5.5 · web.dev: Web Vitals

“Lazy load handler om at vente med det, ingen kigger på endnu, ikke om at vente med det, alle kigger på først.”

Du er velkommen til at læse mere i nogle af vores andre blogindlæg

Del dette:

Fik du læst disse?

  • Illustration af AI-forordningens fire risikoniveauer: forbudt, højrisiko, gennemsigtighed og minimal risiko med eksempler (A.I. genereret)

    AI-forordningen for små og mellemstore virksomheder: Det skal I vide

    Af: Jannick Jensen • 29/10/2026
    EU’s AI-forordning bliver ofte omtalt, som om den kun handler om tech-giganter. Men den gælder også for den lille virksomhed, der bruger ChatGPT til marketing…
  • Illustration med fire spørgsmål før udgivelse af AI-billeder: ser det ægte ud, viser det en rigtig person, ligner det produktet, og kopierer det andres værk (A.I. genereret)

    AI-billeder og -video i markedsføring: Mærkning, ophavsret og rigtige personer

    Af: Jannick Jensen • 28/10/2026
    AI kan lave produktbilleder, kampagnevisuals og videoer på få minutter. Det sparer tid og penge, men det rejser også nye spørgsmål: Skal billederne mærkes? Hvem…
  • Illustration af en AI-politik i tre farver: grøn for offentlig information, gul for interne data i godkendte værktøjer og rød for adgangskoder og følsomme data (A.I. genereret)

    AI-politik for marketingteamet: Sådan laver I regler for AI (med skabelon)

    Af: Jannick Jensen • 27/10/2026
    De fleste marketingfolk bruger allerede ChatGPT, Claude eller Copilot hver dag. Spørgsmålet er, om de gør det på en måde, virksomheden kan stå inde for….