Den Kompletta Guiden till Lazy Loading Bilder

0
24

Bilder som är kritiska. Oavsett om det är marknadsföring, banners, bilder produkt eller logotyper, det är omöjligt att föreställa sig en hemsida utan bilder. Tyvärr har dock bilder är ofta tunga filer vilket gör dem den enskilt största orsaken till att sidan svälla. Enligt HTTP Arkiv Tillstånd av Bilder rapport, median sida storleken på stationära datorer är 1511 KB och bilder står för nästan 45% (650 KB) av den totala.

Som sagt, det är inte som om vi kan helt enkelt göra sig av med bilder. De är för viktiga för att den totala användarupplevelsen. Vi behöver i stället för att göra våra webbsidor laddas riktigt fort med dem. I denna guide kommer vi att täcka alla ins och outs av lazy loading bilder, en teknik som hjälper till att förbättra den tid det tar för en sida att laddas genom att senarelägga bild laddar tills de behövs.

Innan vi dyker rätt i, här är ett exempel på en video som visar konceptet. Kort sagt, en grå platshållare box återges på sidan tills det rullar in i visa—vid vilken punkt den faktiska bilden laddas på plats i lådan.

Kapitel 1: Vad är Lazy Loading?

Vi förknippar ofta ordet “lat” med att undvika att arbeta så länge som möjligt, eller enbart handla om att vilja göra ingenting alls.

På samma sätt, lazy loading skjuter lastning av resurser på sidan så länge de inte behövs. Istället för att ladda dem på en gång, vilket är vad som normalt händer, tillåter vi dem att ladda senare.

Lazy Loading är en uppsättning tekniker inom webb-och applikationsutveckling som skjuter lastning av resurser på en sida till en senare tidpunkt—när dessa resurser verkligen behövs istället för att fylla dem på framsidan. Dessa tekniker hjälper till att förbättra prestanda, bättre utnyttjande av enhetens resurser och minska kostnaderna.

Tekniken lazy loading kan tillämpas på nästan alla resurser på en sida. Till exempel, även en JavaScript-fil kan hållas tillbaka om det är bäst att inte läsa den från början. Samma sak för en bild—ladda den när vi behöver det.

Vi kommer att hålla till lazy loading bilderna i den här handboken, men det är bra att veta att det kan tillämpas på andra tillgångar.

Kapitel 2: Varför Lata Belastning på Alla?

Om användaren aldrig bläddrar till den punkt på den sida som innehåller bilden, sedan kommer användaren aldrig att se den bilden. Det är också aldrig laster i första hand eftersom hey, det var aldrig behövs.

Du kan redan börja se hur detta gynnar både dig och användaren. Här är två av de fördelar som vi får med lazy loading.

Resultat Av

Den uppenbara fördelen är att vi får mindre web-sidor att ladda snabbare. Lazy loading minskar antalet bilder som behöver laddas på en sida på framsidan. Färre bild förfrågningar innebära färre bytes att ladda ner. Och färre bytes att ladda ner innebär att sidan gör snabbare än om dessa byte och förfrågningar görs.

Detta säkerställer att varje enhet på alla nätverk är möjligheten att hämta och bearbeta de återstående resurserna mycket snabbare. Alltså, tiden från det att begäran att göra blir mindre och sidan blir användbar mycket tidigare. Win-Win!

Minska kostnaderna

Den andra fördelen är att du som webbplatsens administratör. Cloud hosting-tjänster, som Content Delivery Networks (Cdn) eller web-servrar eller lager, levererar bilder (eller någon tillgång för den delen) till en kostnad baserad på antal byte som överförts. En lat laddade bilden kan aldrig få laddas om användaren når aldrig det. Därmed kan du minska den totala byte levereras på sidan och i slutändan spara några slantar i processen. Detta är särskilt sant för användare att direkt studsa en sida eller interagerar endast med den övre delen av innehållet.

Minskningen i antal byte som överförts från din leverans nätverket eller servern minskar leverans kostnader. Detta kommer att bli tydligare när vi utforskar lazy loading i de kommande avsnitten.

Hur mycket kommer du spara? Du kan ta reda på vilka bilder som är en kandidat för lat för lastning och hur många byte som du kan spara på första sidan laddas genom att använda Google Fyr revision verktyg. Detta har en särskild avdelning för nbc-bilder. Du kan också använda ImageKit s webbplats analyzer för att identifiera om din webbplats använder lazy loading eller inte bortsett från andra kritiska bild som rör optimeringar på din sida.

