Biztonság Szakszó

Tömörítés (gzip, brotli)

Szerző: · 7 perc olvasás · Frissítve:
Tömörítés (gzip, brotli) - Biztonság (szakszó) a tudástárban
Tömörítés (gzip, brotli) - Biztonság | eClick GEO-audit tudástár

A tömörítés az az eljárás, amellyel a szerver átvitel előtt összecsomagolja a szöveges válaszokat, a böngésző pedig kicsomagolja őket. A weben két algoritmus számít: a régebbi gzip és az újabb, hatékonyabb Brotli.

Hogyan működik

A böngésző minden kéréshez küld egy Accept-Encoding fejlécet. Ebben felsorolja, mit tud kicsomagolni: jellemzően gzip, deflate, br, zstd. A szerver ebből választ, és a válaszban Content-Encoding: br vagy Content-Encoding: gzip fejléccel jelzi a döntését. Ha ilyen fejléc nincs, a válasz tömörítetlenül utazik a hálózaton.

A nyereség szöveges fájloknál nagy. Egy tipikus HTML-, CSS- vagy JavaScript-állomány 70-85 százalékkal zsugorodik. A Brotli azonos tartalmon általában 15-20 százalékkal kisebb eredményt ad, mint a gzip. Képeknél és videóknál viszont nincs mit nyerni, mert azok formátuma eleve tömörített.

Mit jelent a keresőknek és az AI-nak

A keresőrobotok és az AI-crawlerek ugyanúgy küldik az Accept-Encoding fejlécet, mint a böngészők. Kisebb átvitel gyorsabb letöltést jelent, ez pedig több lekért oldalt ugyanannyi idő alatt. A tartalom nem változik tőle, tehát ez nem rangsorolási trükk. A TTFB (Time to First Byte) értékét sem javítja magától, sőt élő tömörítésnél pár ezredmásodperccel ronthatja is.

Mikor számít igazán

Akkor, ha nagy az HTML-méret, vagy sok script és stíluslap tölt be. Mobilneten és gyenge kapcsolaton minden megspórolt száz kilobájt látható. A riportokban azt látjuk, hogy ma már a magyar oldalak többségén be van kapcsolva valamilyen tömörítés. A hiány jellemzően régi, saját kezelésű VPS-eken bukkan fel.

Röviden: a tömörítés olcsó, egyszer beállítható nyereség, de nem javítja ki a felesleges kódot.

Miért fontos

A tömörítés az átvitt bájtok számát csökkenti, nem a munkát a böngészőben. Ettől függetlenül valódi, mérhető hatása van.

  • Gyorsabb megjelenés. A HTML és a CSS hamarabb megérkezik, így a tartalom korábban rajzolódik ki.
  • Olcsóbb forgalom. Nagy látogatottságnál a sávszélesség-költség érezhetően csökken.
  • Hatékonyabb feltérképezés. A robotok ugyanannyi idő alatt több oldalt szednek le, ami nagy katalógusoknál számít.
  • Mobil felhasználók. Lassú kapcsolaton a tömörítetlen 400 kB-os HTML másodperceket vesz el.

A hatása ugyanakkor mérsékelt. Ha az oldal a sebesség-mérésen rosszul szerepel, a tömörítés önmagában nem fogja megjavítani. Egy felpuffadt sablon tömörítve is felpuffadt sablon marad.

Kikre vonatkozik

Minden HTTP-t kiszolgáló oldalra vonatkozik: bemutatkozó honlapra, blogra, webshopra, API-ra egyaránt. Nincs olyan oldaltípus, amelynél a szöveges válaszok tömörítése ártana.

  • SaaS-platformon (Shopify, Unas, Shoprenter) a szolgáltató oldja meg, neked ellenőrizni kell, nem beállítani.
  • Saját szerveren vagy VPS-en a te dolgod. Itt találjuk a hiányzó tömörítés túlnyomó részét.
  • Statikus oldalaknál érdemes előre tömörített .br és .gz fájlokat kiszolgálni.
  • Staging és belső rendszerek esetén nem sürgős, de a beállítás ott is egy sor.

Ez tipikusan környezeti feladat, nem tartalmi: a hatókör a hoszting vagy a szerverkonfiguráció. Fejlesztő vagy üzemeltető tíz perc alatt elintézi.

