Lazy loading av bilder: när det passar och när du bör undvika det

Vad ändrar lazy loading?

Lazy loading ändrar när webbläsaren begär en bild, inte dess pixelmått, format eller komprimering. På en lång receptsida behöver besökaren början direkt men kanske aldrig når de femton bilderna i slutet. Att vänta med dem kan undvika onödiga nedladdningar när sidan öppnas.

Det handlar om tre olika uppgifter: storleksändring tar bort onödiga pixlar, komprimering minskar datamängden och lazy loading skjuter upp begäran. En stor bild är fortfarande tung när den väl laddas. En liten kan visas sent om begäran dröjer.

Förbered lämpliga mått med verktyget för storleksändring och jämför komprimering vid behov. Bestäm sedan vilka bilder som behövs från början. Guiden om filstorlek behandlar förberedelserna; här väljer vi laddningstidpunkt.

Kom igång utan att koda

Du behöver inte ändra HTML för att välja vilka bilder som ska laddas först. Börja med en produktsida eller lång artikel. Första vyn är det område du ser innan du skrollar.

1. Leta efter en befintlig inställning. Titta under tema, bilder eller prestanda i webbplatsens administration. Sök efter ”lazy loading” eller ”uppskjuten bildladdning”. Namn och plats varierar, och vissa tjänster sköter det automatiskt. Fråga webbplatsens ansvariga innan du installerar ytterligare ett tillägg.
2. Håll första vyn redo. Huvudbilden och andra direkt synliga bilder ska laddas normalt. Ta reda på hur undantag fungerar om sådana finns. Aktivera inte en regel för alla bilder innan du vet hur huvudbilden hanteras.
3. Prova på bilder längre ner. Senare artikelillustrationer är en bra början. Använd förhandsvisning eller testsida om möjligt och kontrollera sedan den publicerade sidan. Testa gallerier separat eftersom besökaren kan byta bild snabbt.
4. Kontrollera läsupplevelsen. Öppna på mobil och dator. Kommer huvudbilden snabbt? Visas andra bilder i tid vid långsam och snabb skrollning? Hoppar texten när en bild kommer? Prova även en direktlänk till ett avsnitt längre ner.

Vid problem återställer du den senaste inställningen och ber om hjälp med sidan. Kontrollen avslöjar tydliga dröjsmål och hopp, men visar inte att sidan blivit snabbare. Det kräver mätningar; testavsnittet förklarar vad du ska anteckna.

Du kan be den ansvariga: ”Kontrollera lazy loading på den här sidan. Låt huvudbilden och direkt synliga bilder laddas normalt. Skjut upp lämpliga bilder längre ner och reservera deras utrymme så att texten inte hoppar. Testa på mobil och dator och jämför huvudbildens laddningstid före och efter.” Lägg till sidlänken och nämn bilder som visas sent.

Vilka bilder kan laddas senare?

Öppna en typisk sida utan att skrolla. Vilka bilder syns och hjälper besökaren att förstå innehållet? Upprepa på en smal mobil och en bred datorskärm. Banner, rubrik och produktgalleri kan hamna på olika platser.

Utgå från den verkliga placeringen, inte filnamn eller uppladdningsordning. Första bilden i mediebiblioteket behöver inte vara först på sidan. Ett foto efter en lång inledning kan också hamna i första vyn i en annan sidmall.

Om samma bild syns direkt på datorn men längre ner på mobilen är normal laddning en tryggare start. loading har ingen mediafråga som picture. Lägg inte till ett skript för skärmstorlekar bara för att spara en begäran; kontrollera först om den innebär en märkbar belastning.

En dold galleribild är inte garanterad att laddas senare. Galleriets skript kan förladda bilder oberoende av attributen. Testa snabba byten och att gå tillbaka till en tidigare bild, inte bara att skrolla.

Varför huvudbilden inte ska vänta

