Om GZIP-komprimering
Hvad er en GZIP-test?
En GZIP-test stiller et enkelt spørgsmål: Komprimerer din server en side, før den sender den? GZIP er den komprimeringsmetode, som internettet har brugt i årtier, og den fungerer ved at finde gentagelser i tekst og kode dem mere effektivt.
HTML, CSS og JavaScript indeholder ekstremt mange gentagelser, så besparelserne er store – typisk 70 til 90 procent. Browseren pakker filen ud ved modtagelsen, og den besøgende opdager aldrig, at det er sket.
Det konfigureres én gang på serveren, gælder for alt på én gang og koster næsten ingenting i processorkraft. Derfor er det værd at reagere med det samme på en mislykket GZIP-test: Få rettelser er så billige eller har så bred effekt.
GZIP og Brotli
Brotli er en nyere komprimeringsmetode, der generelt klarer sig bedre end GZIP på tekst, ofte med yderligere 15-20 procent, og som understøttes af alle moderne browsere.
Den har ikke så meget erstattet GZIP, som den er kommet til som et supplement. Servere forhandler med hver klient og bruger den bedste metode, som begge understøtter, så den normale konfiguration er Brotli med GZIP som fallback.
En GZIP-test, der består, fortæller dig, at komprimering finder sted. Om den bedste metode bliver brugt, er et separat spørgsmål og værd at stille, når det grundlæggende er på plads.
Er komprimering stadig relevant i 2026?
Det er en af de få optimeringer, der er næsten gratis og hjælper alle besøgende ved hver anmodning. Intet andet på en performance-tjekliste kombinerer samme rækkevidde og lave omkostning.
De fleste moderne hostingløsninger aktiverer det som standard, hvilket netop er grunden til, at det går ubemærket hen, når en migrering, en brugerdefineret serverkonfiguration eller et nyt CDN-lag slår det fra. Websites mister komprimering langt oftere, end de får den.
Effekten er usynlig ved indlæsning af en enkelt side, men betydelig på tværs af et helt website. Det er den slags problem, der kan eksistere i årevis, uden at nogen rapporterer det.
Hvordan komprimering hænger sammen med AI-søgning
Crawlere anmoder om komprimerede svar ligesom alle andre klienter. Hvis der leveres ukomprimeret HTML, bliver hver hentning større og langsommere, hvilket reducerer, hvor meget af et stort website der bliver hentet under en given crawl.
Denne omkostning er usynlig for den enkelte side, men betydelig på tværs af tusindvis af sider, hvilket gør det til netop den slags, der er værd at kontrollere i stedet for at antage, at det er i orden.
Det har ingen betydning for, hvordan indholdet forstås, kun for hvor meget af det der nås.
Bedste praksis for komprimering
- Aktivér det for HTML, CSS, JavaScript, SVG og JSON.
- Komprimér ikke billeder eller video; de er allerede komprimerede og vil blive en smule større.
- Foretræk Brotli, hvor det understøttes, med GZIP som fallback.
- Kontrollér igen efter ændringer af hosting, CDN eller server.
- Kontrollér ved hjælp af svarheadere i stedet for at stole på indstillingen i kontrolpanelet.
- Kombinér med minificering; de to metoder fjerner overlappende, men ikke identisk redundans.
Hvad dette værktøj kontrollerer
GZIP-testen anmoder om siden og rapporterer, om svaret blev leveret komprimeret. Testen godkendes, når det var tilfældet.
Den kontrollerer sidedokumentet, så en komprimeret side, der leverer ukomprimerede typografiark eller scripts, vil stadig bestå. Hvis dokumentet er komprimeret, men webstedet stadig føles tungt, er aktiverne det næste sted at lede.
Hvad kan du gøre som det næste
Komprimering er én af tre måder at gøre filer mindre på. Kontrollér, om dine aktiver også er
minificeret, se sidens samlede størrelse med værktøjet
websidens filstørrelse, og bekræft, at serveren bruger en moderne protokol, med kontrollen
HTTP/2.