Nginx Gzip tömörítés beállítása – Hogyan csökkentsük 70%-kal a weboldal méretét?

Az Nginx Gzip tömörítés egy olyan szerveroldali beállítás, amely az HTML, CSS, JavaScript, XML és JSON típusú szöveges fájlokat tömörítve továbbítja a böngésző felé, így a legtöbb esetben 50-70%-kal csökkenti az oldal méretét. A cél, hogy ugyanazt a tartalmat kisebb adatcsomagokban juttassuk el a felhasználóhoz, ezáltal lerövidítve a betöltési időt és gyorsabb, gördülékenyebb webélményt kínálva. Néhány perc alatt, az nginx konfigurációjában a gzip on; sor engedélyezésével, a megfelelő MIME típusok, minimális fájlméret és tömörítési szint beállításával már mérhető sebességnövekedést érhetünk el.

Manapság a weboldalak sebessége nem csupán egy technikai részlet; az SEO, konverziós arány, hirdetési hatékonyság és a felhasználói elégedettség egyik fő minőségi mércéje. A 2026-os SEO irányelvek szerint a felhasználói élmény, Core Web Vitals mutatók, mobilos teljesítmény és a keresőrobotok hatékony feltérképezése együttesen számítanak. Ezért az Nginx Gzip tömörítés bekapcsolása az egyik legfontosabb optimalizáció, különösen megosztott tárhelyen, VPS-en, felhő alapú szervereken vagy nagyforgalmú vállalati oldalak esetén. A Hostragons infrastruktúráján futó weboldalak esetében a teljesítményközpontú tárhelyválasztás is támogatja ezt a fejlődést: gyors web hosting csomagok.

Mi az az Nginx Gzip tömörítés?

Az Nginx Gzip tömörítés egy szerveroldali funkció, amely a HTTP válaszokat küldi el a kliensnek Gzip algoritmussal tömörítve. A böngésző a kérésében jelzi az Accept-Encoding: gzip fejléccel, hogy támogatja a tömörített adatot; az Nginx pedig ennek megfelelően gzip formátumban küldi a választ. A böngésző ezt a fájlt a felhasználó észlelése nélkül kicsomagolja, így a megjelenített tartalom változatlan marad, csak az átvitt adat mérete csökken.

Például egy 180 KB-os CSS fájl Gzip tömörítéssel akár 35-50 KB közé is zsugorodhat. Egy 500 KB-os JavaScript fájl pedig a kód szerkezetétől függően 120-180 KB-ra csökkenhet. Az HTML dokumentumok esetén, ahol ismétlődő tagek, szóközök és szöveges elemek vannak túlsúlyban, akár 70%-os méretcsökkenés is gyakori. Ez azonban nem igaz a képekre, mint a JPEG, PNG, WebP vagy AVIF, amelyek már eleve saját tömörítési eljárással rendelkeznek.

Valóban reális 70%-os méretcsökkenés?

Igen, ha a megfelelő fájltípusokat vesszük figyelembe. Fontos azonban megérteni, hogy a Gzip nem csökkenti a teljes weboldal méretét, hanem csak a tömöríthető szöveges erőforrások átvitelének méretét. Tegyük fel, hogy egy oldal összesen 3 MB méretű. Ennek 1 MB-ja HTML, CSS, JS és JSON fájlokból áll, a maradék 2 MB pedig képekből és videókból. Gzip kizárólag az 1 MB-os szöveges rész méretét csökkenti. Ha ezt a részt 70%-kal tömörítjük, az oldal összes mérete 3 MB-ról körülbelül 2,3 MB-ra csökken. Ha az oldal főként szöveges és script fájlokból áll, a megtakarítás még látványosabb lehet.

Vegyünk egy gyakorlati példát: egy WordPress oldal kezdőoldalán az HTML kimenet 220 KB, a téma CSS fájljai 310 KB, a JavaScript fájlok 760 KB, míg a JSON kérések 120 KB méretűek. Az összes tömöríthető tartalom így 1.410 KB. Gzip bekapcsolása után ez az érték 420-600 KB közé csökkenhet. Ez azt jelenti, hogy az átvitel során 800-990 KB adatot takarítunk meg. Mobil hálózatokon ez a különbség jelentősen javítja az LCP-t (Largest Contentful Paint) és a TTFB-t (Time To First Byte), ami gyorsabb tartalommegjelenítést eredményez.

