- Egy GET-kérés a megfelelő Accept-Encoding fejléccel megmutatja, hogy a szerver valóban tömörít-e, a HEAD-kérés félrevezethet.
- HTML, CSS és JavaScript esetén a 3-5-szörös méretcsökkenés a normális, a 20 százalék alatti nyereség hibára utal.
- A már tömörített formátumokat (JPEG, WebP, MP4, PDF, WOFF2) hagyd ki, ott a tömörítés csak processzort visz.
- Ha CDN van előtte, a Vary: Accept-Encoding fejléc nélkül könnyen rossz változat kerül a gyorsítótárba.
- A magyar tárhelyeken jellemzően él a gzip a HTML-re és a CSS-re, de a JSON-válaszok és a betűtípusok kimaradnak.
Egy átlagos magyar WordPress-oldal HTML-je 60-120 kilobyte, a stíluslapok és a JavaScript együtt könnyen 400-800 kilobyte. Ha ez tömörítés nélkül hagyja el a szervert, akkor nem a képekkel van a legnagyobb baj, hanem azzal, hogy a szöveges fájlok négy-ötszörös méretben utaznak a látogató böngészőjéig. A tömörítés az a ritka technikai beavatkozás, ami néhány sor konfiguráció, nem jár tartalmi engedménnyel, és azonnal mérhető byte-ban.
Hivatalosan igazolt. Két eljárásról beszélünk. A gzip a HTTP korai évei óta velünk van, gyakorlatilag minden böngésző és minden letöltő eszköz érti. A Brotli ennél újabb, a Google fejlesztette, az IETF RFC 7932 írja le, és ugyanazon a szövegen jellemzően 15-20 százalékkal kisebb végeredményt ad, mint a gzip. A böngésző az Accept-Encoding kérés-fejlécben mondja meg, mit tud fogadni, a szerver pedig a Content-Encoding válasz-fejlécben jelzi, mit küldött.
A dolog azért érdemel külön kört, mert az AI-válaszmotorok és a keresőrobotok is ugyanezen a csövön jönnek be. Az AI-crawlerek nagy számban, sorozatban töltenek le oldalakat, és nem minden robot vár türelmesen. A tömörítés nem tesz be téged egy AI-válaszba, de a lassú, nehéz kiszolgálás jó eséllyel kifelé mozdít belőle.
Miért nem elég annyi, hogy „a tárhelyen megy a gzip”?
Mert a tömörítés nem kétállású kapcsoló, hanem egy MIME-típusokból álló lista. A szerver csak azokat a válaszokat tömöríti, amelyek típusa szerepel a listán. Ez a lista majdnem mindig tartalmazza a text/html, text/css és application/javascript értékeket, mert évekkel ezelőtt valaki bemásolt egy mintakonfigurációt. És majdnem sosem tartalmazza azt, ami azóta lett fontos.
Saját tapasztalat. A magyar megosztott tárhelyeken végzett ellenőrzéseim során a HTML és a CSS szinte mindig tömörítve jön, a REST API és az admin-ajax JSON-válaszai viszont gyakran nyersen, ahogy az SVG-k egy része is. Ez nem szerverhiba, hanem egy elavult típuslista maradványa.
Hogyan ellenőrzöd curl-lel, hogy tömörítve jön-e a válasz?
A legrövidebb hiteles teszt egy GET-kérés, amiben te magad küldöd az Accept-Encoding fejlécet, és csak a válasz fejléceit kéred vissza. Így néz ki.
curl -s -o /dev/null -D - -H 'Accept-Encoding: br, gzip' https://pelda.hu/
A kimenetben a content-encoding: br vagy content-encoding: gzip sort keresed. Ha egyik sincs ott, a szerver tömörítés nélkül küldte a HTML-t. Fontos részlet, hogy ne HEAD-kéréssel próbálkozz (tehát ne curl -I-vel), mert több szerver és cache-réteg a HEAD-válasznál másképp viselkedik, mint az igazi letöltésnél. Volt már, hogy a HEAD tisztán mutatta a tömörítést, a valódi GET pedig nem, és fordítva is.
A tömörítési arányt két letöltés összevetésével kapod meg. Az egyik kéri a tömörítést, a másik nem.
curl -s -o /dev/null -w '%{size_download}\n' https://pelda.hu/style.csscurl -s -o /dev/null -w '%{size_download}\n' -H 'Accept-Encoding: br' https://pelda.hu/style.css
A két szám aránya maga a tömörítési arány. Ugyanezt végezd el legalább a következőkön, mert mindegyik más konfigurációs ágon fut.
- a nyitóoldal HTML-je és egy aloldal HTML-je
- a legnagyobb stíluslap és a legnagyobb JavaScript-fájl
- egy SVG-ikon vagy logó
- egy JSON-végpont, például a
/wp-json/gyökér - a XML sitemap és az RSS-hírcsatorna
- a saját betűtípus-fájlok, ha nem a Google szolgálja ki őket
Ha a szerver a Brotlit nem adja, de a gzipet igen, kérdezz rá külön-külön. A -H 'Accept-Encoding: br' és a -H 'Accept-Encoding: gzip' külön futtatása megmutatja, melyik modul hiányzik valójában.
Mit mutat meg a böngésző fejlesztői eszköze?
A böngésző ugyanezt mutatja, csak egyszerre az összes kérésre, ezért jó második körnek. Nyisd meg a Hálózat (Network) fülön az oldalt kikapcsolt gyorsítótárral, majd kattints rá egy kérésre, és a válasz-fejlécek között keresd a Content-Encoding sort. A Chrome és az Edge esetén a fejlécet oszlopként is felveheted, így egy pillantással átnézheted az egész listát.
A Méret (Size) oszlop két számot ad. A felső az átvitt méret, az alsó a kicsomagolt tartalom mérete. Ha a kettő megegyezik egy szöveges fájlnál, ott nincs tömörítés. A Lighthouse audit is jelzi ugyanezt „Enable text compression” néven, de az csak a nagyobb fájlokat panaszolja fel, a JSON-válaszokat és a kis SVG-ket jellemzően elnézi. Ezért nem elég a Lighthouse zöld pipája.
Mekkora tömörítési arány számít elfogadhatónak?
Saját tapasztalat, mérésekből. A szöveges tartalmaknál a 3-5-szörös csökkenés a szokásos, tehát a 100 kilobyte-os HTML 20-30 kilobyte körül érkezik meg. A minifikált CSS és JavaScript 4-6-szoros aránnyal tömörül, a formázott JSON néha ennél is jobban, mert sok ismétlődő kulcsnevet tartalmaz.
Gyakorlati küszöbként ezt használom. Ha a nyereség 60 százalék fölötti, rendben vagy. Az 50-60 százalék közötti sáv jellemzően alacsony tömörítési szintre vagy gzipre utal Brotli helyett. A 20 százalék alatti nyereség szöveges fájlon szinte mindig hibát jelent, például azt, hogy a fájlt egy plugin már tömörítette, vagy hogy a méretben egy nagy beágyazott base64-blokk dominál, ami nem tömörödik tovább.
A Brotli tömörítési szintje 0 és 11 között állítható. Az előre elkészített, statikus fájlokhoz a 11-es szint való, mert egyszer fut le. A menet közben generált HTML-hez a 4-5-ös szint a praktikus, a magasabb szint ott már több processzoridőt eszik, mint amennyi byte-ot megtakarít.
Hogyan kapcsolod be Apache alatt?
Apache alatt a gzipet a mod_deflate, a Brotlit a mod_brotli adja, utóbbi a 2.4.26-os verzió óta része a csomagnak. Megosztott tárhelyen a .htaccess fájlba írhatod, saját szerveren a virtuális host konfigurációjába érdemes.
- Ellenőrizd, hogy a modul betöltődött-e, saját szerveren az
apachectl -M | grep -E 'deflate|brotli'paranccsal. - Vedd fel a tömörítendő típusokat a
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/javascript application/json application/xml image/svg+xml application/rss+xmlsorral. - Brotli esetén ugyanez a lista kell a
AddOutputFilterByType BROTLI_COMPRESSdirektíva után, és aBrotliCompressionQuality 5beállítás egy jó kiindulás. - Tedd ki a
Header append Vary Accept-Encodingsort, hogy a köztes gyorsítótárak ne keverjék össze a változatokat. - Futtasd újra a curl-tesztet, és nézd meg, hogy a JSON és az SVG is tömörítve jön-e.
Ha a tárhelyed nem engedi a modulok kezelését, a típuslista kiegészítése akkor is működik, mert a modul jellemzően már be van töltve. Ezt a lépést ezért mindig előbb próbáld meg, mint hogy a szolgáltatót keresd.
Mit írj be Nginx alá?
Nginx alatt a gzip a beépített modul dolga, és három beállítás számít igazán. A gzip on; kapcsolja be, a gzip_types adja meg a típuslistát, a gzip_min_length 256; pedig megvédi a nagyon kis válaszokat az értelmetlen tömörítéstől. A gzip_comp_level 5; a szokásos kompromisszum, a 9-es szint alig ad többet, processzorban viszont sokat kér.
Két csapda van. Az egyik, hogy a text/html típust az Nginx mindig tömöríti, ezért azt nem is szabad a gzip_types listába írni, viszont a application/json és a image/svg+xml nem kerül be magától. A másik, hogy proxy mögötti tartalomnál a gzip_proxied any; beállítás nélkül a tömörítés egyszerűen kimarad, és ez a hiba némán történik. A Brotli az Nginxben nem beépített, hozzá az ngx_brotli modult kell befordítani vagy dinamikus modulként betölteni, ezért itt a Brotli mindig tudatos döntés eredménye.
Hogyan áll a dolog LiteSpeed alatt?
A LiteSpeed és az OpenLiteSpeed érti az Apache .htaccess direktíváit, tehát a fenti sorok jó eséllyel változtatás nélkül működnek. A tömörítés maga viszont a szerver saját beállításai között kapcsolódik, a Tuning részen, ahol a tömörítendő típusok listája és a statikus fájlok gyorsítótárazott tömörítése külön kapcsolót kapott.
Saját tapasztalat. LiteSpeed alatt a leggyakoribb hiba nem a szerveren van, hanem a LiteSpeed Cache pluginban. A plugin a gyorsítótárba előre eltett HTML-t saját logikával szolgálja ki, és ha a tömörítés a plugin oldalán ki van kapcsolva, akkor a szerveren beállított tömörítés a gyorsítótárból érkező találatokra nem érvényesül. Ezért LiteSpeed alatt mindig kétszer mérj, egyszer hideg és egyszer meleg gyorsítótárral.
Mely fájltípusokat ne tömörítsd?
Azokat, amelyek belső szerkezete már tömörített. Ott a második kör nem csökkenti a méretet, néhány százalékkal akár növeli is, a processzoridőt pedig felhasználja. A kihagyandó kör a következő.
- raszteres képek, tehát a JPEG, PNG, GIF, WebP és AVIF
- videó és hang, például MP4, WebM, MP3, AAC
- tömörített archívumok, ZIP, GZ, RAR, 7z
- PDF, mert a belső adatfolyamai már zlib-bel tömörítettek
- a WOFF2 betűtípus, ami maga is Brotlival tömörített formátum
Az SVG viszont sima XML, tehát tömörítendő, és nagyon jól tömörödik. A WOFF (az első verzió) táblái zlib-bel vannak becsomagolva, ott a plusz gzip lényegében nem hoz semmit. A régi TTF és OTF fájlok ellenben nyersek, azokon a tömörítés komoly nyereség, csak ma már ritkán kellene ilyet kiszolgálni a weben.
Mi történik, ha a CDN és a szerver is tömörít?
Hivatalosan igazolt. A HTTP egy válaszon több Content-Encoding értéket is megenged, a gyakorlatban viszont a böngészők és a CDN-ek ezt nem szeretik. A normális működés az, hogy a CDN az eredeti szerver felé tömörítve kéri a tartalmat, majd a tömörített választ vagy változatlanul továbbadja, vagy kicsomagolja és a látogató által támogatott eljárással újratömöríti. A Cloudflare és a nagyobb szolgáltatók ezt maguktól megteszik.
A baj két helyen keletkezik. Az egyik a gyorsítótárazás. Ha a Vary: Accept-Encoding fejléc lemarad, a CDN egyetlen változatot tesz el, és előfordul, hogy egy Brotlival tömörített választ kap az a kliens, ami csak gzipet ért. A látogató ilyenkor törött oldalt vagy letöltési ajánlatot lát, és a hiba csak bizonyos böngészőkben jelentkezik, ezért nehéz megfogni.
A másik a kétszeres munka. Ha az eredeti szerver már 11-es szintű Brotlit állít elő minden dinamikus válaszra, a CDN pedig kicsomagolja és újratömöríti, akkor kétszer fizeted ki a processzoridőt ugyanazért a byte-számért. Szakmai feltételezés. Ha CDN van előtte, jellemzően jobban jársz azzal, ha az eredeti szerveren a dinamikus tartalomra közepes szintet állítasz, és a végső, erős tömörítést a CDN-re hagyod. Ezt érdemes mérni, mert szolgáltatótól függ.
Miért marad ki a betűtípus és a JSON a magyar tárhelyeken?
Saját tapasztalat. Amit a magyar megosztott tárhelyeken rendszeresen látok, az egy félkész állapot. A gzip él, a HTML és a CSS tömörítve jön, tehát a gyors ellenőrzés zöld. A típuslista viszont egy évekkel ezelőtti mintából származik, amikor a JSON még nem volt a webfejlesztés gerince, és a betűtípusokat mindenki a Google-től szedte.
Ennek két látható következménye van. Az egyik, hogy a REST API és a keresés-javaslatok, a kosárfrissítés, a szűrők, tehát minden JSON-válasz nyersen megy ki. Ezek egyenként kicsik, de egy termékszűrő vagy egy webshop-kosár alatt sokan vannak, és éppen a felhasználó interakciója közben terhelik a hálózatot. A másik, hogy a saját, régi formátumú betűtípusok tömörítés nélkül utaznak, és mivel a betűtípus blokkolja a szöveg megjelenését, ez a késés jól látszik a mért értékekben.
Szakmai feltételezés. Az ok szerintem az, hogy a tömörítés beállítása sosem kerül vissza felülvizsgálatra. Egyszer bekerül a .htaccess-be, utána évekig senki nem nyitja ki, mert nem hibázik, csak kevesebbet ad, mint amennyit adhatna. Aki a szöveges tartalmat gépi olvasóknak is szánja, annak megérdemel egy évenkénti kört.
Milyen ellenőrzőlistával zárd le a munkát?
- Curl-lel GET-kéréssel ellenőrizd a
Content-Encodingfejlécet a nyitóoldalon és egy aloldalon. - Mérd meg a tömörítési arányt a legnagyobb CSS- és JS-fájlon, és fogadd el, ha 60 százalék felett van.
- Nézd meg külön a JSON-végpontot, az SVG-t, a sitemapot és az RSS-t.
- Ellenőrizd a saját betűtípusokat, és ha WOFF2-t szolgálsz ki, vedd ki a tömörítendő típusok közül.
- Győződj meg arról, hogy a válaszban ott van a
Vary: Accept-Encodingfejléc. - CDN mögött mérj hideg és meleg gyorsítótárral is, és kérdezz rá gzipre és Brotlira külön.
- Írd fel, mit állítottál, mert hat hónap múlva egy plugin-frissítés után ugyanezt fogod keresni.
A tömörítés nem rangsorolási trükk, és önmagában nem hoz látogatót. Annyit tesz, hogy a meglévő tartalmad kevesebb byte-ból érkezik meg, embernek és gépi olvasónak egyaránt. Ez a fajta munka nem látványos, viszont egyszer kell elvégezni, és utána évekig dolgozik.
Források és további olvasnivalók
- Google Search Central, Core Web Vitals és oldalélmény dokumentáció
- IETF RFC 7932, Brotli Compressed Data Format
- IETF RFC 9110, HTTP Semantics (Content-Encoding és Vary fejezetek)
- Apache HTTP Server dokumentáció, mod_deflate és mod_brotli
- Nginx dokumentáció, ngx_http_gzip_module
- LiteSpeed Technologies dokumentáció, Tuning és LiteSpeed Cache
- MDN Web Docs, HTTP Headers és Accept-Encoding
- web.dev, Text compression és Lighthouse audit leírások
Gyakori kérdések
Elég, ha csak a gzipet kapcsolom be, vagy kell a Brotli is?
A gzip a minimum, azt minden kliens érti. A Brotli ugyanazon a szövegen jellemzően 15-20 százalékkal kisebb végeredményt ad, tehát ha a szerver támogatja, érdemes bekapcsolni a gzip mellett. A kettő nem zárja ki egymást, a kliens választ közülük.
Miért mutat a curl -I mást, mint a valódi oldalletöltés?
A curl -I HEAD-kérést küld, amire több szerver és gyorsítótár másképp válaszol, mint egy igazi letöltésre. Használj helyette GET-kérést a curl -s -o /dev/null -D - formában, így azt a választ látod, amit a böngésző is kap.
Nem lassítja-e a szervert, ha mindent tömörítek?
A menet közbeni tömörítés processzoridőt kér, ezért nem érdemes mindenre kiterjeszteni. A már tömörített képeket, videókat, PDF-eket és WOFF2 betűtípusokat hagyd ki, a dinamikus tartalomnál pedig közepes tömörítési szintet állíts, mert a legmagasabb szint alig ad többet.
Hogyan derül ki, hogy a CDN vagy a szerver tömörít?
Kérdezd le közvetlenül az eredeti szervert az IP-jén vagy egy CDN nélküli aldomainen, és utána a nyilvános címet. Ha a két válasz Content-Encoding fejléce eltér, akkor a CDN nyúl bele, és ott kell a beállításokat átnézni.
A tömörítés javítja a helyezésemet a keresőben?
Önmagában nem. A kisebb átvitt méret segítheti a betöltési mérőszámokat, azok pedig részét képezik az oldalélmény-jelzéseknek, de a tömörítés bekapcsolása nem garantál jobb helyezést, és nem pótolja a tartalmi munkát.
Mit tegyek, ha a tárhelyen nem érem el a szerver beállításait?
Először próbáld ki a .htaccess fájlban a tömörítendő MIME-típusok listájának kiegészítését, mert a modul megosztott tárhelyen jellemzően már be van töltve, csak a lista hiányos. Ha ez nem hoz változást, a szolgáltatót kell megkérned a modul engedélyezésére.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.