Webbplatsen tar 4 sekunder att öppna, och besökaren lämnar. Låter det bekant? Oftare än inte ligger problemet inte i webbhotellet eller i bilder. Sidorna väger helt enkelt mer än de borde eftersom servern levererar dem "som de är" utan komprimering.

GZIP-komprimering minskar storleken på HTML, CSS och JavaScript med 60-80% innan de skickas till webbläsaren. För WordPress är detta inte en tung plugin med massor av inställningar, utan ett direktiv i konfigurationen eller en kryssruta i adminpanelen. Enligt W3Techs används komprimering av mer än 85% av webbplatserna på internet, och om din webbplats inte är bland dem förlorar du sökrankning och konverteringar helt i onödan.

Här är sju fungerande sätt att aktivera GZIP: från manuell redigering av.htaccess till ett par klick i en plugin. I slutet visar jag hur du kontrollerar resultatet och går igenom vanliga frågor om kompatibilitet med CDN, Brotli och cachning.

💡 Snabb översikt:

• Lägg till komprimeringskod i .htaccess via FTP
• Skriv gzip on och gzip_types i nginx.conf
• Aktivera komprimering med en kryssruta i W3 Total Cache eller WP Rocket
• Kontrollera resultatet i Chrome DevTools eller GiftOfSpeed

Vad är GZIP-komprimering och varför behöver en WordPress-webbplats det

GZIP är en komprimeringsalgoritm som fungerar på servernivå: innan den skickas till webbläsaren "packar" den textfiler till en mer kompakt form. Webbläsaren packar upp dem i farten och renderar sidan som vanligt. Användaren märker ingen skillnad, medan mängden överförd data minskar flera gånger om.

Vad som exakt komprimeras: HTML-sidkod, CSS-stilmallar, JavaScript-skript, XML-filer, typsnitt och SVG. GZIP rör inte bilder; det finns separata komprimeringsformat för dem (WebP, AVIF) och optimeringsplugins.

Skillnaden i siffror är lätt att se i Chrome DevTools: samma sida före och efter komprimering skiljer sig i storlek med två till tre gånger. Multiplicera det med antalet besökare per månad så får du seriösa besparingar i trafik och laddningstid.

En viktig nyans: GZIP är inte det enda alternativet. Moderna servrar stöder Brotli, en algoritm från Google som komprimerar textfiler 15-25% bättre än GZIP. Men Brotli är inte tillgängligt hos alla webbhotell, medan GZIP fungerar överallt inklusive de äldsta konfigurationerna. Därför är det alltid värt att börja med GZIP, och koppla in Brotli som nästa nivå när grunden är klar.

Metod 1: via.htaccess på Apache

Det vanligaste scenariot: webbplatsen körs på Apache, och allt du behöver göra är att lägga till några rader i filen .htaccess i webbplatsens rot.

Var.htaccess finns. Anslut till servern via FTP (till exempel genom FileZilla) eller gå till webbhotellets filhanterare. I rotmappen för webbplatsen (där wp-config.php och mapparna wp-content, wp-admin finns) hittar du .htaccess. Ladda ner den till din dator; vi redigerar lokalt så att du snabbt kan återställa vid ett fel.

Vad du ska lägga till. Öppna .htaccess i en textredigerare (Notepad++, VS Code, Sublime Text) och lägg till följande block FÖRE raderna # BEGIN WordPress:

1
<IfModule mod_deflate.c>
2
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
3
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
4
  AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml
5
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
6
  AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf
7
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
8
 
9
  BrowserMatch ^Mozilla/4 gzip-only-text/html
10
  BrowserMatch ^Mozilla/4.0[678] no-gzip
11
  BrowserMatch bMSIE !no-gzip !gzip-only-text/html
12
  Header append Vary User-Agent
13
</IfModule>

Vad som händer här. Blocket <IfModule mod_deflate.c> kontrollerar om modulen mod_deflate är aktiverad på servern (hos de flesta webbhotell är den aktiverad som standard). Direktiven AddOutputFilterByType DEFLATE anger vilka filtyper som ska komprimeras. Raderna BrowserMatch är en krycka för gamla versioner av Internet Explorer som förhindrar gzip-buggar i IE6 och äldre. Header append Vary User-Agent talar om för proxyservrar att ta hänsyn till användarens webbläsare vid cachning.

Spara filen och ladda upp den tillbaka till servern och ersätt den befintliga. Innan detta, se till att göra en säkerhetskopia av den ursprungliga .htaccess; om webbplatsen går ner är det bara att återställa den gamla versionen så fungerar allt som förut.