Lazy loading är kritisk inte bara till bra resultat men också att leverera en bra användarupplevelse. Eftersom att kombinera prestanda och användarupplevelse med lazy loading är viktigt och utmanande, vi kommer att fortsätta att behandla det här ämnet mer i detalj i handboken efter att vi har tittat på olika sätt att lata ladda bilder.

Kapitel 3: Lazy Loading-Tekniker för Bilder

Det finns två vanliga sätt att ladda in bilder på en sida: <img> – taggen och CSS-background-image egendom. Vi kommer först att titta på den vanligare av de två, <img> – taggen och sedan flytta till CSS bakgrund bilder.

Lazy loading bilder i en bild tag

Låt oss börja med den typiska HTML-koden för en bild:

<img src=”/path/to/some/image.jpg” />

Uppmärkningen för lat för laddning av bilder är ganska likartade.

Steg ett är att förhindra att bilden laddas upp framför. Webbläsaren använder src-attributet på taggen för att utlösa bild belastning. Det spelar ingen roll om det är första eller den 1000: e bilden i HTML-koden. Om webbläsaren får src attribut, kommer det att leda till bilden att laddas ner, oavsett om det är i eller ur aktuella vyn.

Att skjuta upp lasten, sätta bild-URL i ett attribut övriga src än. Låt oss säga att vi ange bildens URL i data-src-attributet på bilden tag. Nu src tom och webbläsaren inte kommer att utlösa bilden belastning:

<img data-src=”https://ik.imagekit.io/demo/default-image.jpg” />

Nu när vi är som hindrar bilden från lastning, vi måste berätta för de webbläsare när du ska ladda det. Annars kommer det aldrig att hända. För detta kommer vi in på att så snart som bilden (dvs dess platshållare) går in i den virtuella, vi utlösa belastning.

Det finns två sätt att kontrollera när en bild går in i den virtuella. Låt oss titta på dem båda med fungerande kod prover.

Metod 1: Trigger bilden belastning med hjälp av Javascript-händelser

Denna teknik använder händelse lyssnare på bläddra, förstora, förminska och orientationChange händelser i webbläsaren. Bläddra händelsen är ganska tydligt eftersom det klockor där användaren är med på en sida som rullning uppstår. Ändra storlek och orientationChange händelser är lika viktiga. Ändra storlek händelse inträffar när webbläsaren fönstrets storlek ändras, även orientationChange aktiveras när enheten roteras från liggande till stående, eller vice versa.

Vi kan använda dessa tre händelser för att känna igen en förändring på skärmen och bestämma antalet bilder som blir synliga på skärmen och leda dem till last om detta.

När någon av dessa händelser inträffar, vi hittar alla bilder på sidan som är uppskjuten, och från dessa bilder, vi kolla vilka som är närvarande i det virtuella. Detta görs med hjälp av en bild top offset, i det aktuella dokumentet topp, och fönstrets höjd. Om en bild har gått in i det virtuella, vi hämtar URL: en från data-src-attribut och flytta den till den src attribut och bilden kommer att läsas in som ett resultat.

Observera att vi kommer att be JavaScript för att välja bilder som innehåller en lat klass. När bilden har laddats, vi ska ta bort den klassen eftersom det inte längre behov för att utlösa en händelse. Och, när alla bilder är laddade, vi tar bort händelsen lyssnare.

När vi bläddrar, bläddrar händelse utlöser flera gånger snabbt. Således, för prestanda, lägger vi till en liten timeout för vårt skript som anpassar lazy loading funktion utförande så att den inte blockerar andra uppgifter som körs i samma tråd i webbläsaren.

Här är ett fungerande exempel på detta tillvägagångssätt.

Se Pennan Lazy loading-bilder med hjälp av event handlers – exempel koden genom att ImageKit.io (@imagekit_io) på CodePen.

Observera att de första tre bilderna i detta exempel är laddade up front. WEBBADRESSEN är direkt närvarande i src-attributet i stället för data-src-attributet. Detta är viktigt för en bra användarupplevelse. Eftersom dessa bilder är på toppen av sidan, de bör göras synlig så snart som möjligt. Det finns ingen anledning att vänta för JavaScript att ladda dem.

Metod 2: Trigger bilden belastning med hjälp av Korsningen Observatör API

