Gzip-komprimering

Gzip-komprimering är en metod där din webbserver packar ihop textbaserade filer, som HTML, CSS och JavaScript, innan de skickas till besökarens webbläsare. Tänk på ett tjockt paket du ska posta: du kan skicka det som det är, eller vika ihop innehållet så att det tar mindre plats i lådan, och det senare är ungefär vad servern gör med din kod varje gång någon öppnar en sida. Filerna blir ofta 60 till 80 procent mindre på vägen över nätet, webbläsaren packar upp dem på ett ögonblick, och besökaren märker ingenting annat än att sidan känns snabbare. Själva innehållet rörs inte: sidans H1, texten och din strukturerade data ser exakt likadana ut på andra sidan.

Det bästa med det hela är att du sällan behöver bygga något själv, eftersom nästan alla moderna webbhotell och de flesta CMS redan tillhandahåller funktionen och det i regel räcker att slå på en inställning. Här går vi igenom hur tekniken fungerar, vad den ger för hastigheten och för ditt löpande SEO-arbete, och hur du kontrollerar att den verkligen är på. Se det som samma sorts grundarbete som att se till att sidorna faktiskt indexeras och att följa upp läget i Search Console.

Vad tekniken gör med dina filer

Gzip är både ett filformat och ett program som kommer från GNU-projektet, där det användes för att packa ihop filer långt innan det blev en självklar del av webben, och namnet står helt enkelt för GNU zip. På en webbplats sker allt i realtid: webbläsaren ber om en fil, servern packar ihop den innan den skickas, och webbläsaren packar upp den när den kommit fram. Det är samma sorts osynliga serverarbete som när ett SSL-certifikat krypterar trafiken, och lika lite som krypteringen är det cloaking: innehållet är identiskt, det är bara paketeringen som skiljer.

Det som är värt att förstå är att metoden bara är vettig för textbaserade format, eftersom kod består av enorma mängder upprepning där samma taggar, klassnamn och mellanslag återkommer om och om igen. Bilder och video är redan komprimerade. Där finns nästan inget att hämta. Det gör Gzip till en teknisk åtgärd och inget annat, alltså inte en fråga om ordantal eller nyckelordstäthet.

Filtyper där komprimeringen verkligen gör skillnad:

• HTML-dokument, som ofta innehåller mycket upprepad struktur, inklusive metabeskrivningar och Open Graph-taggar i head
• CSS-filer, där samma egenskaper och värden återkommer rad efter rad, inte minst på en tung landningssida
• JavaScript, inklusive stora bibliotek och ramverk
• JSON-svar från API:er och dynamiskt innehåll, till exempel JSON-LD som bär din schema-markup
• SVG-grafik, som i grunden bara är text
• XML, sitemaps och RSS-flöden från bloggen i din innehållsstrategi

Så fungerar komprimeringen

Under huven läser LZ77 igenom filen och letar efter sekvenser som redan förekommit, och i stället för att upprepa en identisk textsträng lägger den in en kort referens som säger “det här har du redan sett, hämta det där bak”. Ju mer upprepning i koden, desto hårdare går den att packa. En minifierad fil kan därför krympa rejält ändå.

Tre saker sker i tur och ordning när en fil hämtas:

• Webbläsaren talar om vilka komprimeringsmetoder den klarar av
• Servern packar filen och svarar med headern Content-Encoding, ett svarshuvud i samma familj som det som bär noindex
• Webbläsaren packar upp filen och jämför kontrollsumman CRC med originalet

Stämmer inte kontrollsumman vet webbläsaren att något gått fel under överföringen, och det är därför du kan lita på att den uppackade koden blir exakt likadan som originalet, tecken för tecken, ända ner till radbrytningar som CR LF. Hela utbytet styrs av HTTP och kräver ingen inställning i webbläsaren. Att servern skickar färre byte brukar dessutom vara snällt mot din crawl budget, eftersom Googlebot håller sig inom ett tak för hur hårt den får belasta servern.

Därför märks mindre filer i hastighet och ranking

Poängen är inte tekniken i sig utan vad mindre filer gör för upplevelsen, och det märks tydligast för besökare på mobil eller på en långsammare uppkoppling där varje sparad kilobyte räknas. Google mäter hur snabbt och stabilt dina sidor laddar genom Core Web Vitals, och de signalerna vägs in när Googles algoritm sorterar sökresultaten, tillsammans med system som RankBrain som tolkar vad sökaren egentligen vill ha. För en verksamhet som slåss om lokala sökresultat kan marginalerna vara små.

Snabbare filöverföring påverkar flera saker samtidigt:

• Kortare total laddningstid för hela sidan, vilket i regel också syns i sessionslängden
• Tidigare FCP, alltså när besökaren ser något på skärmen
• Lägre förbrukning av bandbredd, vilket kan hålla nere kostnaden hos webbhotellet
• Mindre dataanvändning för besökare med begränsad mobil surf
• En sida som känns responsiv innan allt hunnit laddas klart, en klassisk detalj i konverteringsoptimering

Komprimering fixar inte en svag plats i SERPen på egen hand, och den ändrar varken din klickfrekvens i sökresultatet eller kvaliteten på texten. Men den tar bort en onödig broms, och en sida som skickar mindre data hinner rita upp innehållet tidigare. Det är den sortens tekniska grund man börjar med innan man ger sig på svårare saker som länkbygge och ämnesauktoritet.

Filer du ska och inte ska packa

