Varför dina bilder hör hemma på ett CDN (och vad ett bild-CDN lägger till)
Bilder är vanligtvis det tyngsta du skickar och den enklaste stora vinsten du inte tar. Vad en CDN fixar, och de fyra sakerna en bild-CDN gör som en vanlig inte gör.
Öppna DevTools på nästan vilken sida som helst, sortera nätverkspanelen efter storlek och titta på de tio översta raderna. På den överväldigande majoriteten av webbplatser kommer de alla att vara bilder, och den första kommer att vara flera gånger större än något annat.
Det är verkligen goda nyheter, eftersom det betyder att den största spaken som är tillgänglig för dig också är en av de enklaste att dra - och till skillnad från JavaScript kan bilderna optimeras helt utan att röra din applikationskod.
Två separata problem
Bilder är långsamma av två orelaterade skäl, och förvirrande är varför människor är besvikna över halva mått.
De är långt borta: ett foto på 400 kB som serveras från ett ursprung tar lika lång tid att nå Sydney som alla andra 400 kB gör, vilket är ett tag. Och de är för stora: fel dimensioner, fel format, kvalitetsinställningar som ingen har valt.
Ett vanligt CDN löser det första problemet helt och det andra inte alls. Det kommer att leverera din onödigt enorma foto mycket snabbt faktiskt. Det är värt att ha - men det är hälften av den tillgängliga vinsten, och vanligtvis den mindre hälften.
De fyra saker som en bild-CDN tillför
1. Ändra storlek per begäran
Den största enskilda besparingen, och den minst glamorösa. Ett foto på 3000 pixlar som visas i ett 400 pixlar långt kort bär ungefär 56 gånger så mycket pixeldata som visas. Ändra storlek till vad som faktiskt visas - runt två gånger CSS dimensioner, för hög-DPI-skärmar - rutinmässigt tar bort 70 till 90 procent av byte innan någon formatkonvertering beaktas.
2. Formatförhandling
Webbläsare annonserar vilka bildformat de accepterar på varje begäran. En bild CDN läser den rubriken och tjänar AVIF till klienter som stöder det, WebP till dem som inte gör det och originalet till något äldre - bestämmer per förfrågan, utan <picture> element som ska underhållas och inget byggsteg som ska synkroniseras.
3. Transformer som drivs av webbadressen
Detta är den del som förändrar hur du arbetar. Istället för att generera varianter i förväg begär du den variant du vill ha som en del av webbadressen – en bredd, en beskärning, en kvalitetsinställning, ett formatöverskridande. Kanten producerar det på första begäran och cachelagrar resultatet, så efterföljande förfrågningar för samma variant är vanliga cacheträffar.
Den praktiska effekten är att ditt mediebibliotek innehåller ett högkvalitativt original per bild och inget annat. Ingen miniatyråtergivning, ingen ombyggnad när en designer ändrar en kortbredd, inga föräldralösa derivatfiler ackumuleras på flera år. En layoutändring blir en ändring av ett nummer i en webbadress.
4. Leverans från närområdet, med allt cachat
Det transformerade resultatet cachas vid kanten som vilket annat objekt som helst, så konverteringskostnaden betalas en gång per variant snarare än per begäran.
Varför detta slår en byggtidspipeline
Att skapa bildvarianter vid byggtiden fungerar och fungerar bra ända fram till dess att det uppfyller ett CMS-system.
Bygg pipelines bryts ner eftersom innehållet inte är byggt. Någon laddar upp ett 4000-pixel produktfoto genom adminpanelen på en fredag eftermiddag, och inga bygg körningar. En designer ändrar ett rutnät från tre kolumner till fyra, och varje förgenererad bredd är nu fel. En ny enhetskategori kommer och det finns ingen variant för den. Var och en är individuellt hanterbar och kollektivt anledningen till att de flesta webbplatsers bildoptimering tyst slutar fungera inom cirka arton månader efter att ha installerats.
Transformation på begäran har inte detta felläge, eftersom det inte finns något att hålla synkroniserat. Den rätta varianten är vad URL:en än begär.
Detta är vanligtvis den snabbaste tillgängliga vägen till en bättre Största Contentful Paint, eftersom LCP-elementet på de flesta sidor är en stor hjältebild. Optimera att en bild ofta flyttar en Core Web Vital från rött till grönt på en eftermiddag - vilket inte är något du kan säga om många prestandaförändringar.
De tre sakerna du behöver för att komma rätt i HTML-koden
Kanten hanterar bytena; några få markeringsdetaljer avgör om webbläsaren använder dem på ett bra sätt.
- Använd srcset och storlekar så att en telefon begär en bild i telefonstorlek istället för att ladda ner skrivbordet och skala ner det. Utan detta hjälper storleksändring bara de besökare som råkar vara på små skärmar.
- Ange attribut för bredd och höjd på varje bild. Det kostar ingenting och förhindrar layoutförskjutningen som inträffar medan filen fortfarande anländer.
- Ladda aldrig LCP-bilden. En riktig besparing när du laddar ner under fällningen är att du inte behöver lägga den på din hjältebild. Kontrollera att ditt CMS inte läggs till
loading="lazy"Allting urskillningslöst.
Vanliga frågor
Vad är en bild-CDN?
Ett bild-CDN är ett innehållsleveransnätverk som även omvandlar bilder på begäran – ändrar storlek på dem, konverterar dem till moderna format som WebP eller AVIF, justerar kvalitet och beskärning – och cachar resultaten vid edge. Du lagrar ett högkvalitativt original, och varje besökare får en version som är lämplig för deras webbläsare och det utrymme som bilden upptar.
Ska jag lägga mina bilder på ett CDN?
Ja, för nästan alla webbplatser med besökare utanför serverns omedelbara region. Bilder står vanligtvis för det mesta av en sidas totala vikt, så att betjäna dem från en närliggande kant ger den största enskilda förbättringen av laddningstiden som finns tillgänglig. Lägga till on-the-fly storleksändring och format konvertering föreningar det, eftersom avstånd och filstorlek är separata problem och en vanlig CDN bara behandlar den första.
Hur mycket kan bildoptimering minska sidans vikt?
Ofta med 80 till 90 procent för själva bilderna. Ett 2,4 MB-foto som ändrats till dess visade dimensioner kan sjunka till cirka 900 KB, och konvertera det till AVIF kan ta det under 200 KB. Storleksändringen står normalt för mer av sparandet än formatändringen, eftersom överdimensionerade bilder är extremt vanliga.
Är en bild-CDN bättre än att generera bilder vid byggtid?
För webbplatser med innehåll som hanteras via ett CMS, i allmänhet ja. Bygg rörledningar kräver att alla nödvändiga varianter är kända och regenereras i förväg, vilket bryts när någon laddar upp en överdimensionerad bild utanför en byggnad eller en designer ändrar en layoutbredd. Transformation på begäran har inget att hålla i synk – den nödvändiga varianten är vad än webbadressen begär, genererad en gång och sedan cachad.
Behöver jag fortfarande srcset om jag använder ett bild-CDN?
Jaha. CDN kan producera vilken storlek du begär, men bara webbläsaren känner till visningsområdet, enhetens pixelförhållande och layouten. srcset och storlekar är hur webbläsaren berättar för CDN vilken storlek den faktiskt behöver. Utan dem begär varje enhet samma bild oavsett skärmstorlek, och mycket av fördelen med att ändra storlek på begäran går oanvänd.
Bilder är den tyngsta delen av de flesta sidor och därför den största tillgängliga vinsten. Ett CDN fixar avståndet, ett bild-CDN fixar också storleken genom att ändra storlek och konvertera per begäran och cacha resultatet. Ladda upp ett original, begär varianter efter webbadress, använd srcset så att webbläsare frågar efter rätt och håll din hjältebild borta från lata laddningar.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
