Lazy loading

Lazy loading er en teknik, der udsætter indlæsningen af billeder, iframes eller andre ressourcer, indtil de er tæt på at blive brugt. En side med 30 billeder behøver dermed ikke hente dem alle, før brugeren kan læse den øverste del.

Teknikken kan reducere den første datamængde og gøre siden hurtigere at komme i gang med. Det støtter arbejdet med Core Web Vitals, især på lange sider, gallerier og produktlister.

Lazy loading er ikke det samme som komprimering. Et billede på 4 MB er stadig for stort, når det til sidst hentes. Brug derfor teknikken sammen med passende dimensioner og formater som WebP.

Det er heller ikke en regel om, at alt skal vente. Indhold, som brugeren ser med det samme, bør normalt indlæses tidligt. Et forsinket hero-billede kan gøre oplevelsen dårligere og forringe Largest Contentful Paint.

På almindelige billeder kan browserens loading="lazy" bruges. Moderne browsere bestemmer selv, hvor tæt billedet skal være på skærmen, før det hentes. Det er ofte bedre end et tungt JavaScript-bibliotek til simple behov.

Brug lazy loading på billeder længere nede på siden, indlejrede videoer, kort og iframes, som mange besøgende aldrig når. På en produktside kan billeder under første skærm vente, mens hovedbilledet bør være tilgængeligt hurtigt.

Angiv altid bredde og højde, så browseren kan reservere pladsen. Ellers hopper teksten, når billedet kommer ind, og det kan påvirke Cumulative Layout Shift.

Test den faktiske side på mobil. Cache og hurtig kontorforbindelse kan skjule problemer. Brug browserens netværksbegrænsning og se, om vigtige billeder kommer med det samme, mens senere indhold venter.

En cateringvirksomhed har en caseside med 24 billeder. Hvert billede fylder i gennemsnit 180 kB. Uden lazy loading kan siden forsøge at hente cirka 4,32 MB billeder ved første åbning.

Kun de første fire billeder ligger på den første skærm. Med lazy loading hentes de fire først, svarende til 720 kB, mens resten hentes, når brugeren scroller. Den første billedmængde falder dermed med cirka 3,6 MB i dette regneeksempel.

Hero-billedet markeres ikke som lazy. Det optimeres separat og leveres i en størrelse, der passer til skærmen. Resultatet er, at den synlige del kommer hurtigt, uden at resten af galleriet belaster forbindelsen fra start.

Virksomheden bruger siden som en del af sin hjemmeside, og rådene i guiden om en brugervenlig hjemmeside bruges til at vurdere både hastighed og næste skridt.

Den største fejl er at sætte lazy loading på sidens vigtigste billede. Hvis browseren opdager det sent, kan LCP blive dårligere. Billeder over folden, logo og centrale produktbilleder skal vurderes særskilt.

En anden fejl er at bruge flere løsninger samtidig. Tema, WordPress, cacheplugin og billedplugin kan alle forsøge at styre loading. Det kan give dublerede attributter, JavaScript-fejl eller billeder, der aldrig vises.

Lazy loading må heller ikke skjule indhold for søgemaskiner eller brugere uden JavaScript. Browserens indbyggede attribut er robust, mens specialbyggede løsninger skal have fallback og testes med Googlebot i tankerne.

WordPress har haft indbygget lazy loading på mange billeder siden version 5.5. Nyere versioner bruger mere nuancerede regler for ikke at forsinke de første billeder. Et plugin kan stadig ændre adfærden, så kildekoden og netværket bør kontrolleres.

Browseren bestemmer selv tærsklen for native lazy loading. Billedet kan derfor blive hentet, før det faktisk er synligt. Det er meningen: der skal være tid til at hente det, inden brugeren når frem.

CSS-baggrundsbilleder understøtter ikke den almindelige loading-attribut på samme måde som et img-element. De kræver en anden strategi og bør bruges med omtanke til vigtigt indhold.

Largest Contentful Paint måler, hvornår det største synlige indholdselement i den første visning bliver renderet i browseren. Det er ofte et hero-billede, produktfoto eller stor overskrift. Hvis det element lazy-loades, kan browseren prioritere det for lavt.

