Vad lazy loading faktiskt gör med din Largest Contentful Paint

Lazy loading är ett schemaläggningsbeslut, inte en hastighetsbesvärjelse

Lazy loading beskrivs ofta som en prestandaförbättring, vilket är sant på samma sätt som att inte packa en resväska är en viktminskning. Det hjälper eftersom webbläsaren gör mindre arbete direkt i början.

Den skillnaden spelar roll för Largest Contentful Paint, oftast förkortat LCP. LCP mäter när det största meningsfulla elementet i visningsytan renderas. På många sidor är det elementet en hero-bild. På andra är det en stor rubrik, en posterbild, ett produktfoto eller ett innehållsblock.

Lazy loading ändrar när resurser begärs. Det får inte en bild att avkodas snabbare, en server att svara snabbare eller ett typsnitt att renderas tidigare. Om du lazy loadar fel sak, särskilt elementet som blir LCP, säger du åt webbläsaren att vänta innan den hämtar just det den måste visa för att klara Core Web Vitals.

Det är därför lazy loading både används för mycket och förstås för dåligt.

Vad webbläsaren gör när du lazy loadar en bild

Inbyggd lazy loading för bilder läggs vanligtvis till så här:

<img src='hero.jpg' loading='lazy' alt='...'>

Med loading='lazy' får webbläsaren skjuta upp hämtningen av bilden tills den bedömer att bilden sannolikt kommer att behövas. I praktiken använder webbläsare avstånd från visningsytan, nätverksförhållanden, bilddimensioner och andra heuristiker. De exakta reglerna är implementationsdetaljer och kan ändras.

Med loading='eager', eller utan lazy-attribut i de flesta fall, behandlar webbläsaren bilden som en del av den normala laddningsprocessen. Den måste fortfarande prioritera mellan CSS, JavaScript, typsnitt, bilder och andra förfrågningar, men bilden går att upptäcka omedelbart.

Det betyder att lazy loading främst påverkar tre faser:

• Upptäckt: när webbläsaren märker resursen.
• Förfrågans start: när nätverkshämtningen börjar.
• Renderingstidpunkt: när resursen till slut kan avkodas och målas upp.

För LCP är den farliga fasen förfrågans start. Om förfrågan för LCP-bilden börjar sent förskjuts allt efter den också sent.

Den enkla regeln: lazy loada aldrig LCP-kandidaten

Om en bild syns i den initiala visningsytan och sannolikt är det största innehållselementet ska du inte lazy loada den.

Det inkluderar:

• hero-bilder
• primära produktfoton ovanför den initiala vyn
• stora ingressbilder för artiklar
• stora bakgrundsliknande bilder implementerade som <img>
• videoposterbilder när postern är det huvudsakliga visuella elementet

Webbläsaren kan inte rendera LCP-bilden förrän den har begärts, överförts, avkodats och målats upp. Lazy loading lägger in osäkerhet före det första steget. Även en liten fördröjning kan räcka för att flytta LCP från acceptabelt till dåligt på en långsammare anslutning.

Ett vanligt felmönster ser ut så här:

1. Servern skickar HTML.
2. Webbläsaren tolkar en bild ovanför den initiala vyn.
3. Bilden har loading='lazy'.
4. Webbläsaren väntar eftersom lazy loading-heuristiken säger att den kan det.
5. CSS och JavaScript fortsätter att laddas.
6. Bildförfrågan startar senare än den borde.
7. LCP blir sent, trots att själva bildfilen är rimligt optimerad.

Det här är frustrerande eftersom sidan kan se prydlig ut i en kodgranskning. Problemet är inte bara filstorlek. Det är prioritet.

Om du läser labbresultat och försöker avgöra om LCP faktiskt är problemet är vår guide till att läsa en Lighthouse-rapport utan panik avsiktligt praktisk: separera fältdata, labbtips och åtgärder innan du börjar ändra kod. (Obs: om din routing är skiftlägeskänslig, använd den exakta URL:en från ditt CMS.)

