Lazy load og LQIP: billeder, der loader forkert eller for sent

Kort svar: Lazy load udskyder billeder, til de nærmer sig skærmen – en gevinst for alt under folden og en fejl for alt over den. De klassiske problemer er, at LCP-billedet bliver lazy-loadet, eller at LQIP-pladsholdere bliver hængende som slørede billeder. Løsningen er den samme: undtag hero- og topbilleder fra lazy load under Page Optimization → Media Excludes i LiteSpeed Cache (eller lad Viewport Images gøre det), og lad resten være lazy.

Fagligt gennemgået: 2. oktober 2026

Lazy load er slået til på de fleste sites – med god grund: hvorfor hente 40 billeder, når den besøgende kun ser fem? Men funktionen har én blind vinkel: den ved ikke, hvilke billeder der er vigtige. Når den udskyder det store hero-billede eller viser slørede pladsholdere for længe, bliver hastighedsfunktionen selv til hastighedsproblemet.

Menupunkternes navne kan variere lidt mellem versioner af LiteSpeed Cache. Navnene herunder følger LiteSpeeds egen dokumentation pr. oktober 2026.

Før du ændrer noget: Mål LCP på forsiden og en typisk underside (mobil og desktop), før du retter, så du kan se effekten. Ret én indstilling ad gangen, ryd cachen bagefter, og test i et privat vindue – ellers ser du din egen, gamle udgave af siden.

Sådan virker lazy load og LQIP

Med lazy load får billederne først deres rigtige kilde, når de nærmer sig skærmen. I mellemtiden står der en pladsholder – enten en tom flade eller en LQIP (low quality image placeholder): en miniatureudgave i lav kvalitet, som LiteSpeed Cache får genereret hos QUIC.cloud, og som giver et sløret preview i stedet for et hul. Godt brugt føles siden hurtigere, layoutet står fast, og der spares båndbredde. Fejlene opstår, når mekanikken rammer billeder, der skulle have været hentet med det samme:

De relevante indstillinger i LiteSpeed Cache ligger tre steder:

Fane under Page Optimization	Indstillinger	Bruges til
Media Settings	Lazy Load Images, Add Missing Sizes, Responsive Placeholder, LQIP Cloud Generator, LQIP Quality, LQIP Minimum Dimensions	Slå lazy load og pladsholdere til og fra
Media Excludes	Lazy Load Image Excludes, Class Name Excludes, Parent Class Name Excludes, Lazy Load URI Excludes, LQIP Excludes	Undtage bestemte billeder eller sider
VPI	Viewport Images, Viewport Images Cron	Automatisk finde billeder over folden via QUIC.cloud

Typiske symptomer og hvor du skal kigge

Symptom	Sandsynlig årsag	Første kontrol
PageSpeed: „Largest Contentful Paint image was lazily loaded“	LCP-billedet er ikke undtaget	Fejl 1
Billeder står slørede og bliver aldrig skarpe	LQIP afløses ikke (JavaScript-fejl, kø eller gammel cache)	Fejl 2
Billeder popper først frem, når du er nået til dem	Hentningen starter for sent, eller der er dobbelt lazy load	Fejl 3
Indholdet hopper, når billeder lander	Manglende width/height eller pladsholder uden dimensioner	Fejl 3 og CLS-guiden

1. Fejl 1: LCP-billedet lazy-loades

Når sidens største synlige element – typisk hero-billedet – lazy-loades, opdager browseren det sent, og LCP-målingen straffes hårdt; PageSpeed Insights advarer direkte om det. Find først det præcise LCP-element; fremgangsmåden står i guiden om LCP i WordPress.

Undtag derefter billedet under Page Optimization → Media Excludes. Du har tre muligheder:

• Lazy Load Image Excludes: en del af filnavnet eller URL’en, fx hero-forside.
• Lazy Load Image Class Name Excludes: en CSS-klasse på selve billedet, fx den klasse temaet eller sidebyggeren sætter på hero-sektionens billede.
• Lazy Load Image Parent Class Name Excludes: en klasse på elementet omkring billedet – praktisk, når billederne skifter, men sektionen er den samme.

hero-forside
site-logo
wp-post-image

Eksemplet viser typiske værdier, én pr. linje: et filnavn, logoets klasse og klassen på det fremhævede billede. Brug dit eget temas klasser – de varierer. Undtag kun de dokumenterede topbilleder: hero, logo og de første produktbilleder på kategorisider. Lad alt andet beholde lazy load.

Udvikler du selv temaet, kan du også sætte attributten data-no-lazy="1" direkte på billedet. LiteSpeed Cache springer billeder med den attribut over.

2. Lad Viewport Images finde topbillederne

Manuelle undtagelser virker, men de skal vedligeholdes. Fanen VPI (Viewport Images) lader QUIC.cloud analysere siderne og finde de billeder, der står over folden på den enkelte side. LiteSpeed Cache undtager dem derefter fra lazy load automatisk. Med Viewport Images Cron slået til behandles køen i baggrunden.

VPI kræver, at sitet er forbundet til QUIC.cloud, og analysen sker side for side, så nye sider får først gavn af det, når de er behandlet. Hvad tjenesterne koster i kreditter, står i guiden om QUIC.cloud-kreditter og kvoter. Bruger du VPI, så hold de manuelle undtagelser korte – fx kun logo og den faste hero på forsiden – så de to mekanismer ikke modarbejder hinanden.

3. Fejl 2: slørede pladsholdere hænger

