Cache

Vad är Cache och hur jobbar vi med det?

När du besöker en hemsida via din webbläsare är det en hel del som sker bakom kulisserna. Vi ska prata lite om det och sedan dyka ner lite djupare i hur vi jobbar med cache och varför det är viktigt.

Hemsida i webbläsaren
För kommunikation mellan datorer (i detta fall din dator och en server någonstans) över nätverket behövs någon form av identifikation så att datorerna kan kommunicera med varandra – en IP-adress. Om du inte vet vad det är för något så kan du jämföra IP-adress med en vanlig hemadress, den berättar var du bor någonstans, den berättar var ditt nätverk finns.

När du skriver in ett domännamn i webbläsaren, låt oss ta webbpoolen.se som exempel, då kommer först webbläsaren att behöva översätta domännamnet till en IP-adress innan den kan upprätta en anslutning mot servern där hemsidan ligger. Detta görs med hjälp av DNS, som står för att översättningen av domännamn till IP-adress sker. Din dator behöver alltså först skicka iväg en förfrågan mot en DNS server för att översätta domännamnet till en IP-adress. För att din webbläsare inte ska behöva göra samma förfrågan för samma domännamn flera gånger om under en kortare tidsperiod ”cachas” översättningen från domännamn till IP-adress på flera olika nivåer längs med vägen – den cachas bland annat i din dator. Nästa gång du vill komma åt hemsidan kommer den att hämta IP-adressen lokalt från datorn.

När IP-adressen finns till godo börjar webbläsaren upprätta en anslutning mot servern där hemsidan ligger. Låt oss säga att hemsidan ligger på en server i Tyskland och du försöker komma åt den från en dator i Sverige, ja då kommer data behöva flöda mellan servern i Tyskland och ditt nätverk i Sverige. Det kanske låter som att det borde vara ohållbart att ha en hemsida på en server i Tyskland med främst svenska besökare, men faktum är att tiden det tar för att skicka data den sträckan inte behöver ta så lång tid, trots allt. På vägen fram till servern i Tyskland från ditt nätverk i Sverige kommer datan passera en mängd olika nätverk, dessutom kommer mediet datan färdas genom vara olika mellan noder (förgreningar eller slutpunkt) längs med vägen. När data färdas genom luften (radiovågor) når vi en hastighet på 300 000 km/s (ja, ljusets hastighet).

Nu föreställer vi oss att förfrågan från din webbläsare har anlänt till servern nere i Tyskland och nu kommer servern börja förbereda en respons som den sedan skickar tillbaka till dig i form av en eller flera filer – när det gäller hemsidor skickar servern först en HTML-fil. Därefter begär din webbläsare resterande resurser i form av stilmallar (CSS), Javascript och bilder. I normalfallet kan det bli upp emot 80 förfrågningar efter filer och bilder mellan server och klient (webbläsaren).

Låt oss säga att hemsidan du besöker består av 20 bilder med totala storleken 20MB (20 miljoner Bytes, eller 160 miljoner bits), då förstår du att det är en hel del att skicka över nätverket. Utan någon form av cache så hade servern behövt skicka samma resurser om och om igen varje gång du uppdaterar sidan i webbläsaren. De flesta webbläsare cachar/sparar automatiskt bilder och andra resurser för att minska nätverksbelastningen. Låt oss säga att det tog 10 sekunder för transaktionen av data (6 sekunder bara för att ladda ner bilderna). Tiden det tar beror bland annat på vilken nedladdningshastighet ditt nätverk har, samt vilken uppladdningshastighet servern i sig kan bistå med (viktigt att välja webbhotell med omsorg).

Nu har vi istället minskat nätverksbelastningen markant genom att spara resurser i den lokala webbläsaren. Vi kan gå några steg djupare för att öka hastigheten. När nu servern inte behöver skicka samma filer om och om igen så behöver den fortfarande bearbeta din förfrågan på nytt när du uppdaterar sidan i webbläsaren.

Låt oss då säga att hemsidan är skapad i WordPress och du använder en mängd olika plugins och ett långsamt tema så att det tar servern 2 sekunder (2 sekunder är LÅNG tid för en dator) att bara tugga genom koden innan data börjar skickas ut till din webbläsare på nytt. Här kan vi implementera cache på flera olika nivåer nere på servernivå för att skynda på processen.

Den åtgärden som ger snabbast responstider är att helt enkelt inte låta servern tugga genom samma kod om och om igen bara för att du uppdaterar webbläsarfönstret – i stället genererar vi en statisk HTML-fil som skickas ut. Så länge ingen förändring sker sett till innehåll kommer den statiska filen ligga kvar som den är. Om servern inte har en massa annat att göra, det vill säga att den är korrekt lastbalanserad så kan nu tiden det tar för servern att bearbeta din förfrågan och börja skicka ut en HTML-fil komma ner på så låg tid som 10ms (10 tusendels sekunder).

Nu har vi kommit så långt så att servern skickar en statisk fil trots att själva hemsidan är byggd i ett kraftfullt CMS, men vi gör fortfarande onödiga moment. Om HTML-filen inte har förändrats något mellan sidanropen så behöver vi ju inte skicka den på nytt varje gång? Nej, vi instruerar här webbläsaren att cacha/spara HTML-filen lokalt. Nästa gång du uppdaterar webbläsaren behöver servern fortfarande bearbeta ditt anrop men denna gång ger den en respons som instruerar webbläsaren om att ingen förändring är gjord så att webbläsaren kan läsa in den HTML-fil som redan är sparad. Denna respons kan vidare sparas på ett nätverk närmare dig så att anslutningen inte behöver gå hela vägen mellan Sverige och Tyskland varje gång.

Det går att dyka djupare än så här men nu hoppas vi att ni har en grundförståelse för varför cache är viktigt.

Välj oss som leverantör om du vill ha en samarbetspartner med breda kunskaper och förståelse på alla nivåer!