Korsningen Observatör API är relativt ny. Det gör det enkelt att upptäcka när en del går in i den virtuella och vidta åtgärder när det gör det. I den tidigare metoden, vi var tvungna att binda händelser, hålla prestanda i åtanke och genomföra ett sätt att beräkna om elementet var i det virtuella eller inte. Korsningen Observatör API tar bort allt som overhead genom att undvika matte och leverera bra prestanda ur lådan.

Nedan är ett exempel som använder API: et för att lata ladda bilder. Vi fäster observatör på alla bilder för att vara lata laddad. När API upptäcker att elementet har gått in i den vy, med hjälp av isIntersecting egendom, vi hämtar URL: en från data-src-attribut och flytta den till attributet src för webbläsaren för att utlösa bild belastning. När detta är gjort kan vi ta bort den lata klass från bilden och även ta bort observatör från den bilden.

Se Pennan Lazy loading-bilder med hjälp av IntersectionObserver – exempel koden genom att ImageKit.io (@imagekit_io) på CodePen.

Om du jämför bilden laddningstider för de två metoderna (event lyssnare vs. Korsningen Observatör), kommer du att hitta bilder laddas mycket snabbare med hjälp av Korsningen Observatör API och att den åtgärd som utlöses snabbare så väl— och ändå webbplats inte visas trög på alla, även i färd med att rulla. I den metod som omfattar händelsen lyssnare, vi var tvungna att lägga till en timeout för att göra det skick, som har en något negativ inverkan på användarens upplevelse som bilden belastning utlöses med en liten fördröjning.

Men, som någon ny funktion, stöd för Korsning Observatör API är inte tillgängliga i alla webbläsare.

Denna webbläsare har stöd för data är från Caniuse, som har mer i detalj. En rad anger att webbläsaren stöder den funktionen på denna version och upp.

Skrivbordet

ChromeOperaFirefoxIEEdgeSafari
58 45 55 Inga 16 Inga

Mobil / Surfplatta

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox
Inga 46 Inga 67 69 62

Så, vi måste falla tillbaka till händelse lyssnaren metod i webbläsare där Korsningen Observatör API stöds inte. Vi har tagit hänsyn till detta i exemplet ovan.

Kapitel 4: Lazy Loading CSS bakgrundsbilder

En gemensam bakgrund bild i CSS:

.min klass {
background-image: url(‘/path/to/some/image.jpg’);
/* fler stilar */
}

CSS bakgrundsbilder är inte så enkelt som att bilden tag. För att läsa dem webbläsaren behöver för att bygga DOM-trädet samt CSSOM träd för att besluta om CSS-stil som gäller för DOM nod i det aktuella dokumentet. Om CSS-regel ange bakgrundsbild gäller inte ett element i dokumentet, då webbläsaren inte ladda bakgrundsbild. Om CSS-regel är tillämplig på ett element i det aktuella dokumentet, då webbläsaren laddar bilden.

Va? Detta kan tyckas vara komplicerade i början, men det är samma beteende som utgör grunden till den teknik för lazy loading bakgrundsbilder. Enkelt uttryckt, vi lura webbläsaren till att inte tillämpa background-image CSS-egenskapen för ett element, till att elementet kommer in i det virtuella.

Här är ett fungerande exempel som lata laddar en CSS i bakgrunden på bilden.

Se Pennan Lazy Loading bakgrunden bilder i CSS genom att ImageKit.io (@imagekit_io) på CodePen.

En sak att notera här är att den JavaScript-kod för lazy loading är fortfarande den samma. Att vi fortfarande använder Korsningen Observatör API-metoden med en återgång till händelse lyssnare. “Trick” ligger i CSS.

Vi har ett element med ID-bg-bild som har en background-image. Men när vi lägger till den lata klass till del, vi kan ändra bakgrunden-bild egendom genom att sätta värdet på det att ingen i CSS.

Eftersom ett element med ett ID och en klass har högre specificitet i CSS än ett ID ensam, den webbläsare som gäller egenskapen background-image: ingen till den del en början. När vi bläddrar du nedåt Korsningen Observatör API (eller händelsen lyssnare, beroende på vilken metod du väljer) upptäcker att bilden är i det virtuella, det tar bort den lata klass från elementet. Detta förändringar gällande CSS och gäller den faktiska bakgrunden-bild egendom till den del, som utlöser belastning av bakgrundsbilden.

Kapitel 5: Skapa en Bättre användarupplevelse Med Lazy Loading

