Lat laddning skjuter upp laddningen av resurser tills de behövs, oftast genom att fördröja bilder, iframes och komponenter tills de närmar sig det synliga området på skärmen. Syftet är att minska det arbete som krävs för att rendera den första vyn, så att innehållet en besökare ser omedelbart inte konkurrerar om bandbredd och bearbetning med innehåll långt under vecket som kanske aldrig visas alls.
Tekniken har blivit enkel att tillämpa för bilder och iframes, där ett inbyggt webbläsarattribut hanterar det utan JavaScript, där webbläsaren bestämmer när den ska börja laddas baserat på närhet till visningsporten och anslutningsförhållanden. För komponenter och rutter uppnår koddelning motsvarande resultat genom att skjuta upp JavaScript-paket tills en rutt besöks eller en funktion används, vilket avsevärt kan minska mängden skript som måste laddas ner och köras innan en sida blir interaktiv.
Det vanligaste och mest skadliga misstaget är att tillämpa det urskillningslöst, inklusive på innehåll i den ursprungliga visningsporten. Lat inläsning av huvudbilden fördröjer exakt det element som avgör den största mängden innehållsfärg, och ger ett sämre resultat än att inte tillämpa tekniken alls. Det korrekta mönstret är att ladda innehåll ovanför mitten ivrigt, helst med en prioritetshint, och att bara skjuta upp det som verkligen finns nedanför mitten. Generell tillämpning via ett plugin eller en global inställning är hur webbplatser får sämre inläsningsstatistik efter att ha implementerat en prestandaoptimering.
Layoutstabilitet är den andra faktorn. Uppskjutna bilder som anländer utan reserverat utrymme gör att innehållet förskjuts när det laddas, vilket omvandlar en laddningsförbättring till ett visuellt instabilitetsproblem. Explicita dimensioner eller bildförhållanden på varje uppskjutet element är inte valfria, och en platshållare som upptar rätt utrymme är det som gör uppskjutningen osynlig för användaren snarare än bara snabbare.
Det finns fall där tekniken är olämplig. Innehåll som måste finnas för att sökmotorer ska kunna indexera på ett tillförlitligt sätt, utskrivbara sidor där allt måste renderas och gränssnitt där användare rutinmässigt skrollar snabbt igenom långa listor lider alla av aggressiv uppskjutning. I det sista fallet laddas bilder som bara laddas när de närmar sig visningsfönstret för sent för en snabb skrollare, vilket producerar en ström av tomma platsmarkörer och en större laddningsmarginal eller en annan strategi krävs.
En relaterad faktor är vad som händer när uppskjutning misslyckas. Om bilder bara laddas via JavaScript som inte körs, på grund av ett fel, ett blockerat skript eller en webbläsare utan stöd, renderas sidan utan sina bilder och det finns ingen reservlösning. Uppskjutning i en nativ webbläsare undviker detta helt, vilket är en anledning till att det bör föredras framför skriptbaserade implementeringar där det räcker. Där en skriptbaserad metod verkligen behövs är det en liten mängd arbete att tillhandahålla en reservlösning som laddar innehållet när mekanismen inte är tillgänglig, vilket förhindrar en kategori av fel som är osynlig vid normal testning och påverkar en liten men verklig andel besökare.
Med omdöme är uppskjutning bland de mer effektiva teknikerna som finns tillgängliga för sidor med omfattande innehåll nedanför mitten, vilket beskriver de flesta produktlistningar, artiklar och långa marknadsföringssidor. I praktiken är det en del av en bredare laddningsstrategi som behandlas i webbprestanda arbete, tillsammans med bildformat och storlek, resursprioritering och paketstruktur, och dess inverkan är störst i e-handel sammanhang där kategorisidor innehåller dussintals bilder och mobilbesökare bär hela kostnaden för att ladda alla på en gång.