Om webbplatsen efter uppladdning ger fel 500, kontrollera om det finns extra mellanslag eller radbrytningar före <?php eller efter avslutande taggar i filen. Ett fel i .htaccess bryter hela webbplatsen, så det är bättre att göra redigeringar en i taget och kontrollera efter varje.

Metod 2: på en NGINX-server

NGINX hanterar komprimering annorlunda än Apache. Här finns ingen .htaccess, och alla inställningar skrivs i filen nginx.conf eller i konfigurationsfilen för en specifik webbplats (vanligtvis i /etc/nginx/sites-available/).

Lägg till eller avkommentera följande rader i sektionen http eller server:

1
gzip on;
2
gzip_vary on;
3
gzip_min_length 1000;
4
gzip_comp_level 6;
5
gzip_types text/plain text/css text/javascript
6
           application/javascript application/x-javascript
7
           application/rss+xml application/xml application/xhtml+xml
8
           image/svg+xml image/x-icon
9
           font/ttf font/otf application/x-font-ttf
10
           application/vnd.ms-fontobject;
11
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Efter att du gjort ändringar, kontrollera konfigurationssyntaxen med kommandot nginx -t och ladda om NGINX: sudo systemctl reload nginx.

Parametern gzip_comp_level 6 är en kompromiss mellan komprimeringsnivå och processorbelastning. Ett värde på 1 är minimal komprimering, 9 är maximal. I praktiken ger nivå 6 nästan samma besparingar som 9 men förbrukar märkbart mindre serverresurser.

Metod 3: på en IIS-server (Windows Server)

IIS är en webbserver från Microsoft som används på Windows-webbhotell. Aktivering av komprimering här görs på två sätt: via det grafiska gränssnittet eller kommandoraden.

Via IIS-gränssnittet. Öppna IIS Manager. I avsnittet "Komponenter" → "Tjänster" hittar du "Komprimering". Markera kryssrutorna "Aktivera statisk innehållskomprimering" och "Aktivera dynamisk innehållskomprimering". Klicka på "Verkställ" i panelen "Åtgärder".

Via kommandoraden (som administratör):

1
:: Static compression
2
appcmd set config /section:urlCompression /doStaticCompression:True
3
 
4
:: Dynamic compression
5
appcmd set config /section:urlCompression /doDynamicCompression:True

Statisk komprimering cachar redan komprimerade versioner av filer på disk, vilket sparar processortid. Dynamisk komprimering komprimerar svar "i farten" och passar för personaliserade sidor men belastar processorn. I praktiken för WordPress är båda lägena aktiverade: statisk hanterar CSS/JS medan dynamisk hanterar HTML för varje sida.

Metod 4: via webbhotellets kontrollpanel

De flesta moderna webbhotell aktiverar GZIP som standard. Om du finns på cPanel, gå till avsnittet "Webbplatsoptimering" eller "Prestanda" och leta efter reglaget "Komprimering" eller "Komprimera innehåll". På Plesk är vägen liknande: "Prestanda" → "Utgående komprimering".

Om du inte hittar reglaget, skriv till webbhotellets support. Detta är en standardförfrågan; teknisk support svarar på den inom några minuter och aktiverar ofta komprimering på servernivå i ett enda svar. Du behöver inte förklara vad GZIP är; det räcker att skriva "Vänligen aktivera GZIP-komprimering för min webbplats".

Du kan kontrollera om webbhotellet redan komprimerar sidor före några redigeringar; metoden beskrivs i avsnittet "Hur du kontrollerar om komprimering är aktiverad" nedan. Om kontrollen visar att GZIP fungerar, hoppa över alla servermetoder och gå vidare till plugins endast om du vill hantera komprimering från WordPress adminpanel.

Metod 5: W3 Total Cache-plugin

W3 Total Cache är ett av de äldsta caching-pluginen i WordPress arkiv med en miljon aktiva installationer och 4,5 i betyg på WordPress.org. GZIP-komprimering aktiveras i det med en separat kryssruta och kräver inte att du rör serverfiler.

Installera pluginet från WordPress arkiv, gå till Performance → Browser Cache och leta upp sektionen "HTTP (gzip) compression". Kryssa i rutan "Enable HTTP (gzip) compression" och spara inställningarna. Pluginet lägger automatiskt till nödvändiga direktiv i .htaccess eller konfigurerar NGINX-regler beroende på vilken server webbplatsen körs på.