Rättelse: använd den faktiska interna URL:en

Den korrekta Wux-artikelns URL är Så läser du en Lighthouse-rapport utan panik. Poängen kvarstår: identifiera LCP-elementet innan du ändrar laddningsbeteendet.

När lazy loading kan förbättra LCP

Lazy loading kan förbättra LCP indirekt när det håller icke-kritiska resurser ur webbläsarens väg.

Föreställ dig en produktsida med en hero-produktbild högst upp och en karusell med tolv rekommendationsbilder under den initiala vyn. Om alla tretton bilder laddas eager kan webbläsaren använda bandbredd och anslutningsplatser på bilder som användaren ännu inte kan se. På ett begränsat nätverk kan det konkurrera med hero-bilden, CSS eller typsnittsfiler.

Att lazy loada karusellbilderna under den initiala vyn kan hjälpa LCP-bilden att laddas tidigare eftersom färre icke-kritiska förfrågningar konkurrerar under den första sidladdningen.

Det här är det legitima prestandafallet för lazy loading:

• eager-loada LCP-kandidaten ovanför den initiala vyn
• lazy loada bilder under den initiala visningsytan
• undvik tunga skript som injicerar viktiga bilder sent
• behåll bilddimensioner i HTML för att undvika layoutskiften

Lazy loading är inte en LCP-optimering i sig. Det är ett verktyg för resursprioritering. Det hjälper när det skyddar den kritiska vägen.

Det bättre mönstret för LCP-bilder

För en LCP-bild ovanför den initiala vyn är målet att få webbläsaren att upptäcka den tidigt, begära den tidigt och rendera den utan layoutinstabilitet.

En stabil baslinje ser ut så här:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

De viktiga delarna är inte dekorativa:

• loading='eager' förhindrar fördröjning från lazy loading.
• fetchpriority='high' säger åt webbläsaren att den här bilden är viktig.
• width och height reserverar utrymme och minskar layoutskift.
• srcset och sizes förhindrar onödigt stora nedladdningar.
• Ett modernt format kan minska överföringstiden när det används noggrant.

Om du fortfarande skickar en stor JPEG till varje skärm kan bildformat och responsiv storleksanpassning spela större roll än lazy loading-attributet. För ett praktiskt beslutsträd, se när AVIF slår WebP och när det inte gör det.

Bakgrundsbilder kräver extra omsorg

CSS-bakgrundsbilder upptäcks inte lika tidigt som vanliga HTML-bilder. Webbläsaren måste hämta och tolka CSS innan den känner till dem. Om ditt LCP-element är en CSS-bakgrundsbild har du redan gjort upptäckten svårare.

Det betyder inte att bakgrundsbilder är förbjudna. Det betyder att du bör vara medveten.

För dekorativa bilder fungerar CSS-bakgrunder bra. För meningsfulla hero-bilder är ett <img>- eller <picture>-element vanligtvis bättre eftersom det är synligt för HTML-tolkaren, stöder alt-text och fungerar väl med responsiva bildattribut.

Om du måste använda en CSS-bakgrund för en LCP-bild, överväg att förladda den:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload är inte heller ett trollspö. Att förladda för många bilder skapar samma prioritetsproblem i en annan kostym. Använd det för den enda bild som verkligen spelar roll, inte för varje bild i designsystemet.

JavaScript-baserad lazy loading gör ofta saker värre

Innan inbyggd lazy loading hade brett stöd använde många webbplatser JavaScript-bibliotek som bytte ut data-src mot src efter sidladdning eller efter att en intersection observer aktiverades. Vissa gör det fortfarande.

Det kan vara rimligt för långa artikelsidor eller bildtunga gallerier. Det är ett dåligt val för innehåll ovanför den initiala vyn.