A Gzip tömörítés SEO-ra és felhasználói élményre gyakorolt hatása

A Google nem emeli ki külön, hogy a gzip be van-e kapcsolva, mint rangsorolási tényezőt, de a gzip hatására javuló teljesítménymutatók jelentősen befolyásolják az SEO-t. A kisebb méretű fájlok gyorsabban töltődnek le, a böngésző hamarabb megkezdi a renderelést, így a felhasználó rövidebb ideig vár. Ez különösen fontos mobil felhasználók, lassú internetkapcsolat vagy nemzetközi látogatók esetén.

• Gyorsabb első betöltés: Ha az HTML fájl kisebb, a böngésző hamarabb felépíti az oldal vázát.

• Kisebb sávszélesség-felhasználás: Ugyanolyan forgalomnál kevesebb adat kerül átvitelre, ami nagy forgalmú oldalak esetén költségmegtakarítást jelenthet.

• Jobb keresőrobot feltérképezés: A keresők hatékonyabban töltik le az erőforrásokat.

• Core Web Vitals támogatás: A Gzip nem oldja meg önmagában az LCP problémákat, de a CSS és JS fájlok méretének csökkentésével javítja az összteljesítményt.

• Alacsonyabb visszapattanási arány: E-kereskedelmi és vállalati oldalak esetén már néhány száz milliszekundumos gyorsulás is befolyásolhatja a konverziókat.

Az oldal sebességét optimalizálva nem elég csak a szerver beállításaira koncentrálni; figyelembe kell venni a tárhely minőségét, SSL konfigurációt, DNS válaszidőt és a téma hatékonyságát is. Egy biztonságos és gyors környezet kialakításához érdemes lehet átnézni az SSL tanúsítvány megoldások és a domain kezelési lehetőségeket is: Domain ellenőrzés és regisztráció.

Ajánlott beállítások az Nginx Gzip tömörítéshez

Az Nginx-ben a gzip engedélyezése általában a fő konfigurációs fájlban vagy az adott webhelyhez tartozó server blokkban történik meg. A fájl helye függ a Linux disztribúciótól: Ubuntu és Debian rendszereken gyakran az /etc/nginx/nginx.conf vagy az /etc/nginx/sites-available/ alatt találhatók a konfigurációk, míg CentOS, AlmaLinux vagy Rocky Linux esetén inkább az /etc/nginx/conf.d/ mappa használatos.

Az ajánlott alapbeállítás lényege, hogy a gzip aktív legyen, csak elegendően nagy szöveges fájlokat tömörítsen, csökkentse az elavult böngészők problémáit, és a megfelelő MIME típusokat kezelje. Egy tipikus éles környezetben az alábbi beállításokat használjuk: gzip on; gzip_comp_level 5; gzip_min_length 1024; gzip_vary on; gzip_proxied any; gzip_types text/plain text/css application/javascript application/json application/xml text/xml image/svg+xml.

A gzip_comp_level értéke 1 és 9 között változhat. Minél magasabb a szint, annál jobb a tömörítés, de nő a CPU terhelés is. A legtöbb weboldal esetében 4, 5 vagy 6 egy optimális egyensúlyt jelent. A legmagasabb, 9-es szint nem mindig előnyös, mert egy kis méretű fájl tömörítése esetén túlzottan leterheli a processzort. Különösen nagy forgalmú VPS vagy dedikált szervereken fontos megtalálni az ideális egyensúlyt. Ha szerver kapacitás korlátos, érdemes lehet VPS szerver csomagok választani, amelyek hatékonyabb működést biztosítanak.

Lépésről lépésre: Nginx Gzip tömörítés bekapcsolása

1. Ellenőrizze a jelenlegi állapotot

Minden optimalizálás előtt mérje fel az aktuális teljesítményt. A Chrome DevTools Hálózat (Network) fülén frissítse az oldalt, és nézze meg a fájlok Size (méret) és Transferred (átvitt) értékeit. Ha ezek nagyon közel vannak egymáshoz, valószínűleg a gzip nincs bekapcsolva. Emellett a válasz fejlécek között keresse a Content-Encoding: gzip sort. Ellenőrzéshez használhat WebPageTest-et, GTmetrix-et, PageSpeed Insights-ot vagy curl parancsot is.