Packa alltid:

• HTML, CSS och JavaScript, oavsett hur små filerna verkar
• JSON och XML, som packas ovanligt bra, inklusive din XML-sitemap
• SVG-filer, eftersom de är ren text bakom kulisserna
• Teckensnittsformat som levereras okomprimerade

Låt vara i fred:

• JPEG, PNG och WebP
• Video- och ljudfiler
• ZIP-arkiv och andra redan packade paket
• PDF-filer, som ofta har egen komprimering inbyggd

Och för att ge en känsla för vinsten, här är typiska besparingar för textfiler:

Siffrorna varierar mellan olika sajter, men storleksordningen brukar hålla, och vill du veta var du står jämfört med andra i branschen går det att väva in i en konkurrentanalys.

Två metoder som kompletterar varandra

Brotli är en nyare metod som Google släppte, och den packar textfiler något hårdare, särskilt på de högsta nivåerna. Så varför använder inte alla bara den? Svaret är att det sällan behöver vara antingen eller: servern kan titta på vad besökarens webbläsare stöder och välja Brotli när det går, med Gzip som säker reserv, från gamla Windows-datorer till nyare macOS-maskiner.

Så här brukar valet falla ut i praktiken:

• Har webbhotellet båda: låt servern välja automatiskt
• Har du bara en metod tillgänglig: kör den, skillnaden mellan dem är liten
• Bygger du om sajten: se till att fallbacken faktiskt finns kvar

Så aktiverar du komprimeringen steg för steg

Hur du slår på funktionen beror på var din webbplats bor och vilket verktyg du använder, men i de flesta fall är det en engångsåtgärd som tar några minuter. Gången är densamma oavsett plattform:

1. Logga in på ditt webbhotell eller din CMS-panel och leta upp inställningarna för prestanda.
2. Kontrollera om komprimering redan är på, så att du inte gör dubbelt arbete.
3. Aktivera den via panelen, en plugin eller serverns konfigurationsfil och spara ändringarna.
4. Töm all cache, ladda om sidan och kontrollera resultatet.

På WordPress

Kör du WordPress är den enklaste vägen ofta en cache-plugin, eftersom de flesta prestandapluginer har en kryssruta som antingen aktiverar komprimeringen eller skriver rätt serverregler åt dig. Du behöver sällan röra en enda rad kod.

Några saker att tänka på:

• Slå på funktionen på ett ställe, inte i flera pluginer samtidigt
• Kombinera gärna med minifiering av CSS och JavaScript
• Kontrollera efteråt, eftersom vissa teman sätter egna regler
• Töm all cache, annars testar du en gammal version av sidan

Via webbhotellet

Har du ett modernt webbhotell är chansen stor att allt redan är påslaget, och flera leverantörer, till exempel SiteGround, sköter det åt dig på servernivå utan att du behöver göra något alls. Är det inte på hittar du oftast inställningen i kontrollpanelen under prestanda, hastighet eller optimering.

Tre vägar när inställningen inte syns:

• Fråga supporten om komprimering är aktiverad för ditt konto, det är en helt normal fråga
• Lägg in reglerna i filen .htaccess om servern kör Apache, alltså samma fil som ofta sköter omdirigeringar, men ta en säkerhetskopia först
• Låt en plugin sköta det åt dig om du känner dig osäker på kod

Hur vet du att komprimeringen är på?

Att slå på en inställning är en sak, att veta att den gör jobbet är en annan, och lyckligtvis går kontrollen snabbt utan att du behöver några dyra SEO-verktyg.

Verktyg du kan använda

• Ett gratis onlineverktyg av typen Check Gzip Compression, där du klistrar in din adress
• Webbläsarens inbyggda utvecklarverktyg, oavsett om du sitter på Windows eller macOS
• Kommandoradsverktyg för dig som vill se svarshuvuden i klartext
• Den tekniska genomgången i ett större SEO-verktyg, som Ahrefs och liknande plattformar, om du redan har tillgång till en

För de flesta räcker onlineverktyget, som ger en tydlig bekräftelse på om filerna packas och hur mycket du sparar.

Läsa Content-Encoding-headern

Vill du se det med egna ögon öppnar du utvecklarverktygen, går till fliken Network och laddar om sidan, klickar på huvuddokumentet och letar i svarshuvudet. Står det gzip där är saken klar. Ser du ingen sådan rad skickas filen okomprimerad, och då är det dags att gå tillbaka till stegen ovan.

Vanliga orsaker till att headern saknas

• En cache serverar en gammal version av sidan
• Komprimeringen är bara påslagen för vissa filtyper
• En mellanliggande tjänst som ett CDN tar bort headern på vägen
• Du testar en fil som redan är komprimerad, till exempel en bild

Töm cachen, testa flera filtyper och kontrollera igen innan du felsöker vidare. Nio gånger av tio är det cachen som lurar dig.

Det här är en av de där sällsynta förbättringarna som är billig, snabb att göra och svår att ångra: du krymper filerna, sidan laddar snabbare och du lägger en trygg teknisk grund för hela ditt SEO-arbete att bygga vidare på. Snabbare sidor gör sällan hela jobbet, men de tar bort friktion på vägen till en konvertering. Har du kontrollerat att headern säger gzip och att bara textfilerna packas, så har du gjort det som behövs. Nästa steg blir gärna caching och minifiering, och efter det innehållet som faktiskt drar besökare, men det är en annan historia.