Lazy loading presenterar en bra prestanda. För ett e-handelsföretag som laddar hundratals produkt bilder på en sida, lazy loading kan ge en betydande förbättring av den ursprungliga sidan laddas samtidigt minska bandbredd.

Dock en hel del företag som inte väljer lazy loading eftersom de tror att det går mot att leverera en bra användarupplevelse (dvs den första platshållaren är ful, laddningstider är långsam etc.).

I detta avsnitt kommer vi att försöka lösa vissa problem kring användarens upplevelse med lazy loading-bilder.

Tips 1. Använd Rätt Platshållare

En platshållare är vad som visas i behållaren tills själva bilden är laddad. Normalt ser vi utvecklare med hjälp av en solid färg platshållare för bilder eller en bild som platshållare för alla bilder.

De exempel vi har tittat på hittills har använt en liknande metod: en låda med ett fast ljus grå bakgrund. Men vi kan göra bättre för att ge en mer behaglig upplevelse. Nedan finns några exempel på att använda bättre platshållare för våra bilder.

Dominerande Färg Platshållare

Istället för att använda en fast färg för den bild som platshållare, vi hittar den dominerande färgen från den ursprungliga bilden och använda den som en platshållare. Denna teknik har använts under ganska lång tid av Google bildsök resultat samt av Pinterest i sitt elnät design.

Pinterest använder den dominerande färgen i bilden som bakgrundsfärg för bild som platshållare.

Det här kanske ser komplicerat att uppnå, men ett mycket enkelt sätt att åstadkomma detta är att skala ner bilden till ner till en 1×1 pixel och sedan skala upp det till storleken på den platshållare—en mycket grov uppskattning, men en enkel, no-fuss sätt att få en enda dominerande färg. Med hjälp av ImageKit, den dominerande färgen platshållare kan erhållas med hjälp av en fastkedjad omvandla i ImageKit som visas nedan.

<!– Ursprungliga bilden på 400×300 –>
<img src=”https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400 h-300″ alt=”originalbilden” />

<!– Dominerande färgen bild med samma mått –>
<img src=”https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-1 h-1:w-400,h-300″ alt=”dominerande färg platshållare” />

Platshållaren bilden är bara 661 byte i storlek jämfört med den ursprungliga bilden som är 12700 bytes—19x mindre. Och det ger en snyggare övergång erfarenhet från platshållare för att själva bilden.

Här är en video som visar hur denna effekt fungerar för användaren.

Se Pennan Dominerande färg platshållare – Lazy loading-bilder med hjälp av IntersectionObserver – exempel koden genom att ImageKit.io (@imagekit_io) på CodePen.

Låg bildkvalitet Platshållare (LQIP)

Vi kan förlänga ovan nämnda idén att använda en dominerande färg platshållare ytterligare. Istället för att använda en enda färg, vi använder en mycket låg kvalitet, suddig version av den ursprungliga bilden som platshållare. Den inte bara ser bra ut, men det ger också användaren en uppfattning om vad den faktiska bilden ser ut som och uppfattningen att bilden belastning pågår. Detta är bra för att förbättra den upplevda laddar erfarenhet. Denna teknik har använts av artister och Medium.

LQIP bild-URL exempel med hjälp av ImageKit:

<!– Ursprungliga bilden på 400×300 –>
<img src=”https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400 h-300″ alt=”originalbilden” />

<!– Låg bildkvalitet platshållare med samma mått –>
<img src=”https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400 h-300,bl-30,q-50″ alt=”dominerande färg platshållare” />

Den LQIP är 1300 byte i storlek, fortfarande nästan 10 gånger mindre än den ursprungliga bilden och en betydande förbättring när det gäller visuell upplevelse över alla andra platshållare teknik.

Här är en video som visar hur denna effekt fungerar för användaren.

Se Pennan LQIP platshållare – Lazy loading-bilder med hjälp av IntersectionObserver – exempel koden genom att ImageKit.io (@imagekit_io) på CodePen.

Det är klart att med hjälp av antingen dominerande färg eller LQIP platshållare ger en smidigare övergång från platshållaren till själva bilden, ger användaren en uppfattning om vad som ska komma i stället för att platshållare, och förbättrar laddar uppfattning.

Tips 2: Lägg till Bufferten Tid för Bilderna att Ladda