• Fördelar: rör inte serverfiler manuellt, en miljon installationer bekräftar stabilitet, kompatibelt med CDN och Brotli
• Nackdelar: gränssnittet är överbelastat med alternativ, en nybörjare kan lätt förstöra cachelagringen med fel kryssruta

Metod 6: WP Rocket-tillägget

WP Rocket är ett premiumtillägg för prestanda som automatiskt lägger till GZIP-regler i .htaccess efter aktivering. Det finns inga komprimeringsinställningar i det; det aktiveras automatiskt vid installation.

• Fördelar: noll manuellt arbete, komprimering aktiveras automatiskt, tillägget löser också en rad relaterade uppgifter (cachning, lazy loading, minifiering)
• Nackdelar: betalversion (från $59 per år), att betala enbart för GZIP är inte motiverat

Om du redan har köpt WP Rocket för andra uppgifter fungerar komprimeringen redan. Om du funderar på att skaffa tillägget enbart för GZIP, gör det inte: .htaccess eller W3 Total Cache gör samma sak gratis.

Metod 7: WP Super Cache-tillägget

WP Super Cache är ett gratis cachningstillägg från Automattic (samma företag som ligger bakom WordPress.com). Det fungerar enklare än W3 Total Cache: färre inställningar, mindre risk att något går sönder.

Installera tillägget, gå till Inställningar → WP Super Cache → Avancerat och hitta alternativet "Komprimera sidor så att de levereras snabbare till besökare". Aktivera och spara.

• Fördelar: gratis, enkelt gränssnitt, stabil kod från Automattic
• Nackdelar: underlägset W3 Total Cache i cachningsfunktionalitet, ingen finjustering av komprimeringstyper

Så fungerar GZIP-komprimering i praktiken

När en webbläsare begär en sida skickar den headern Accept-Encoding: gzip, deflate, br, vilket betyder "jag förstår gzip, deflate och brotli, skicka i något av dessa format". Servern ser denna header, kontrollerar om komprimering är aktiverad för den begärda filtypen, och i så fall komprimerar den svaret och lägger till headern Content-Encoding: gzip.

Webbläsaren tar emot den komprimerade datan, packar upp den i minnet och renderar sidan. För användaren sker allt omedelbart; gzip-uppackning tar bråkdelar av en millisekund även på en svag mobil enhet.

Denna mekanism är universell: den fungerar på samma sätt för Apache, NGINX, IIS och alla WordPress-tillägg. Tillägg uppfinner inte sin egen komprimeringsmetod; de lägger helt enkelt till samma serverdirektiv som vi skrev manuellt i de tre första metoderna.

Vad Google PageSpeed Insights och GTmetrix visar

Båda tjänsterna, PageSpeed Insights och GTmetrix, kontrollerar komprimering under varje granskning och markerar uttryckligen problemet om textresurser levereras utan GZIP.

I PageSpeed Insights visas varningen som "Aktivera textkomprimering" i avsnittet "Möjligheter" i granskningen. Lighthouse (motorn bakom PageSpeed Insights) uppskattar direkt de potentiella besparingarna i kilobyte för varje okomprimerad resurs. I GTmetrix finns en liknande kontroll, "Aktivera GZIP-komprimering" i kategorin "Innehåll".

En viktig punkt: varken PageSpeed Insights eller GTmetrix skiljer mellan GZIP och Brotli på rekommendationsnivån. Om komprimering är aktiverad med någon av dessa metoder kommer granskningen att visa en grön bock. Så GZIP räcker för att klara granskningen.

Så kontrollerar du om komprimering är aktiverad

Tre metoder från visuell till lågnivå.

Metod 1: Chrome DevTools. Öppna webbplatsen, tryck på F12, gå till fliken Nätverk. Uppdatera sidan, klicka på valfri rad och titta på fliken Headers. Leta reda på raden Content-Encoding: gzip i avsnittet Response Headers.

Där kan du också se den faktiska och komprimerade storleken: i exemplet ovan vägde sidan 51,6 kB, och efter komprimering 17,7 kB.

Metod 2: onlinetestare. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) eller Check GZIP Compression (checkgzipcompression.net): du klistrar in webbadressen och får ett utlåtande och komprimeringsprocent. Snabbare än DevTools om du behöver kontrollera någon annans webbplats eller flera sidor i rad.

Metod 3: curl från kommandoraden. Om du är på Linux/macOS eller i WSL på Windows:

1
curl -I -H "Accept-Encoding: gzip" https://yoursite.com | grep Content-Encoding