Largest Contentful Paint (LCP) mäter hur snart det största innehållselementet i första vyn blir synligt. Det är ofta huvudfotot men kan vara ett textblock. Identifiera elementet i prestandarapporten. Är det en bild ska den inte laddas med fördröjning. En adress i den ursprungliga HTML-koden låter webbläsaren börja tidigt; om ett skript lägger in den senare kan väntan öka.

Att ta bort lazy loading löser inte allt. Serversvar, filstorlek och visning kan fortfarande orsaka fördröjning. Googles guide till LCP-optimering delar upp förloppet. Pixilos guide till Core Web Vitals skiljer laddningsproblem från layoutförskjutningar.

Använd fetchpriority="high" selektivt för en bild som visat sig viktig. Hög prioritet för alla galleribilder skapar ingen användbar ordning. Inställningen tar heller inte bort uppskjuten laddning.

Kontrollera vad CMS och galleri redan gör

Granska bilden på den publicerade sidan innan du installerar ett tillägg. CMS, tema eller optimeringstjänst kan redan lägga till attributet. Titta på den färdiga HTML-koden och begäran, inte bara ett namn som ”bildoptimering”.

Hantera beteendet på ett ställe. Byter ett skript adresser, omsluter bilder med fler element eller förladdar galleribilder, kan ytterligare en mekanism försvåra felsökningen. Börja med en sida och undanta huvudbilden från uppskjutning.

En CSS-bakgrund är ett separat fall: laddningsattributet för img fungerar inte på en bakgrundsdeklaration. Be mallens ansvariga kontrollera hur resursen hittas. Bild-HTML i ett innehållsblock ändrar inte temats bakgrund.

Lägg till webbläsarens lazy loading i HTML

För en illustration tydligt nedanför första vyn behåller du den riktiga adressen i src och lägger till laddningsattributet. Byt exempelvägarna mot egna filer. Alt-texten beskriver vad bilden visar; receptinstruktioner hör hemma i brödtexten. En rent dekorativ bild ska ha alt="".

<img
  src="/images/recipe-step-04.webp"
  width="1200"
  height="800"
  loading="lazy"
  alt="Deg vikt över fyllningen med kanterna fortfarande öppna"
>

Ett foto som mätts som LCP i första vyn behöver ett annat val:

<img
  src="/images/finished-loaf.webp"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="Nygräddat bröd med gyllenbrun skorpa"
>

eager innebär normal laddning, vanligtvis samma som att utelämna loading. Ett uttryckligt värde hjälper om mallen annars automatiskt lägger till lazy loading. Det betyder inte att nedladdningen blir klar omedelbart. MDN:s referens för bildelementet förklarar attributen.

Webbläsaren avgör när bilden är nära nog att begära, ibland innan den syns. En begäran utanför vyn visar därför inte att inställningen misslyckats. Använd inte ett fast skrollavstånd som testkrav. Läs web.dev:s guide till inbyggd lazy loading.

Reservera plats och behåll responsiva varianter

Ange källfilens pixelmått i width och height, här 1200 × 800. De bestämmer proportionerna; CSS kan visa bilden mindre. Samma tal på en annorlunda formad bild reserverar fel utrymme. För skalning utan beskärning:

.article-image {
  display: block;
  max-width: 100%;
  height: auto;
}

Lägg till class="article-image" på bilden eller anpassa en befintlig regel. Vid fast beskärning reserverar du den visade ytan. Kontrollera layouten: andra CSS-regler kan skriva över inställningarna.

Lazy loading ersätter inte srcset och sizes. Behåll användbara varianter för filvalet. I picture ska laddningsattributet sitta på img. Guiden till responsiva bilder har fullständiga exempel.

Testa den publicerade ändringen

