Teknik
TypeScript - från obskyrt till självklart
TypeScript har växt och är ett närmast oumbärligt verktyg vid frontendutveckling.
Många webbplatser och tjänster idag innehåller väldigt stor volym data i form av bland annat bilder och video. Ett CDN, ”Content Delivery Network” är en central del i hur innehåll som bild, ljud och video levereras ut på webben. CDN:et avlastar servern och man får på så sätt hög prestanda med minimal fördröjning. En annan fantastisk fördel är att det även underlättar det redaktionella arbetet.
Tänk att du ska flytta. Antingen gör du hela jobbet själv, eller så tar du hjälp av släkt och vänner. Det blir samma resultat i slutändan, men om du får hjälp kommer det att gå mycket fortare.
Ett CDN är lite som er webbservers "släkt och vänner", det vill säga ett gäng andra servrar som hjälper till när data ska skickas ut till användarna. Dessa servrar är i sin tur ihopkopplade i ett supersnabbt globalt nätverk och specialiserade på att serva innehåll i form av bilder, filmer, kod eller dokument snabbt och säkert. Med denna bakgrund förstår man också varför det heter CDN – Content Delivery Network – ett nätverk specialbyggt för att leverera innehåll.
Att avlasta webbservern är dock bara en av många olika uppgifter som ett CDN har. När vi pratar med våra kunder om varför man bör använda ett CDN så är det framför allt de fantastiska prestandaökningar vi ser och den kraftfulla verktygslådan med hjälptjänster som man får tillgång till som vi lyfter fram. Att ha en snabb webbsida eller e-handel kan vara en stark konkurrensfördel både i termer av användarupplevelse och i hur Google och andra sökmotorer rankar sidan.
Då har du en webbserver som står på plats hos er eller hos en internetleverantör. Den är ensam ansvarig för en mängd olika arbetsuppgifter som behöver utföras i samband med att en sida ska servas till en webbplatsbesökare. Den ska inte bara serva själva HTML-sidan utan även alla bilder, typsnitt, kodfiler (CSS, JavaScript, XML, JSON m.m.) och eventuella filmer som finns på webbplatsen. Det ska den göra från en central plats (där den står) via en enda nätverksuppkoppling. Har man dessutom ett CMS i vilket man administrerar sina sidor ska servern dessutom hämta data från en databas och exekvera kod.
De flesta servrar klarar av detta helt okej. Ibland kan det hoppa och blinka lite på sidan innan allt är på plats, speciellt om det är många stora bilder, men allt kommer ju fram till slut.
Men om man inte nöjer sig med att det hoppar och blinkar? Om man både vill ha många bilder och en sida som laddar blixtsnabbt? Då ska man använda ett CDN. Den egna webbservern behöver nu bara fokusera på det som bara den kan göra: serva själva HTML-sidan. Allt annat runt om kring delegerar man till CDN:et.
Som ett experiment tog vi en helt vanlig startsida på en helt vanlig webbplats och tittade på hur datamängden fördelade sig på olika typer av filer:
Totalt är det cirka 1,3 MB (1300 kB) med data som ska skickas från server till klient vid ett besök till denna startsida. Korrekt implementerat skulle CDN:et kunna ansvara för 99% av all data, dvs. allt utom själva HTML-sidan.
De servrar som ingår i ett CDN är i grund och botten helt vanliga servrar så man undrar ju vad det är som gör att ett CDN så snabbt? Det är flera olika delar som sammantaget skapar denna markanta prestandaökning.
Själva grundprincipen för ett CDN är att man vill serva data från en server som, rent fysiskt, står så nära slutanvändaren som möjligt. Om den som surfar på webbplatsen sitter i Västerås vill man troligtvis att data servas från en server i Stockholm. Är det en person i Australien som besöker webbplatsen så vill man att servern står i Sydney.
Utan ett CDN skulle en användare i Australien behöva ladda data från en server i Stockholm - på andra sidan jordklotet. På vägen ska det passera genom en massa andra kablar, nätverk och routers. Det tar både tid och belastar nätet.
Med ett CDN så skulle det bara ta tid första gången en användare i Australien besökte webbplatsen. Vid detta första anrop skulle CDN-servern hämta hem lokala kopior av filerna och alla nästföljande besökare skulle få dessa kopior av filerna skickade till sig från den lokala servern i Sydney istället för att de skulle behöva skickas ända från Stockholm (igen).
Att spara undan lokala kopior kallas cachning och det är en väldigt viktig del av all teknik på Internet. Även webbläsaren på din dator håller sig med en egen cache där den stoppar undan filer för att slippa hämta nya filer varje gång du besöker en sida.
Förutom att en CDN-server står på en plats nära slutanvändaren rent fysiskt och jobbar med cachad data så är den även specialanpassad för att kunna serva filer snabbt. Dels sitter den inkopplad på ett nätverk som är väldigt snabbt, dels är den konfigurerad för hastighet, t.ex. genom att alla filer servas via nätverksprotokollet HTTP/2. En normal användare ser inget av detta annat än att det går undan.
Vi säger "server" i singularis, men i praktiken handlar det om flera servrar som står i datacenter, ihopkopplade i kluster. En och samma sida kan alltså i praktiken servas av flera olika servrar parallellt. De är konfigurerade för lastbalansering vilket innebär att de tillsammans hjälps åt och fördelar arbetet jämnt mellan sig. Så om en server helt plötsligt skulle få för mycket att göra träder de andra in och avlastar den.
Komprimering handlar om att minska mängden data som skickas. Man måste såklart fortfarande skicka all data i sin helhet, men man kan se till att göra det i ett format som är så kompakt och lättviktigt som möjligt.
Ett CDN lägger alltid automatiskt en viss komprimering på själva datatrafiken, i likhet med de flesta moderna webbservrar. Det är dock deras verktygslåda för framför allt bildkomprimering som gör CDN:en till något utöver det vanliga.
En bild är en bild, eller hur? Inte riktigt. Den kan skalas, beskäras, komprimeras, roteras, maskas och sparas ner i en mängd olika bildformat - JPEG, PNG, GIF, SVG, WebP osv. Alla dessa funktioner får man tillgång till om man använder ett CDN. En del funktioner kan man ställa in så det sker automatiskt. Ett CDN kan t.ex. känna av om besökaren har en modern webbläsare och serva en bild i WEbP-format istället för PNG eller JPEG. Bara det ger en bildfil som är 25 - 35% mindre i filstorlek än sin motsvarighet i JPEG eller PNG.
Men den största besparingen får man genom att anpassa bildernas storlek utifrån hur stora de behöver vara för att se bra ut på den enskilde användarens enhet, det som kallas responsiv bildhantering. En mobiltelefon har mycket mindre skärm än en typisk desktopdator och då är det onödigt att skicka stora bilder till mobiltelefonen, som ju dessutom ofta har sämre nätverkshastighet. Detta sker inte per automatik utan den som utvecklar webbplatsen definierar ett antal olika bildstorlekar som CDN:et sedan sparar ut bilden i. Sedan låter man webbläsaren avgöra vilken bildstorlek som ska laddas baserat på storleken på användarens webbläsarfönster.
Om vi går tillbaka till den typiska startsidan som vi nämnde inledningsvis så kan man med hjälp av rätt konfigurerad bildhantering spara många dyrbara kilobyte för de mobila användarna.
För att sidan ska se bra ut på en riktigt stor skärm (t ex 2560 x 1440 pixlar) behöver man ladda 1,4 MB bilddata. Samma sida som visas på en smartphone med en bildskärm på 360 x 640 pixlar behöver bara ladda 734 kB bilddata - bara hälften så mycket. Det är samma bilder med samma motiv, men deras storlek och ibland även beskärning har anpassats för användarens enhet.
För en redaktör kan det spara mycket tid. Tidigare var det vanligt att man var tvungen att spara ut flera olika versioner av samma bild manuellt och ladda upp varje bild för sig för att få till ett snyggt resultat. Med ett CDN slipper man det. Redaktören laddar bara upp den högupplösta versionen av bilden och sedan sparar CDN:et ut alla de storlekar som bilden behöver för att funka i den responsiva designen. Om man manuellt behöver se över beskärning av bilderna kan man göra det direkt via CMS:et. Eller så kan man låta CDN:ets AI hantera även detta. Den kan t ex identifiera ansikten på personer i bilderna och se till att bilderna beskärs med utgångspunkt från dessa.
Om man nu låter ett världsomspännande servernätverk cacha, serva, komprimera och hantera både bilder och annan data, tappar man inte kontrollen över filerna?
Alla dessa frågor är frågor som man bör ställa sig innan man implementerar ett CDN. I grund och botten skiljer det sig inte så mycket från andra molnbaserade tjänster. Det är externa servrar som står i stora datacenter distribuerade runt om i världen. De flesta företag använder andra molnbaserade tjänster idag såsom Google Docs, Office 365, SalesForce eller Jira.
Om man har en verksamhet som omgärdas av speciell lagstiftning avseende datahantering så är chanserna stora att man redan har policys för användning av molnbaserade tjänster. Är man osäker är vår rekommendation är att man går igenom den specifika CDN-leverantörens information. Generellt är det bra att se om leverantörens villkor innefattar en roll som personuppgiftsbiträde (dataprocessor) inom det avtal de erbjuder, men säkrast är att kontakta dem för GDPR-relaterade frågor.
Vad gäller cachning så stämmer det att filerna cachas i upp till ett år så länge som CDN:et inte får besked om något annat. Därför brukar man implementera en lösning som kallas ”fingerprinting”. Det innebär att om en bild eller annan fil uppdateras på en sida så förändrar man även bildens digitala fingeravtryck – i praktiken en sträng av tecken. CDN:et ser om teckensträngen förändras och vet därmed om att det är dags att hämta en ny version av filen. De brukar också ha inloggade kontrollpaneler med funktioner för att styra cachning och andra aspekter av deras datahantering för dig som kund.