Bliver billederne stående slørede, er det LQIP-pladsholderen, der aldrig afløses af det rigtige billede. Gå årsagerne igennem i denne rækkefølge:

1. JavaScript-fejl: udskiftningen styres af JavaScript. Åbn browserens konsol, og se efter røde fejl. Er defer eller delay af JavaScript indblandet, så se guiden om JavaScript efter defer og delay.
2. LQIP-køen hos QUIC.cloud: er genereringen sat i kø, eller er kvoten brugt, kan pladsholderne mangle eller være forældede.
3. Gammel cache: cachen kan servere en gammel HTML-udgave med forældede pladsholdere. Ryd cachen, og test igen i et privat vindue.

Vil du helt undgå fænomenet, kan du slå LQIP Cloud Generator fra. Så bruger LiteSpeed Cache en ensfarvet eller SVG-baseret pladsholder (Responsive Placeholder). Den er mindre elegant, men fejler aldrig. Billeder, der er for små til, at LQIP giver mening, kan du holde ude med LQIP Minimum Dimensions eller LQIP Excludes.

4. Fejl 3: billeder dukker for sent op

Popper billederne først frem, når den besøgende allerede er nået til dem, indlæses de for sent i scroll-forløbet. God lazy load starter hentningen et stykke før billedet rammer skærmen. LiteSpeed Cache har ingen dokumenteret indstilling for den afstand, så hvis billederne konsekvent kommer for sent, skal du lede efter årsager, der forsinker hentningen:

• Dobbelt lazy load: temaet, sidebyggeren eller et andet optimeringsplugin lazy-loader også. To lag oven på hinanden giver forsinkelse og nogle gange billeder, der aldrig vises. Lad kun ét værktøj stå for lazy load; se guiden om LiteSpeed Cache sammen med andre optimeringsplugins.
• Delay af JavaScript: forsinkes lazy load-scriptet til første brugerinteraktion, starter ingen billeder, før den besøgende rører siden.
• Store, uoptimerede filer: starter hentningen til tiden, men tager filen lang tid, hjælper ingen indstilling. Komprimér og server WebP eller AVIF; se guiden om billedoptimering i QUIC.cloud.

Hurtig scroll på mobil afslører problemet tydeligst. Tjek samtidig, at billederne har korrekte dimensioner i markup’en. Manglende width og height får indholdet til at hoppe, når billederne lander – og så er det pludselig et CLS-problem oveni. Indstillingen Add Missing Sizes under Media Settings kan tilføje manglende dimensioner automatisk, og Responsive Placeholder sørger for, at pladsholderen fylder det samme som billedet.

5. Glem ikke baggrundsbilleder og sidebyggere

Mange hero-sektioner bruger et CSS-baggrundsbillede i stedet for et almindeligt img-element. Baggrundsbilleder hentes først, når CSS’en er indlæst og regnet igennem, og nogle sidebyggere lazy-loader dem med deres egen mekanisme. Er LCP-elementet et baggrundsbillede, hjælper LiteSpeeds billedundtagelser ikke nødvendigvis. Overvej at bruge et rigtigt billedelement i heroen, eller preload billedet; se guiden om preload, preconnect og fetchpriority.

6. Verificér balancen

Balancen er rigtig, når alle punkterne her holder:

• Netværk-fanen i DevTools viser, at topbilledet hentes i første bundt requests – uden lazy-attribut og uden pladsholder.
• Billeder under folden hentes først, når du scroller.
• Ingen pladsholdere bliver hængende, heller ikke på langsom mobilforbindelse.
• LCP-målingen er forbedret eller uændret god.

Test på mobilstørrelse: folden ligger et andet sted dér, og et billede kan være „over folden“ på desktop og langt nede på mobil. Gentag tjekket efter temaopdateringer – ændrede klassenavne kan gøre gamle undtagelser virkningsløse.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• Dårlig LCP i WordPress: find det rigtige LCP-element
• CLS i WordPress: billeder, fonts, bannere og dynamiske elementer
• Billedoptimering i QUIC.cloud: WebP, AVIF og køen, der hænger
• WordPress hosting hos Hostious – LiteSpeed og NVMe som standard i alle pakker

Ofte stillede spørgsmål om lazy load

Skal lazy load være slået til overhovedet?

Ja, på stort set alle sites – gevinsten på billedtunge sider er stor. Kunsten er undtagelserne: topbillederne skal hentes straks, resten må vente. Det er en kort opsætning, ikke et enten-eller.

Hvorfor er mine billeder slørede i PageSpeed-screenshots?

Målingen fanger ofte øjeblikket, hvor LQIP-pladsholderne stadig vises – det kan være helt normalt. Problemet er der kun, hvis pladsholderne også hænger for rigtige besøgende, eller hvis LCP-elementet selv er sløret eller kommer for sent.

Native lazy load eller LiteSpeeds – hvad gælder?

WordPress sætter selv loading=”lazy” på de fleste billeder og springer typisk det første store billede over. LiteSpeed Cache lægger sin egen JavaScript-baserede håndtering ovenpå, bl.a. for LQIP. Med LiteSpeeds lazy load aktiv er det dens undtagelseslister, der bestemmer – så det er dér, du arbejder.

Koster LQIP og Viewport Images noget?

Begge genereres hos QUIC.cloud og bruger derfor af kontoens kreditter eller kvote. Hvor meget der er gratis, ændrer sig, så tjek din QUIC.cloud-konto. Vil du undgå afhængigheden, kan du bruge manuelle undtagelser og en simpel pladsholder i stedet.