Készítsen mérési tervet: tesztelje a kezdőlapot, kategóriaoldalt, termék vagy szolgáltatás oldalt és blogbejegyzést is. Csak a kezdőoldal vizsgálata félrevezető lehet, mert egyes aloldalakon több JavaScript vagy dinamikus JSON kérés lehet. Az eredményeket táblázatban rögzítve jól látható a Gzip bekapcsolása utáni javulás.

2. Készítsen biztonsági mentést az Nginx konfigurációról

Mielőtt módosítaná a szerver beállításait, mindig készítsen biztonsági másolatot. Egy apró hiba megakadályozhatja az Nginx újraindulását. Másolja le az érintett fájlt és nevezze el dátummal. Ha menedzselt tárhelyet használ, előfordulhat, hogy a vezérlőpulton Gzip vagy Tömörítés néven talál beállítást. Ha nem biztos a dolgában, kérjen segítséget a szolgáltatójától.

3. Adja hozzá a Gzip direktívákat

A gzip beállításokat az http blokkba érdemes elhelyezni, így érvényesek lesznek az összes oldalra. Ha csak egy adott oldalra szeretné aktiválni, akkor a server blokkban is megteheti. Az ajánlott konfiguráció így néz ki: gzip on; gzip_disable msie6; gzip_vary on; gzip_proxied any; gzip_comp_level 5; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_min_length 1024; gzip_types text/plain text/css text/xml application/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml.

Ezek a beállítások lefedik a leggyakrabban használt szöveges fájlokat a modern weboldalakon. Kerülje a felesleges MIME típusok hozzáadását, mert a már tömörített fájlok újratömörítése nem hoz előnyt. Ilyenek például a JPG, PNG, GIF, WebP, MP4, ZIP vagy PDF fájlok. Az SVG fájlok viszont, mivel szövegalapúak, különösen alkalmasak a gzip tömörítésre.

4. Tesztelje az Nginx konfigurációt

A változtatás után ne indítsa újra rögtön az Nginx-et, előbb ellenőrizze a konfiguráció helyességét az nginx -t paranccsal, amely hibák esetén jelzi a problémákat. Ha minden rendben, indítsa újra vagy töltsön újra konfigurációt a systemctl reload nginx parancs segítségével, ami megszakítás nélkül frissíti a beállításokat. Az újraindítás (restart) komolyabb beavatkozás, amit forgalmas időszakban óvatosan használjon.

5. Ellenőrizze az eredményeket

A konfiguráció életbe lépése után törölje a böngésző gyorsítótárát vagy használjon inkognitó módot a teszteléshez. A Network fülön ellenőrizze, hogy megjelenik-e a Content-Encoding: gzip fejléc, és nézze meg, hogy az átvitt adat mennyisége csökkent-e. Például egy korábban 240 KB méretű HTML fájl most 45-70 KB közé eshet vissza. A CSS és JS fájloknál is hasonló méretcsökkenést kell tapasztalnia.

Gzip beállítások összehasonlító táblázata

Mely fájlokat érdemes Gzip-pel tömöríteni?

A Gzip legjobban az ismétlődő szöveges mintázatokat tartalmazó fájlokon működik. Ide tartoznak a HTML oldalak, CSS stíluslapok, JavaScript fájlok, JSON API válaszok, XML oldaltérképek, RSS feedek és SVG képek. A modern webalkalmazásokban, mint a React, Vue vagy Angular, a fő JavaScript csomagok mérete jelentős lehet, így ezek Gzip-pel történő tömörítése nagy megtakarítást eredményez, gyakran a fájl méretének felére csökkentve azt.

Vannak viszont fájltípusok, amelyeket nem érdemes Gzip-pel tömöríteni. Ilyenek például a JPEG, PNG, WebP, AVIF képek, MP4 videók, MP3 hangfájlok, ZIP, RAR archívumok és PDF dokumentumok, melyek már alapból tömörítve vannak. Ezek tömörítése nem hoz értékelhető előnyt, csak a CPU terhelést növeli. A képek esetében inkább a formátumváltásra (WebP, AVIF), helyes méretezésre, lusta betöltésre (lazy loading) és CDN használatára koncentráljunk. Erről részletesebben olvashat a weboldal gyorsítási útmutató.

Gzip használata WordPress, Laravel és statikus oldalak esetén

WordPress oldalak