Svar Content-Encoding: gzip betyder att komprimeringen fungerar. Tomt svar betyder nej.

Kort videoförklaring

För att avsluta ämnet med en visuell sida, här är en kort video som visar hela processen för att aktivera GZIP via .htaccess och kontrollera resultatet i Chrome DevTools:

⁉️🤔 Vanliga frågor

Saktar GZIP-komprimering ner servern?

Tvärtom. Ja, processorn använder resurser på komprimering, men detta är en mikroskopisk belastning jämfört med vinsten från minskad överförd data. Vid komprimeringsnivå 6 (standardkompromissen) hanterar processorn det på millisekunder. Det enda scenariot där komprimering kan märkas är en mycket svag VPS med 512 MB minne och tusentals samtidiga besökare. Men i den situationen har du allvarligare problem än GZIP. I praktiken saktar inte komprimering ner servern: en typisk WordPress-sida komprimeras på 2-5 millisekunder, medan besparingarna i dataöverföring över nätverket uppgår till tiotals och hundratals millisekunder för varje besökare. Komprimering är alltid mer fördelaktigt än dess frånvaro.

GZIP eller Brotli: vad ska man välja 2026?

Börja med GZIP; det fungerar på alla webbhotell och stöds av alla webbläsare utan undantag. Brotli komprimerar märkbart bättre men kräver HTTPS (inget problem 2026) och stöd på serversidan. Om webbhotellet eller CDN:et (Cloudflare, BunnyCDN) stöder Brotli, aktivera det som ett tillägg till GZIP. De flesta moderna webbplatser använder båda: servern levererar Brotli till webbläsare som förstår det och GZIP till alla andra.

Är GZIP-komprimering kompatibelt med CDN?

Fullt ut. CDN:er som Cloudflare eller BunnyCDN komprimerar innehåll på sina edge-servrar själva, ofta i Brotli, även om ditt webbhotell inte stöder det. Om webbplatsen redan ligger bakom Cloudflare, kontrollera att alternativet "Brotli" är aktiverat under "Hastighet" → "Optimering". I detta scenario är det fortfarande användbart att konfigurera GZIP på servernivå som en reserv för direkta förfrågningar till ursprungsservern.

Jag har ett cachningstillägg. Behöver jag aktivera GZIP separat?

Det beror på tillägget. WP Rocket aktiverar GZIP automatiskt, W3 Total Cache med en separat kryssruta, WP Super Cache med en separat kryssruta. Kontrollera inställningarna för ditt tillägg; nästan alla cachningstillägg har ett komprimeringsalternativ men alla aktiverar det inte som standard. Förlita dig inte på att "det borde fungera"; kontrollera via DevTools efter installation.

Kan jag komprimera sidor via functions.php?

Tekniskt sett kan du det, genom PHP-funktionen ob_start('ob_gzhandler'), men vi rekommenderar det inte. Denna metod komprimerar PHP-utdata och påverkar inte statiska filer (CSS, JS) som utgör huvuddelen av trafiken. Komprimering på serversidan (Apache/NGINX) fungerar för alla filtyper och belastar inte PHP-processorn. Lämna PHP-komprimering för de sällsynta fall då åtkomst till serverkonfigurationer är fysiskt omöjlig.

Slutsatser: vad och när du ska aktivera

GZIP är inte ett "ställ in och glöm"-alternativ utan grundläggande hygien för en WordPress-webbplats. Om du just nu inte vet om din server komprimerar sidor, öppna DevTools och kontrollera Content-Encoding-headern. Saknas den? Återgå till metod 1 och lägg till tre rader i .htaccess.

Kort beslutsmatris:

• Webbplats på Apache och du är inte rädd för FTP → metod 1 (.htaccess), 5 minuter
• Webbplats på NGINX och du har tillgång till konfigurationsfilerna → metod 2 (nginx.conf), 10 minuter med syntaxkontroll
• Du rör inte serverfiler av princip → W3 Total Cache eller WP Super Cache, 2 minuter
• Du betalar redan för WP Rocket → gör ingenting, komprimeringen fungerar direkt
• Du vill inte konfigurera något alls → skriv till webbhotellets support

Kontrollera resultatet med någon av de tre metoderna ovan och stäng den här frågan för gott. Det här är den där sällsynta optimeringen som verkligen görs en gång och fortsätter spara trafik och snabba upp webbplatsen år efter år, utan uppdateringar, prenumerationer och upprepad konfiguration.