Kontrollér derfor hvilken fil der er LCP-element på de vigtigste skærmstørrelser. Det kan være forskelligt på mobil og desktop. Brug browserens performanceværktøj eller PageSpeed-data som pejlemærke.

Et LCP-billede bør ligge tidligt i HTML, have passende prioritet og korrekt størrelse. Preload kan være relevant i særlige tilfælde, men det skal bruges præcist. For mange preload-instruktioner skaber ny konkurrence om forbindelsen.

Lazy loading er mest værdifuldt efter den første skærm. Det er her, ressourcer kan udskydes uden at forsinke den del, som brugeren allerede venter på.

Billeder kan bruge loading-attributten direkte. Responsive billeder med srcset og sizes bør stadig være korrekt opsat, så browseren vælger den rigtige fil. Lazy loading af en alt for stor desktopfil på mobil er kun en udsættelse af problemet.

Iframes til kort og video kan også markeres lazy. En indlejret videotjeneste kan hente mange scripts og forbindelser, selv om brugeren aldrig afspiller videoen. En let forhåndsvisning kan reducere belastningen yderligere.

Videoelementer har andre muligheder som preload="none" eller preload="metadata". Valget afhænger af, om videoen starter automatisk, og hvor vigtig den er. En baggrundsvideo i en hero-sektion kræver en særskilt vurdering af filstørrelse og mobiladfærd.

Alt indhold skal stadig have en meningsfuld alt-tekst eller titel, hvor det er relevant. Loading-teknikken ændrer ikke kravene til tilgængelighed og forståelse.

WordPress tilføjer ofte loading-attributter automatisk til billeder i indholdet og udvalgte skabeloner. Temaet afgør dog, hvordan hero, logo, produktgalleri og specialfelter bliver udskrevet.

Et optimeringsplugin kan erstatte native lazy loading med JavaScript eller tilføje placeholders. Kontrollér, om løsningen giver en synlig flimren, om billederne er tilgængelige ved fejl, og om den konflikter med cache.

På WooCommerce skal produktbilleder, variationer, zoom og relaterede produkter testes. Et galleri kan have egne scripts, som reagerer anderledes end almindelige billeder.

Lav ændringer i et stagingmiljø og ryd relevant cache før sammenligning. Ellers kan gamle HTML-versioner få testen til at vise blandede resultater.

Sammenlign netværksmængden ved første visning før og efter. Se antal requests, overført data og hvilke billeder der hentes uden scroll. Målingen bør foretages med tom cache for at vise en ny besøgendes oplevelse.

Mål også LCP og layoutskift. En lavere datamængde er ikke en gevinst, hvis hero-billedet kommer senere eller indholdet hopper. Teknikken skal forbedre den samlede oplevelse.

Scroll gennem siden og kontrollér, at indholdet kommer i god tid. På langsomme forbindelser kan for kort afstand give tomme felter. Browserens native løsning håndterer normalt dette fornuftigt, men specialkode skal testes.

På en webshop bør målingen omfatte kategori, produkt og checkout. Hver skabelon bruger medier på sin egen måde, og én global indstilling passer ikke altid til alle.

Åbn forsiden, en lang artikel, en kategori og en produktside med tom cache. Se hvilke billeder der hentes før scroll, og markér dem som enten kritiske eller udsættelige. Hero, logo og første produktfoto er typisk kritiske; billeder langt under folden er oplagte kandidater til lazy loading.

Kontrollér derefter dimensioner, filformat og layoutplads. Et lazy-loadet billede bør stadig have korrekte width- og height-værdier, responsive størrelser og en passende WebP- eller JPEG-fil. Teknikken skal ikke bruges til at skjule dårlige uploads.

Test med langsom mobilforbindelse og scroll i forskelligt tempo. Billederne skal nå frem, før tomme felter bliver tydelige. Kontrollér også tastaturnavigation, gallerier og modaler, hvor indhold kan blive synligt uden almindelig scroll.

Gem målingerne før og efter, og notér hvilke billeder der blev undtaget. Så kan næste tema- eller pluginopdatering kontrolleres mod en kendt opsætning i stedet for at begynde forfra.