När vi diskuterade olika metoder för att utlösa bild laddar, vi kollade efter den tidpunkt där bilden går det virtuella, dvs bilden belastning utlöses när den övre kanten av bilden platshållare sammanfaller med den nedre kanten av visningsområdet.

Problemet med detta är att användarna kan bläddra riktigt snabbt igenom sidan och bilden kommer att behöva lite tid att ladda och visas på skärmen. I kombination med strypning eventuellt ytterligare fördröja belastning, kan användaren hamnar vänta några millisekunder längre för bild att visa upp. Inte bra för användarens upplevelse!

Samtidigt som vi kan få en ganska bra användarupplevelse med hjälp av Korsningen Observatör API för prestanda och LQIP för smidigare övergångar, det är ett annat enkelt knep som du kan använda för att se till att bilderna är alltid laddad helt när de kommer in i visningsområdet : införa en marginal till trigger-punkt för bilder.

I stället för att läsa in bilden exakt när den går in i det virtuella, ladda den när det är, låt oss säga, 500px innan det går in i den virtuella. Detta ger ytterligare tid, mellan den last som trigger och det faktiska inlägg i det virtuella, för bilderna att ladda.

Med Korsningen Observatör API, kan du använda parametern root tillsammans med rootMargin parameter (fungerar som standard-CSS-marginal-regeln), för att öka den effektiva bounding box som anses hitta skärningspunkten. Med event listener metod, istället för att kontrollera för skillnaden mellan bildens kant och vyns kant till 0, kan vi använda ett positivt tal för att lägga till några tröskel.

Se Pennan Lazy loading bilder med ytterligare tröskel – exempel koden genom att ImageKit.io (@imagekit_io) på CodePen.

Om du titta på följande screencast noga, kommer du att märka att den femte bilden i sekvensen läses in när den tredje bilden visas i vyn. På samma sätt, den sjätte bilden är laddad när den fjärde är i sikte, och så vidare. På detta sätt, vi ger tillräckligt med tid för bilderna att laddas helt och hållet, och i de flesta fall användaren kommer inte att se den platshållare på alla.

