Kort svar: Lazy load udskyder billeder, til de nærmer sig viewporten – en gevinst for alt under folden og en fejl for alt over. De to klassiske problemer: LCP-billedet bliver lazy-loadet (og målingen lider), eller LQIP-pladsholdere bliver hængende som slørede billeder. Løsningen er den samme: undtag hero- og topbilleder fra lazy load i LiteSpeed Caches ekskluderingsfelter, og lad resten være.
Lazy load er tændt på de fleste sites – med god grund: hvorfor hente 40 billeder, når besøgende 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.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026; menupunkternes navne kan variere mellem LiteSpeed Cache-versioner. Diagrammet er en diagnoseillustration.
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: en miniature-udgave i lav kvalitet (genereret hos QUIC.cloud), der 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:
Når sidens største synlige element – typisk hero-billedet – lazy-loades, opdager browseren det sent, og LCP-målingen straffes hårdt; PageSpeed advarer direkte om det. Løsning i LiteSpeed Cache: tilføj billedet (filnavn eller en klasse) i Page Optimization → Media Excludes, så det undtages fra lazy load. Undtag kun de dokumenterede topbilleder – hero, logo og de første produktbilleder på kategorisider – og lad alt andet beholde lazy load. Hvordan du finder det præcise LCP-element, står i LCP-guiden.
Bliver billederne stående slørede, er det LQIP-pladsholderen, der aldrig afløses. Årsagerne i rækkefølge: JavaScript-fejl på siden stopper udskiftningen (tjek konsollen – og se JS-guiden, hvis defer/delay er indblandet); LQIP-genereringen hos QUIC.cloud er køet eller kvoten brugt (se kvote-guiden); eller cachen serverer en gammel HTML-udgave med forældede pladsholdere – purge og gentest. Vil du helt undgå fenomenet, kan LQIP slås fra: en ensfarvet pladsholder er mindre elegant, men fejler aldrig.
Popper billederne først frem, når man allerede er nået til dem, indlæses de for sent i scroll-forløbet. Det handler om margenen: lazy load bør starte hentningen et godt stykke før billedet rammer viewporten. Hurtig scroll på mobil afslører problemet tydeligst. Tjek også, at billederne har korrekte dimensioner i markup’en – manglende width/height får indholdet til at hoppe, når billederne lander, og så er det pludselig et CLS-problem oveni.
Balancen er rigtig, når Netværk-fanen viser, at topbilledet hentes i første bundt requests (uden lazy-attribut), billeder under folden først hentes ved scroll, ingen pladsholdere bliver hængende – og 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 tandløse.
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 10-minutters opsætning, ikke et enten/eller.
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 LCP-elementet selv er sløret/for sent.
WordPress sætter selv loading=”lazy” på de fleste billeder, og 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.