Hogyan ellenőrzöd

  1. Nyisd meg az oldalt a böngészőben, és indítsd el a devtoolsot (F12).
  2. Válts a Network fülre, majd töltsd újra az oldalt.
  3. Kattints a listában a legelső, HTML-dokumentum típusú kérésre.
  4. A Response Headers között keresd a Content-Encoding sort.
  5. Nézd meg a Size oszlopot: a felső szám az átvitt méret, az alsó a kitömörített méret.
  6. Ismételd meg a fő CSS- és JS-fájlokra is, mert ezek gyakran kimaradnak.
  7. Parancssorból egyetlen curl hívással is ellenőrizheted (lásd a technikai példát).
  8. A PageSpeed Insights és a Lighthouse külön figyelmeztetést ad, ha talál tömörítetlen szöveges erőforrást.

Jó jel:

  • Content-Encoding: br vagy gzip szerepel a válaszban.
  • Az átvitt méret a kitömörített töredéke, jellemzően 20-30 százaléka.
  • A HTML mellett a CSS, a JS, az SVG és a JSON is tömörítve érkezik.

Rossz jel:

  • Nincs Content-Encoding fejléc a HTML-válaszban.
  • Az átvitt és a kitömörített méret megegyezik.
  • Csak a HTML tömörített, a statikus fájlok nem.

Mit néz ebből a riport

Az audit lekéri az oldalt, és megnézi, kap-e Content-Encoding fejlécet a válaszban. Ha nincs, a riport alacsony hatású megállapítást ír be, környezeti hatókörrel. Az ajánlás egyszerű: kapcsold be a gzip vagy Brotli tömörítést.

Hogyan javítod

WordPress

  1. Először a tárhely-vezérlőpultot nézd meg. A legtöbb magyar szolgáltatónál van egy kapcsoló a tömörítéshez.
  2. Apache alatt a .htaccess fájlban a mod_deflate vagy mod_brotli modul végzi a munkát.
  3. Ha van cache-plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache), abban is találsz tömörítés-opciót.
  4. Ne kapcsold be két helyen egyszerre, mert a dupla tömörítés hibás válaszokat ad.
  5. PHP-szintű megoldást (ob_gzhandler) csak végszükség esetén használj, mert lassabb.

Shopify

A platform a saját CDN-jén keresztül szolgál ki, és a tömörítést automatikusan intézi. Nincs mit beállítanod, de a devtoolsban ellenőrizd le, hogy tényleg megérkezik a Content-Encoding fejléc.

Unas

SaaS-környezet, a kiszolgálás a szolgáltató kezében van. Ellenőrizd a fejlécet, és ha hiányzik, nyiss hibajegyet. Saját domain vagy elé kapcsolt proxy esetén a proxy beállítását is nézd meg.

Shoprenter

Itt is a platform dönt a kiszolgálásról. Neked az ellenőrzés marad, plusz a saját sablonba rakott külső fájlok. Ha egy scriptet másik szerverről töltesz be, az annak a szervernek a beállításán múlik.

Egyedi fejlesztés

  1. Nginx alatt kapcsold be a gzip on beállítást, és bővítsd ki a gzip_types listát.
  2. Telepítsd a Brotli modult, és hagyd a gzipet tartalék eljárásnak a régi kliensekhez.
  3. Node.js esetén a compression middleware vagy a proxy előtt álló nginx a szokásos megoldás.
  4. Statikus fájlokat build időben tömöríts előre .br és .gz kiterjesztéssel, így futás közben nincs CPU-terhelés.
  5. Élő tömörítésnél maradj közepes szinten (gzip 5-6, Brotli 4-5), a maximum csak előre tömörített fájloknál éri meg.
  6. Ha CDN van az oldal előtt, az origin szerveren is hagyd bekapcsolva a tömörítést a cache-tévesztések miatt.