Om du inte märker tidigare, i alla våra exempel, den tredje bilden (image3.jpg alltid laddade upp framför, även om det är utanför visningsområdet. Detta var också göras efter samma princip: lägg något i förväg i stället för lastning precis på tröskeln för att bättre användarupplevelse.

Tips 3: Undvik Innehåll Reflow

Detta är en annan trivial punkt, som om lösas, kan bidra till att upprätthålla en bra användarupplevelse.

När det inte finns någon bild, den webbläsare som inte känner till den storlek som det kommer att ta. Och om vi inte anger det med hjälp av CSS, så det omslutande container skulle ha någon dimensioner, nämligen den att läsas som 0x0 pixlar.

När bilden laddats, kommer webbläsaren att släppa det i tv och återflöde innehållet för att passa det. Denna plötsliga förändring i layouten orsakar andra element för att flytta runt och det är kallade innehåll reflow, eller att flytta. Michael Scharnagl går in på djupet med att förklara hur detta skapar en dålig användarupplevelse.

Detta kan undvikas genom att ange höjden och/eller bredden för den omslutande behållaren, så att webbläsaren kan måla bilden behållare med känd höjd och bredd. Senare, när bilden laddats, eftersom behållarens storlek är redan angivna och bilden passar in perfekt, resten av innehållet att behållaren inte flytta.

Tips 4: Undvik Lazy Loading Varje Bild

Detta är ett misstag att utvecklare ofta gör eftersom det är super frestande att tro att skjuta upp bild laster är bra hela tiden. Men, precis som livet självt, det är möjligt att ha för mycket av det goda. Lazy loading kan minska den ursprungliga sidan laddas, men det kan också resultera i en dålig användarupplevelse om att vissa bilder är uppskjutna när de inte borde vara.

Vi kan följa vissa allmänna principer för att identifiera vilka bilder som bör vara lat laddad. Till exempel, en bild som finns i det virtuella, eller i början av webbsida, man ska nog inte vara lat laddad. Detta gäller alla header image, marknadsföring, banner, logotyper, eller egentligen vad som helst som användare ser när första landning på en sida. Kom också ihåg att mobila och stationära enheter har olika skärmstorlekar och därmed en annan antalet bilder som kommer att synas på skärmen i början. Du kommer att vilja ta den enhet som används i beaktande och bestämma vilka resurser att ladda upp framsidan och som lata belastning.

Ett annat exempel är en bild som är ännu lite utanför visningsområdet i den första lasten bör inte förmodligen inte vara lat laddad. Detta kommer med den princip som diskuterats ovan—belastning något i förväg. Så, låt oss säga att någon bild som är 500px eller en enda bläddra från botten av det virtuella kan laddas upp framsidan också.

Ytterligare ett exempel är om sidan är kort. Det kan vara bara en enda bläddra eller ett par rullar, eller kanske det är mindre än fem bilder utanför visningsområdet. I dessa fall kan du nog lämna lazy loading ut helt och hållet. Det skulle inte ge någon betydande nytta för slutanvändaren i form av prestanda och ytterligare ett JavaScript som du laddar om sidan för att aktivera lazy loading kommer att kompensera eventuella vinst du får från det.

Kapitel 5: Lazy Loading är Beroende av JavaScript

Hela idén med lazy loading är beroende av JavaScript aktiverat och finns i användarens webbläsare. Medan de flesta av dina användare som kommer troligen att ha JavaScript aktiverat för, är det viktigt att planera för de fall där det är det inte.

Du kan antingen visa ett meddelande som talar om för användarna varför bilderna inte laddas och uppmuntra dem att använda en modern webbläsare eller aktivera JavaScript.

En annan väg är att använda noscript-taggen. Men detta synsätt kommer med några gotchas. Denna fråga tråd på Stack Overflow gör ett bra jobb att ta itu med dessa frågor och är rekommenderad läsning för alla som funderar på att ta itu med denna uppsättning användare.

Kapitel 6: Populära JavaScript-Bibliotek för Lazy Loading

Sedan miljöer och uppgifter genomförandet kan variera mellan olika webbläsare och enheter, kanske du vill överväga en beprövad bibliotek för lazy loading snarare än att snurra upp något från scratch.

Här är en lista över populära bibliotek och plattform specifika plugins som gör att du kan genomföra lazy loading med minimal ansträngning:

    >Ännu en Lat Loader: Detta bibliotek använder Korsningen Observatör API och faller tillbaka till händelse-baserad lazy loading för webbläsare som ännu inte har stöd för det. Detta är bra för nästan alla HTML-element men tyvärr fungerar inte på bakgrunden bilder i CSS. Den goda nyheten är att det stöder IE tillbaka till version 11.

  • lazysizes: Detta är ett mycket populärt bibliotek med omfattande funktionalitet. Det inkluderar stöd för responsiv bild srcset och storlekar attribut och ger enastående prestanda även om det inte utnyttjar Korsningen Observatör API.
  • WordPress A3 Lata Last: Det finns massor av lazy loading-WordPress-plugins ute, men detta kommer med en robust uppsättning funktioner, inklusive en fallback när JavaScript är inte tillgänglig.
  • jQuery Lat: En enkel bibliotek som använder jQuery för genomförandet.
  • WeltPixel Lazy Loading-Enhanced: En Magento 2 förlängning.
  • Magento Lat Image Loader: en Annan Magento förlängning, för 1.x.
  • Shopify Lat Bild Plugin (betalas): Aktivera lazy loading på en Shopify webbplats.

Kapitel 7: Testa Lata Belastning

När du har genomfört lazy loading, kommer du sannolikt att vilja kontrollera att det fungerar som avsett. Det enklaste sättet skulle vara att öppna upp för utvecklare verktyg i din webbläsare.

Från det, gå till Network – > Bilder. När du uppdatera sidan för första gången, bör du endast se laddade bilder i listan.

Sedan, när du börjar att rulla ner på sidan, en annan bild belastning önskemål skulle få aktiveras och laddas. Du kan också märka tider för bild-ladda i vattenfall kolumn i den här vyn. Det skulle hjälpa dig att identifiera bild laddar frågor om något eller problem i att utlösa bild belastning.

Ett annat sätt skulle vara att köra Google Chrome Fyr revisionsberättelse på din sida efter att du har genomfört de förändringar och leta efter förslag under “Offscreen bilder”.

Slutsats

Vi har täckt en hel del av marken om lazy loading bilder! Lazy loading—om den genomförs väl kan ha betydande positiva effekter på din webbplats prestanda lastning prestanda och samtidigt minska den totala storleken på sidan och leveranskostnader, tack för att skjuta upp onödiga resurser på framsidan.

Så, vad väntar du på? Komma igång med lazy loading bilder nu!