WordPress esetén a gzip kétféleképpen aktiválható: szerveroldalon vagy bővítményen keresztül. Az egészségesebb és hatékonyabb megoldás a szerveroldali beállítás, mert így az adat már a PHP feldolgozás előtt tömörítve érkezik. Habár néhány cache plugin javasolja a gzip-et, az igazi kontroll az Nginx konfigurációban van. Emellett a WordPress oldalaknál a CSS és JS minifikálás, kritikus CSS, képtömörítés és oldalcache alkalmazása együtt hozja a legjobb eredményt.

Laravel és API alapú alkalmazások

Laravel esetében a JSON válaszok sokszor nagy méretűek lehetnek, főleg API végpontoknál. Ilyenkor a gzip jelentős sávszélesség-megtakarítást biztosít. A nagyon kis méretű JSON válaszokat viszont a gzip_min_length miatt nem tömöríti a rendszer, ami elfogadott viselkedés. Az API teljesítmény javításához ajánlott az oldalakozás (pagination), a nem szükséges mezők elhagyása és a HTTP cache fejlécek megfelelő használata is.

Statikus HTML oldalak

Statikus weboldalak esetén a gzip hatása általában azonnal érezhető. A HTML, CSS és JS fájlokat az Nginx közvetlenül szolgálja ki, így nincs extra alkalmazásréteg. Néhány szerver előre tömörített .gz fájlokat is létrehoz, de a legtöbb weboldal számára a dinamikus gzip beállítás elegendő.

Gzip és Brotli – Mi a különbség?

A Brotli egy Google által kifejlesztett, újabb tömörítési algoritmus, amely különösen szöveges fájlok esetén jobb arányokat érhet el, mint a Gzip. Azonban az Nginx alapértelmezett telepítésében a Brotli támogatás nem mindig elérhető, ezért kiegészítő modul vagy speciális csomag szükséges hozzá. A Gzip viszont széles körben elterjedt, stabil és szinte minden böngésző által támogatott, így megbízható alapmegoldás.

A 2026-os teljesítmény-optimalizálási trendek szerint a legjobb gyakorlat, ha lehetőség szerint egyszerre támogatjuk mind a Brotli, mind a Gzip tömörítést. Ha a böngésző támogatja a Brotli-t, azt használja, egyébként a Gzip-et. Azonban az első lépésként a helyes Nginx Gzip beállítás is önmagában jelentős gyorsulást hoz a legtöbb weboldal számára.

Mit érdemes figyelembe venni CDN, Cache és Proxy használatakor?

Amennyiben CDN-t vagy visszafelé proxy-t alkalmaz, a tömörítés láncolatát gondosan kell megtervezni. Egyes CDN szolgáltatók a saját oldalukon is alkalmazhatnak Gzip vagy Brotli tömörítést. Ilyen esetben, ha az eredeti szerveren is be van kapcsolva a gzip, nem keletkezik dupla tömörítés, mivel a helyesen konfigurált rendszerek ellenőrzik a Content-Encoding fejlécet. Ettől függetlenül érdemes tesztelni a működést. A gzip_vary on beállítás segít abban, hogy a cache rendszerek helyesen tárolják a tömörített és nem tömörített verziókat a Vary: Accept-Encoding fejléc használatával.

A cache rétegekben az egyik leggyakoribb hiba, hogy tömörített tartalmat küldenek olyan kliensnek, amely nem támogatja a tömörítést. Bár ez manapság ritka a modern böngészők között, előfordulhat régi botok, speciális ügyfelek vagy egyedi integrációk esetén. Ezért a Vary fejléc és a helyes CDN beállítások kulcsfontosságúak. Vállalati oldalak esetén a DNS, SSL, CDN és tárhely architektúráját együtt, komplexen kell kezelni. A Hostragons-on skálázható megoldásokat talál: vállalati tárhely megoldások.

A Gzip biztonsági és stabilitási szempontjai

A Gzip általában biztonságos beállítás, de érzékeny adatok esetén elméletben előfordulhatnak tömörítési alapú oldalcsatorna támadások, mint a BREACH. Ezek lényege, hogy a tömörített HTTPS válaszokból próbálnak meg titkos tokeneket visszafejteni. A modern alkalmazásokban a CSRF token kezelés, SameSite sütik, megfelelő biztonsági fejlécek és választervezés jelentősen csökkentik ezt a kockázatot. Nyilvános, statikus erőforrások esetén a Gzip használata biztonságosnak tekinthető.