1. Anteckna utgångsläget. Spara URL, fönsterstorlek, LCP-element och LCP-tid, starttid för huvudbildens begäran och överförda bilddata före skrollning. Ange om det är ett första besök eller ett test med cache.
2. Granska bildbegäranden. Öppna Network före omladdning och filtrera bilder. Vilka filer begärs i första vyn och när startar de?
3. Ändra en laddningsregel. Ta exempelvis bort uppskjutning från huvudbilden eller aktivera den för senare illustrationer.
4. Bekräfta den publicerade ändringen. Kontrollera attribut och adresser efter nödvändig cacheuppdatering. En lokal malländring ändrar ännu inte den publika sidan.
5. Upprepa och skrolla. Jämför likvärdiga körningar. Skrolla långsamt och snabbt, använd gallerier och avsnittslänkar. Leta efter tomma ytor och innehåll som flyttar sig.

”Disable cache” stänger av webbläsarens cache medan utvecklarverktygen är öppna, men tömmer inte serverns eller CDN-tjänstens cache. Chromes dokumentation för Network förklarar granskningen. Håll nätförhållandena lika och jämför flera körningar, inte bara den bästa.

Börja högst upp med samma fönsterstorlek, nätinställningar och observationstid före skrollning. Anteckna startresultaten först, annars kan senare bildbegäranden störa jämförelsen. En återställd skrollposition kan också få en bild längre ner att laddas direkt.

En bra ändring visar första vyn snabbt och senare bilder när de behövs. Färre tidiga begäranden hjälper bara om läsning och navigering förblir smidiga. Använd PageSpeed-guiden för jämförelsen.

Exempel: en omslagsbild och tolv illustrationer

En lång artikel har en omslagsbild i första vyn och tolv foton längre ner. En global regel skjuter upp alla tretton. Omslaget syns sent på mobilen trots en liten fil. Det här visar ett arbetssätt, inte en uppmätt förbättring.

Kontrollera om omslaget är LCP-elementet. Ta bort dess uppskjutning och testa bara den ändringen. Behåll selektiv uppskjutning och reserverat utrymme för senare bilder. Syns den första illustrationen direkt på datorn, låt även den laddas normalt.

Jämför efter publicering starttid och LCP under liknande förhållanden. Kontrollera alla tolv bilder och hoppa med en avsnittslänk. Kommer omslaget tidigt men hålls dolt av en animation, undersök visningsfördröjningen i stället för att fortsätta ändra laddningsattributet.

Håll bilderna tillgängliga för sökmotorer

Använd relevant alt-text och en riktig källadress. Ett skript som bara lämnar en platshållare tills någon klickar eller skrollar behöver granskas. Googles råd om uppskjutet innehåll rekommenderar laddning när innehållet kommer in i vyn, utan krav på en användarhändelse.

Kontrollera vid behov den renderade sidan med URL-granskning i Search Console. Finns viktiga bildadresser i den renderade HTML-koden? En prestandainställning garanterar inte att alla bilder indexeras eller att placeringarna förbättras.

Vanliga frågor

Ska alla bilder använda lazy loading?

Nej. Välj efter placering och betydelse. Bilder som behövs direkt, särskilt LCP-bilden, ska inte vänta.

Blir bildfilen mindre?

Nej, bara tidpunkten ändras. Ändra storlek eller komprimera en separat kopia om pixelmått eller filstorlek är problemet.

Behöver jag ett JavaScript-bibliotek?

Inte för inbyggd lazy loading av vanliga HTML-bilder. När JavaScript är avstängt skjuts laddningen inte upp och bilder med riktiga källadresser laddas normalt. Ett skript som bara sparar adressen i data-src behöver en reservlösning. Välj egen kod endast för ett konkret behov och testa noga.

Varför laddas vissa bilder utanför vyn direkt?

De kan vara nära nog eller förladdas av en annan del av sidan. Kontrollera vad som startar begäran samt galleriets och temats inställningar innan du ser det som ett fel.

Ersätter asynkron avkodning lazy loading?

Nej. decoding gäller avkodning och visning, loading uppskjutning. Den ena inställningen säger inget om den andra.

Sammanfatta medChatGPT (öppnas i en ny flik)Grok (öppnas i en ny flik)Google (öppnas i en ny flik)Perplexity (öppnas i en ny flik)Claude (öppnas i en ny flik)