Webbläsarens preload scanner är snabb, men den kan inte begära en bild vars URL är gömd i ett anpassat attribut förrän JavaScript körs. Om din hero-bild börjar som data-src='hero.jpg' har du fördröjt upptäckten bakom skriptnedladdning, parsning, exekvering och framework hydration.

Det är en dålig kompromiss för LCP. Lägg kritiska bild-URL:er i riktig HTML. Låt webbläsaren göra sitt jobb.

LCP är inte alltid ett bildproblem

På vissa sidor är LCP-elementet text. I så fall kan lazy loading av bilder ha liten direkt effekt. Flaskhalsen kan vara renderingsblockerande CSS, långsam serversvarstid, client-side rendering eller webbtypsnitt.

Typsnitt är värda att lyfta fram eftersom de ofta är en dold orsak till sen textrendering. En stor rubrik kan bli LCP, och typsnittsladdningens beteende kan fördröja eller ändra när rubriken målas upp. Om ditt bildarbete inte flyttar mätvärdet, inspektera LCP-elementet direkt i stället för att anta. Vår artikel om webbtypsnitt som en prestandavinst täcker de tråkiga åtgärder som ofta fungerar: färre vikter, moderna format, förnuftiga fallbacks.

Så testar du lazy loading-ändringar utan att lura dig själv

Testa inte genom att stirra på din sida på kontorets Wi-Fi. Du behöver se förfrågningarnas timing.

Använd det här arbetsflödet:

1. Öppna Chrome DevTools och spela in en Performance-trace.
2. Aktivera nätverksbegränsning, till exempel Fast 4G eller Slow 4G.
3. Ladda om sidan med cache inaktiverad.
4. Hitta LCP-markören.
5. Identifiera LCP-elementet.
6. Kontrollera i Network-panelen när den resursen började laddas.

Om LCP-resursen startar sent, fråga varför:

• Var den lazy loadad?
• Injicerades den av JavaScript?
• Var den gömd i CSS?
• Nedprioriterades den bakom andra bilder?
• Var servern långsam med att svara?

Gör sedan en ändring och testa igen. Prestandaarbete blir rörigt när team ändrar bildformat, lazy loading, preloading, JavaScript-bundles och CDN-inställningar i samma driftsättning. Du kan förbättra sidan, men du kommer inte att veta vilken ändring som spelade roll.

Fältdata spelar också roll. Labbverktyg är användbara för diagnos, men LCP varierar beroende på enhet, nätverk, visningsyta, cacheläge och geografi. Använd real-user monitoring eller data från Chrome User Experience Report när du kan.

<!-- tool-cta:start -->

💡 Prova detta: Håll din LCP-bild liten och eager-loaded genom att köra den genom Image Compressor, så att den renderas snabbt utan att behöva lazy loading.

<!-- tool-cta:end -->

En praktisk policy för de flesta webbplatser

För de flesta marknadsföringssajter, e-handelssidor, dokumentationssajter och publicistsidor räcker den här policyn:

• Primär bild ovanför den initiala vyn: eager-loada, överväg hög fetch priority.
• Innehållsbilder under den initiala vyn: lazy loada.
• Ikoner och små UI-resurser: vanligtvis inte värda att tänka på individuellt.
• CSS-bakgrund som hero: överväg HTML-bild i stället eller preload försiktigt.
• JavaScript-injicerad hero-bild: åtgärda renderingsarkitekturen om möjligt.
• Karuseller: eager-loada bara den första synliga sliden; lazy loada resten.

Det finns gränsfall. Webbläsares heuristiker förbättras. Ramverk lägger till automatiska bildkomponenter. Vissa plattformar undviker numera lazy loading för bilder som upptäcks nära visningsytan. Ändå förändras inte principen: kritiska resurser ska vara tidiga och uppenbara; icke-kritiska resurser ska vänta.

Lazy loading är värdefullt när det uttrycker den skillnaden. Det är skadligt när det döljer det viktigaste innehållet för webbläsaren tills sidan redan har börjat förlora LCP-loppet.