Doven indlæsning kan reducere sidestart og datamængde, men hvis det bruges forkert, bremser det synligt indhold og forringer kernemålinger. I dette indlæg viser jeg, hvorfor lazy loading ofte forringer webperformance, hvordan LCP lider under det, og hvilke konkrete indstillinger der virkelig gør billeder hurtigere.
Centrale punkter
Forudgående: Følgende centrale aspekter hjælper dig med hurtigt at genkende faldgruber ved billedindlæsning.
- Over folden Aldrig lazy load, ellers lider LCP under det.
- Prioritering Anmodningerne er afgørende for heltebilleder.
- dimensioner sætte (bredde/højde) sænker CLS markant.
- Pladsholdere forbedrer oplevelsen ved rulning.
- messer I stedet for at gætte: Identificer og test LCP-billedet.
Hvorfor lazy loading bremser synlige billeder
Mange Sider markerer det første, største billede fejlagtigt med indlæsning="doven" og udsætter dermed starten af downloadet. Browseren indlæser derefter de ressourcer, den anser for mest presserende, og venter med heltebilledet, indtil det er tæt på visningsområdet. Netop dette billede er imidlertid ofte det LCP-element, der præger opfattelsen af hastigheden. Martin Splitt advarede udtrykkeligt mod denne praksis, fordi Largest Contentful Paint forskydes så målbart (kilde: [3]). Derfor skifter jeg konsekvent alle Above-the-Fold-billeder til Eager Loading i stedet for at blokere rendering.
Netværksprioritering i praksis
Browser prioriterer normalt automatisk synligt indhold, men lazy loading ophæver denne rækkefølge. Hvis du indstiller lazy på et vigtigt billede, vil det blive hentet på et senere tidspunkt, mens CSS, JS eller mindre vigtige medier optager båndbredde. Dette bremser især mobile enheder med svagere CPU'er og forbindelser. Jeg kontrollerer rækkefølgen af anmodninger i DevTools og indstiller om nødvendigt preload eller prioriteter korrekt. En uddybende forklaring på Prioritering af anmodninger hjælper med at løse flaskehalse på en målrettet måde.
Data: LCP-sammenligninger
Tal fra HTTP Archive viser, at sider med lazy loading i gennemsnit har dårligere LCP-værdier end sider uden (kilde: [1]). Medianen på 75. percentilen var 2.922 ms uden lazy loading og 3.546 ms med lazy loading – et fald på ca. 624 ms. Særligt bemærkelsesværdigt: WordPress-sider lå på 3.495 ms uden lazy loading og 3.768 ms med. A/B-tests på web.dev bekræfter: Deaktivering af lazy loading på arkivsider forbedrede LCP med ca. 4 % (desktop) og 2 % (mobil) (kilde: [1]). Disse effekter er for store til at kunne afskrives som målefejl.
| Scenarie | LCP (75. percentil) | Bemærkning |
|---|---|---|
| Uden lazy loading | 2.922 ms | BedreMedianen ifølge HTTP Archive [1] |
| Med Lazy Loading | 3.546 ms | DårligereMedian (+624 ms) [1] |
| WordPress uden Lazy | 3.495 ms | Lavere som med Lazy [1] |
| WordPress med Lazy | 3.768 ms | HøjereLCP uden Lazy [1] |
| TwentyTwentyOne A/B (desktop) | -4 % | Forbedring efter deaktivering [1] |
| TwentyTwentyOne A/B (mobil) | -2 % | Overskud trods flere bytes [1] |
Manglende dimensioner og CLS
Uden at fast bredde og højde springer layoutet, så snart billederne endelig vises. Dette skaber en kumulativ layoutforskydning, som forstyrrer interaktionen og udløser yderligere reflows. Derfor angiver jeg altid bredde- og højdeattributter eller bruger CSS-aspektforhold. På den måde reserverer browseren plads, inden dataene ankommer. Siden virker mere rolig og opbygger synligt indhold på en planerbar måde (kilde: [5]).
Mobile scenarier og langsomme netværk
På På mobile enheder har enhver forsinkelse ved start-download større betydning. CPU-tid til JavaScript, svingende latenstider og energibesparelser øger omkostningerne ved sene billedanmodninger. Lazy Loading flytter anmodninger netop til denne svagere fase. Derfor prioriterer jeg kritiske ressourcer, reducerer JS og sørger for korte kæder. På den måde kan enheden håndtere den første visning uden at det vigtigste billede bliver overset.
Eager Loading til Above-the-Fold
Die Enkel regel: Det, som brugeren ser med det samme, indlæser jeg med det samme. For LCP-billedet indstiller jeg loading="eager" eller fjern Lazy-attributten helt. Derudover kan rel="preload" i passende tilfælde hjælpe med at starte hentningen endnu tidligere. Jeg overvåger effekten med Lighthouse og Core Web Vitals-metrikkerne. Hvis du vil dykke dybere ned i emnet, finder du en god introduktion her: Læs Core Web Vitals korrekt.
Målrettet brug af Intersection Observer
For Jeg bruger fortsat lazy loading til indhold under folden – men med omtanke. Intersection Observer giver mig mulighed for at indstille tærskler, hvorfra offscreen-billeder indlæses lidt tidligere. På den måde undgår jeg flimrende opbygninger, når brugerne scroller hurtigt. Jeg kombinerer dette med databinding for først at indstille billedkilder efter behov og samtidig respektere prioriteter. Nyttige praktiske detaljer findes i artiklen om Krydsningsobservatør.
Placeringsholdere og opfattet hastighed
Sløring-Placeholders, LQIP eller BlurHash dækker huller, indtil det rigtige billede kommer frem. Det reducerer den oplevede ventetid og udjævner overgangen. Jeg sørger for, at pladsholdere bruger de endelige dimensioner for ikke at skabe spring. Samtidig komprimerer jeg kraftigt, så pladsholderne selv næsten ikke bruger båndbredde. Disse foranstaltninger understøtter brugeroplevelsen uden at forsinke de rigtige downloads (kilde: [6]).
E-handel: Raster, uendelig rulning og prioriteter
Butik-Kataloger indlæser mange forhåndsvisningsbilleder, mens brugerne ruller flydende. For aggressive lazy-strategier bremser genindlæsningen og skaber grå felter. Derfor sætter jeg generøse forhåndsindlæsningstærskler og lav, men ikke minimal kvalitet for thumbnails. Det er vigtigt at indlæse de første linjer af rasteret hurtigt for at sikre en jævn start. Infinite Scroll drager desuden fordel af en tynd, prioriteret pipeline til det næste sæt produktbilleder (kilde: [7]).
Måling: Sådan finder jeg LCP-billedet
På I Chrome DevTools markerer jeg LCP-elementet, kontrollerer dets URL og observerer vandfaldspositionen. Hvis anmodningen er forsinket, fjerner jeg Lazy eller øger prioriteten. Derefter kontrollerer jeg filmstrip-visningen for at vurdere den synlige fremgang. PageSpeed Insights leverer desuden felt- og laboratoriedata. Kun ved hjælp af denne måling kan jeg se, om ændringerne har en reel effekt (kilde: [1]).
Konfiguration: Undgå hyppige anti-mønstre
Mange Plugins indstiller Lazy Loading globalt for alle billeder, inklusive logoer, sliders og hero-elementer. Jeg deaktiverer Lazy for synlige medier, indstiller pladsholdere for offscreen-billeder og definerer faste mål. Desuden kontrollerer jeg, om scripts initialiseres for sent og dermed bremser billedanmodninger. CDN-regler må ikke overskrive prioriteter, der hjælper LCP-billedet. Disse justeringsskruer fjerner typiske fejlkilder (kilder: [1], [8]).
Spar båndbredde uden at ofre LCP
Lazy Loading reducerer billedbytes drastisk, hvilket skåner serveren og datavolumenet. Testene viser besparelser på flere gange ved den første rendering, fordi offscreen-billeder ikke længere er nødvendige (kilde: [1]). Denne fordel retfærdiggør brugen, så længe jeg behandler LCP-billedet beskyttet. Jeg skelner derfor strengt mellem Above-the-Fold (eager/preload) og resten (lazy/intersecting). På den måde kombinerer jeg færre bytes med hurtig første opbygning.
Teknisk tjekliste for korrekt implementering
Min Checklisten holder implementeringen enkel og sikker: Jeg identificerer LCP-billedet, deaktiverer Lazy og angiver entydige mål. Jeg tester omhyggeligt rækkefølgen af anmodninger, prioritet og forhåndsindlæsning. Til offscreen-billeder bruger jeg Intersection Observer og meningsfulde tærskler. Jeg overvåger effekterne i Lighthouse og i felten for at undgå regressioner. Derudover hjælper browservejledninger til lazy loading med at identificere faldgruber tidligt (kilder: [5], [8]).
Responsive billeder: srcset, sizes og art direction
Korrekt Anvendte responsive billeder forhindrer over- eller underforsyning. Jeg bruger srcset med breddeskriptorer og en præcis Størrelser, der svarer til den reelle layoutbredde. Et for generisk størrelser="100vw" tvinger mobile enheder til ofte at indlæse store filer. Til art direction eller forskellige beskæringer bruger jeg . med medier-forespørgsler. Vigtigt: Også responsive varianter får faste dimensioner eller en CSS-billedformat, så CLS forbliver lav. På den måde sparer siden bytes uden at gå på kompromis med den visuelle kvalitet.
Brug Priority Hints og Preload korrekt
For LCP-billedet giver jeg browseren klare anvisninger: fetchpriority="høj" på <img> signalerer betydning og supplerer loading="eager". Jeg bruger Preload sparsomt: <link rel="preload" as="image"> kan fremskynde hentningen, men bør anvende de samme parametre (inkl. imagesrcset og billedeformater) som det endelige img for at undgå dobbeltdownloads. Jeg undgår forhåndsindlæsning af billeder uden for Above-the-Fold, så linjen forbliver fri. Derudover betaler det sig at oprette DNS og TLS tidligt til billed-CDN – men uden inflationære hints, der udvander prioriteterne.
Baggrundsbilleder vs. IMG: LCP-venlige markup-beslutninger
Mange Brug af hero-sektioner baggrundsbillede. Baggrundsgrafikker er dog ofte ikke LCP-berettigede – browseren vælger da et andet element som LCP, mens baggrundsbilledet stadig bruger meget båndbredde. Jeg renderer hovedmotivet som ægte <img> i markup, valgfrit med objekt-tilpasning, for at opfylde layoutønsker. På den måde kan browseren prioritere, måle og vise elementet korrekt og tidligt. Dekorative teksturer forbliver som CSS-baggrunde, kritiske motiver kommer som img/billede.
Afkodning, gengivelse og hovedtråd
Billede-Afkodning koster CPU. Til offscreen-billeder indstiller jeg decoding="async", så udpakningen ikke blokerer hovedtråden. Ved LCP-billedet lader jeg decoding="auto", så browseren selv kan afgøre, om synkron afkodning muliggør den hurtigst mulige visning. Jeg undgår ekstra JS-biblioteker til lazy loading, hvis native browserfunktioner er tilstrækkelige – enhver initialisering kan binde hovedtråden og forsinke leveringen af heltebilledet.
Frameworks, hydration og CMS-standardindstillinger
Moderne Frameworks og CMS har deres egne billedstandarder. WordPress markerer som standard mange billeder som lazy – jeg overskriver dette specifikt for logoer, hero og slider i det første viewport. I React/Next, Vue/Nuxt eller Svelte sørger jeg for, at billedkomponenterne ikke skjuler hero-billedet bag hydration. Server-side rendering og streaming hjælper, men kun hvis billedet allerede er i HTML og refereres tidligt. Jeg undgår at indsætte LCP-billedet først via JS – enhver forsinkelse i app-initialiseringen forskydes metrikken og koster mærkbar tid.
Server- og netværksniveau: HTTP/2/3, caching, early hints
På Protokolleniveau sikrer jeg mig spillerum: Rene cache-headers (Cache-kontrol, ETag, uforanderlig) holder tilbagevendende besøg slanke. HTTP/2/3-prioritering understøtter tidlig levering af vigtige objekter – dette fungerer bedst, når browseren ikke støder på kunstige blokeringer på grund af fejlagtige konfigurationer. 103 Early Hints kan udløse forhåndsindlæsning, selv før det endelige svar. Jeg kombinerer dette med kompakte, næste generations formater (AVIF/WebP) og et fornuftigt differentieret kvalitetsvalg for ikke at overbelaste ledningen.
Særlige tilfælde: Videoer, iframes og tredjepart
Helt-Videoer og indlejrede iframes er båndbreddejægere. Til startbilledet på en video bruger jeg et let plakat som img og prioriterer det som et normalt heltebillede; selve videoen uploader jeg kontrolleret. Iframes uden for viewporten må gerne være lazy, men jeg forhindrer, at scripts til annoncer, tag-managers eller sociale embeds fortrænger LCP-billedet. Hvor det er muligt, bruger jeg indlæsning="doven" for iframes langt under folden og sørg for, at deres initialisering ikke forstyrrer hovedrenderingstien.
Kvalitet, formater og artefakter
Billedkvalitet er ikke lineær: Et lille skridt i komprimeringen kan reducere antallet af bytes betydeligt uden synlige skader. Jeg tester forskellige kvalitetsniveauer (f.eks. AVIF/WebP/JPEG) pr. motivtype og har varianter klar til Retina-opløsning. Til thumbnails er en stærkere komprimeret version ofte tilstrækkelig – det giver tilstrækkelig båndbredde til hovedbilledet. Vigtigt: Lever ikke unødvendigt store pixelstørrelser; kombinationen af srcset og præcist Størrelser forhindrer overdimensionering på smalle skærme.
Finjustering af rulleadfærd og tærskelværdier
Das Timingen for offscreen-billeder afgør, om brugerne ser huller. Jeg sætter rootMargins i Intersection Observer, så billeder begynder at indlæses en skærmlængde før ankomsten – på hurtige enheder kan tærsklen være mindre, på langsomme netværk større. Det er vigtigt, at denne logik ikke påvirker LCP-billedet. Til dette formål indkapsler jeg reglen: Alt over folden er ivrigt, alt under følger de dynamiske tærskler.
Teststrategi for produktion: RUM, rollouts og guardrails
Lab-Målinger er værdifulde, men feltværdier er afgørende. Jeg implementerer ændringer i trin og observerer LCP, FID/INP og CLS i Real User Monitoring. Afvigelser på 75. percentil er mit tidlige varslingssystem. I DevTools simulerer jeg svage netværk og CPU-begrænsning, kontrollerer vandfald, initiatorer og prioriteter. Filmstrips viser, om heltebilledet virkelig vises tidligt. Først når forbedringer viser sig konsekvent i feltet og laboratoriet, erklærer jeg den nye konfiguration for standard (kilde: [1]).
Kort og klart: Anbefaling til handling
Sæt Brug selektiv lazy loading og behandl LCP-billedet som første prioritet. Fjern lazy for alle billeder, der er synlige med det samme, giv dem mål og sikker prioritet. Brug placeholders og Intersection Observer for at holde scrollingen flydende. Mål alle ændringer med DevTools, Lighthouse og feltværdier i stedet for at stole på antagelser. Så opnår du bedre LCP-værdier, stabile layouts og en hurtig, pålidelig visning på alle enheder (kilder: [1], [3], [5], [8]).