Gyakori hibák

  • Csak gzip van, Brotli nincs. Működik, de minden válaszon ott hagysz 15-20 százalék felesleges bájtot.
  • Hiányos gzip_types lista. A HTML tömörítve megy, a JS, az SVG és a JSON viszont nem, pedig ezek gyakran nagyobbak.
  • Képek és PDF tömörítése. Ezek már tömörítettek, így csak a CPU-t terheled, nyereség nélkül.
  • Maximális tömörítési szint élő kiszolgálásnál. A processzor sokat dolgozik, a TTFB (Time to First Byte) pedig romlik, a nyereség viszont minimális.
  • Dupla tömörítés. Ha a plugin és a webszerver is tömörít, a böngésző hibás vagy olvashatatlan választ kap.
  • A tömörítést sebesség-csodaszernek hinni. Egy 2 MB-os HTML tömörítve is 2 MB-nyi DOM-ot épít a böngészőben, ezért az oldalméretet külön kell rendbe tenni.
  • Bejelentkezett, titkot tartalmazó válaszok tömörítése. Ha a válaszba a felhasználó bemenete és egy token is bekerül, a tömörítés elvileg szivárogtathat (BREACH), ezért CSRF-tokeneket érdemes kérésenként cserélni.

Technikai példa

Ellenőrzés parancssorból. A curl kifejezetten kéri a Brotli és gzip támogatást, majd csak a válaszfejléceket írja ki:

curl -sI -H "Accept-Encoding: gzip, deflate, br" https://pelda.hu/

# Elvárt válasz (részlet):
# HTTP/2 200
# content-type: text/html; charset=UTF-8
# content-encoding: br
# vary: Accept-Encoding

Ha a content-encoding sor hiányzik, nincs tömörítés. A vary: Accept-Encoding fejléc azért kell, hogy a köztes cache-ek ne adják oda a tömörített választ egy olyan kliensnek, amelyik nem kérte.

Tipikus nginx-beállítás. A gzip_comp_level 6 jó kompromisszum sebesség és méret között:

gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_vary on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml application/xml;

location ~* \.(css|js)$ {
    brotli_static on;
    gzip_static on;
}

Az 1024 bájtos alsó küszöb azért hasznos, mert nagyon kis fájloknál a tömörítés többe kerül, mint amennyit hoz. A brotli_static és gzip_static a build során előre elkészített .br és .gz fájlokat szolgálja ki.

Gyakori kérdések

Melyiket válasszam, gzipet vagy Brotlit?
Mindkettőt kapcsold be egyszerre. A szerver a kliens Accept-Encoding fejléce alapján dönt, így a modern böngészők Brotlit kapnak, a régi kliensek gzipet. Ez nem választás kérdése, hanem tartalék-mechanizmus.
Mennyit gyorsul ettől az oldal?
Függ attól, mekkora szöveges tartalmat töltesz le. Egy 300 kB-os HTML esetén 200-250 kB megtakarítás reális, ami lassú mobilneten akár egy másodperc. Gyors kapcsolaton a különbség sokkal kisebb, néhány száz ezredmásodperc.
Rontja a tömörítés a szerver teljesítményét?
Közepes szinten alig érezhető a terhelés. Maximális tömörítési szintnél viszont már számottevő a CPU-használat minden egyes kérésnél. Statikus fájlokat ezért érdemes előre tömöríteni, és csak a dinamikus HTML-t csomagolni futás közben.
Ha van CDN-em, kell a szerveren is tömörítés?
Igen. A CDN gyorsítótár-tévesztéskor az origin szerverről kéri le a tartalmat, és ilyenkor az eredeti válasz mérete számít. A két réteg nem zárja ki egymást, csak arra ügyelj, hogy ne tömörítsenek egymás után kétszer.
Honnan tudom, hogy a keresőrobot is tömörítve kapja meg az oldalt?
A robotok is küldik az Accept-Encoding fejlécet, tehát ugyanazt kapják, amit a böngésző. A Search Console feltérképezési statisztikáiban láthatod az átlagos letöltési méretet és válaszidőt. Ha a tömörítés bekapcsolása után csökken az átlagos méret, a beállítás él.

Források

Kapcsolódó fogalmak

A te oldaladon hogy áll a(z) „Tömörítés (gzip, brotli)”?

Futtass egy SEO-auditot: pontszám, fejlesztői ítélet, a leggyorsabb javítások, és minden tételhez bizonyíték.

Ingyenes SEO-audit indítása