A stabilitás szempontjából a legnagyobb veszélyt a hibás konfiguráció jelenti. Ha hiányoznak MIME típusok, egyes elvárt fájlok nem tömörülnek, vagy rossz blokkpozíció miatt az Nginx el sem indul. Ezért minden változtatás után futtassa az nginx -t parancsot, figyelje a naplókat, és amennyiben lehet, a módosításokat forgalommentes időszakban végezze.

Milyen metrikákat érdemes figyelni a teljesítmény méréséhez?

A Gzip bekapcsolása után nem elég a PageSpeed pontszámra hagyatkozni. Érdemes részletes, technikai és megbízható mutatókat követni. Ezek közé tartozik az átvitt méret (Transferred size), a fájl mérete a böngészőben (Resource size), a Content-Encoding fejléc megléte, az LCP és az összes blokkolási idő (Total Blocking Time). A Gzip elsősorban az adatátvitel méretét csökkenti; a szerver feldolgozási idejét nem rövidíti meg. Tehát ha lassú adatbázis-lekérdezések vagy nehéz PHP folyamatok vannak, ezek továbbra is szűk keresztmetszetet jelentenek.

• Transferred size: A böngészőnek ténylegesen továbbított, tömörített adat mérete.

• Resource size: A fájl kibontás utáni valós mérete a böngészőben.

• Content-Encoding: Ez a fejléc jelzi, hogy a tömörítés működik.

• LCP: A legnagyobb látható elem betöltési ideje; a Gzip javíthat rajta, de képfeldolgozás is szükséges.

• Total Blocking Time: Nagy JS fájloknál nem csak az átvitel, hanem a futtatási idő is számít.

Gyakori hibák és megoldások

A Gzip be van kapcsolva, de a fájlok nem tömörülnek

Elsőként ellenőrizze a gzip_types beállítást. Az alapértelmezett Nginx csak a text/html fájlokat tömöríti. Ha nem adta hozzá a CSS, JS vagy JSON MIME típusokat, nem fogja elérni a kívánt megtakarítást. Szintén fontos a gzip_min_length értéke: ha a fájl ennél kisebb, nem tömörít.

Nőtt a CPU terhelés

Csökkentse a gzip_comp_level értékét. Például 5 helyett 3 vagy 4 is hozhat hasonló sebességnövekedést kisebb processzorhasználattal. Nagy forgalmú oldalak esetén érdemes megfontolni a CDN tömörítést vagy az előre tömörített statikus fájlokat.

CDN után eltűnt a Content-Encoding fejléc

Ellenőrizze a CDN panel tömörítési beállításait. Egyes szolgáltatóknál a gzip nincs alapból bekapcsolva, vagy csak bizonyos fájltípusokra vonatkozik. Tesztelje külön az eredeti szervert és a CDN-t is.

A PageSpeed pont nem javult jelentősen

Ez normális lehet. A Gzip csökkenti az adatátvitelt, de a renderelést akadályozó CSS, nem használt JS, nagy képek, harmadik féltől származó kódok vagy gyenge tárhely továbbra is korlátozza a teljesítményt. A Gzip fontos első lépés, de nem csodaszer.

Javasolt ellenőrző lista

• Mérje fel az aktuális átvitt méreteket a kezdőoldalon és kritikus sablonokon.

• Készítsen biztonsági mentést az Nginx konfigurációról a módosítás előtt.

• Használja az alapvető beállításokat: gzip on, gzip_vary on, gzip_min_length 1024.

• Adja hozzá a CSS, JS, JSON, XML, RSS és SVG MIME típusokat a gzip_types-hoz.

• Tartsa a gzip_comp_level értékét 4 és 6 között a CPU terhelés kiegyensúlyozásához.

• Ne tömörítse a képeket, videókat és archív fájlokat.

• Futtassa le az nginx -t tesztet, majd reload-olja a szervert.

• Ellenőrizze a Content-Encoding: gzip fejléc jelenlétét Chrome DevTools, curl vagy WebPageTest segítségével.

• CDN használatakor figyelje a Vary: Accept-Encoding fejlécet és a CDN tömörítési beállításokat.

• A Gzip után is gondoskodjon képtömörítésről, cache-ről, adatbázis-optimalizálásról és megfelelő tárhelyről.

Mikor nem elégséges a Gzip tömörítés?

Előfordulhat, hogy a Gzip megfelelően működik, de az oldal még mindig lassúnak tűnik. Ennek oka lehet nem az adatátvitel mérete, hanem a feldolgozási vagy renderelési idő. Például egy 1,5 MB-os JavaScript fájl Gzip után is 400 KB marad, amit a böngészőnek értelmeznie és futtatnia kell. Ezért fontos eltávolítani a nem használt JS kódot, alkalmazni a kód felosztást (code splitting), és halasztani a nem kritikus szkriptek futtatását.

Hasonlóan, egy 1 MB-os fő kép esetén a Gzip nem segít, mert az képtömörítési eljárással már optimalizált. Ilyenkor a WebP vagy AVIF formátumra váltás, megfelelő méretezés és reszponzív képhasználat javasolt. Lassú adatbázis lekérdezések, alacsony CPU korlátok vagy zsúfolt megosztott tárhelyek szintén korlátozzák a Gzip hatékonyságát. Ilyen esetben érdemes átgondolni a tárhely architektúrát: teljesítménycentrikus tárhely választás.

Összegzés: Kis beállítás, nagy sebességnövekedés

Az Nginx Gzip tömörítés az egyik legegyszerűbb, legolcsóbb és leghatékonyabb módja az oldal méretének és adatforgalmának csökkentésére. Megfelelő konfigurációval az HTML, CSS, JavaScript, JSON és XML fájlok mérete akár 50-70%-kal is csökkenhet, ami gyorsabb oldalbetöltést, jobb felhasználói élményt és előnyösebb SEO-t eredményez.

Az optimális eredmény érdekében azonban a Gzip-et ne önmagában alkalmazzuk, hanem egy komplex sebességoptimalizálási stratégiába ágyazzuk bele, amely tartalmaz képtömörítést, cache kezelést, minőségi tárhelyet, naprakész SSL-tanúsítványt és tiszta kódot. Ha szeretné megerősíteni weboldala teljesítmény-infrastruktúráját a Hostragons szolgáltatásain keresztül, érdemes összehasonlítani a tárhely, domain és SSL megoldásokat, hogy megtalálja az igényeinek leginkább megfelelőt: Hostragons hosting megoldások.

Gyakran ismételt kérdések

Valóban gyorsítja az oldalt az Nginx Gzip tömörítés?

Igen. A Gzip csökkenti a szöveges fájlok átvitelének méretét, így a böngésző gyorsabban töltheti le a forrásokat. Különösen a HTML, CSS, JavaScript és JSON fájlok esetén jelentős javulást hozhat. Azonban a képtömörítés, cache és szerver teljesítmény szintén befolyásolja a végeredményt.

Milyen tömörítési szintet válasszak?

A legtöbb éles környezetben a gzip_comp_level 4, 5 vagy 6 ajánlott. A magasabb szintek minimális extra tömörítést hoznak, de jelentősen növelik a CPU terhelést. Nagy forgalmú weboldalaknál fontos a kiegyensúlyozott beállítás a stabil működés érdekében.

Tömöríti a Gzip a képeket is?

Technikailag némely képfájl bekerülhet a tömörítésbe, de a JPEG, PNG, WebP, AVIF és MP4 már alapból tömörített formátum, így nem érdemes Gzip-pel újratömöríteni őket. A képek esetében a formátumváltás, megfelelő méretezés, lusta betöltés és CDN használata a hatékonyabb megoldás.

Használható egyszerre Gzip és Brotli?

Igen. Ha a rendszer megfelelően van beállítva, a böngésző, ha támogatja, a Brotli-t használja, egyébként a Gzip-et. A Brotli jobb tömörítést kínál, de az Nginx konfigurációhoz plusz modul szükséges. A Gzip pedig széles körben támogatott és egyszerűen beállítható.

Hogyan ellenőrizhetem, hogy a Gzip aktív?

A Chrome DevTools Hálózat fülén válassza ki az adott fájlt, és a válasz fejlécek között keresse a Content-Encoding: gzip sort. Emellett a curl parancs vagy WebPageTest szolgáltatások is hasznosak lehetnek. Ha az átvitt adat jelentősen kisebb, mint a fájl mérete, az a tömörítés működését jelzi.