A CDN-t (tartalomkézbesítő hálózatot) sok magyar kisvállalkozás úgy kapja meg, hogy meg sem kérdezik tőle: a tárhelycsomagban ott egy kapcsoló, valaki felkattintja, és onnantól mindenki abban bízik, hogy az oldal gyorsabb lett. Néha tényleg az. Máskor semmi nem változik, viszont a szervernaplóban minden látogató ugyanazzal az IP-címmel jelenik meg, a sütibanner furcsán viselkedik, és fél évvel később derül ki, hogy a mérési adatok egy része használhatatlan. Érdemes tehát a döntést visszavinni oda, ahol el kellett volna kezdeni: mit old meg a CDN, kinek oldja meg, és mit kér cserébe (nem pénzben, hanem üzemeltetési bonyolultságban).
Mit csinál valójában egy CDN, és mit nem?
A CDN a fájljaid másolatát több tucat földrajzi ponton tárolja, és a látogatót a hozzá legközelebbi kiszolgálóponthoz irányítja. Ha a kért fájl megvan a gyorsítótárban (találat), a válasz onnan megy ki, és az eredeti szervered meg sem szólal. Ha nincs meg (kihagyás), a CDN elkéri az origintől, kiszolgálja, és a beállított élettartamig eltárolja.
Hivatalosan igazolt: a nagy szolgáltatók dokumentációja egybehangzóan három dolgot ígér: kisebb hálózati késleltetést a távoli látogatóknál, az origin tehermentesítését, és egy védelmi réteget a rosszindulatú forgalom ellen. Amit egyik dokumentáció sem ígér: hogy a lassú adatbázis-lekérdezésed vagy a húsz beépülő modulod okozta késés eltűnik.
Szakmai feltételezés: egy magyar látogató és egy magyar adatközpontban álló szerver között a hálózati oda-vissza idő jellemzően olyan alacsony, hogy a CDN által megspórolható késleltetés a teljes betöltési időnek csak töredéke. A tényleges nyereség itt szinte mindig a gyorsítótárazásból jön, nem a földrajzi közelségből.
Mikor hoz valódi javulást a CDN egy magyar KKV-oldalnak?
Röviden: akkor, ha a látogatóid egy része messze van, vagy ha sok, ritkán változó fájlt szolgálsz ki, vagy ha a forgalmad hullámzik.
- Nemzetközi látogatók. Ha van német, osztrák, angol vagy tengerentúli közönséged (export, turizmus, szálláshely, kivándorlóknak szóló szolgáltatás), ott a földrajzi távolság valóban mérhető, és a CDN a legolcsóbb megoldás rá.
- Képnehéz oldal. Galéria, portfólió, étlap, ingatlan- vagy termékfotók: itt a letöltött bájtok nagy része statikus, és pont ez az, amit a gyorsítótár jól kezel. Sok szolgáltató ráadásul menet közben modern képformátumra alakít és méretez.
- Sok statikus fájl. Betűtípusok, ikonkészletek, videórészletek, letölthető PDF-ek, dokumentációk.
- Forgalmi csúcsok. Hírlevélkiküldés, rádió- vagy tévémegjelenés, szezonális kampány, Black Friday. A CDN itt nem gyorsít, hanem megakadályozza, hogy az oldal éppen a legrosszabb pillanatban feküdjön le.
- Bot- és támadásvédelem. A folyamatos automata forgalom (kéretlen űrlapkitöltés, felderítő szkennelés, adatgyűjtő robotok) a peremhálózaton szűrve meg sem terheli a szervert.
Saját tapasztalat: a magyar kisvállalkozói oldalaknál a leggyakrabban a képnehéz eset és a forgalmi csúcs indokolja a CDN-t, nem a nemzetközi közönség. Egy tipikus szolgáltatói bemutatkozó oldalon a látogató a képek és a betűtípusok letöltésére vár, nem a HTML-re.
Mikor nem éri meg bekapcsolni?
Ha a látogatóid gyakorlatilag mind magyarok, a szervered magyar vagy közép-európai adatközpontban áll, és az oldal néhány oldalból, kevés képből áll, akkor a CDN-től nem várhatsz érzékelhető gyorsulást. Ilyenkor a bevezetés kockázata (rossz gyorsítótár-szabály, torz napló, elrontott sütikezelés) reálisan nagyobb, mint a haszon.
Ugyanez igaz akkor is, ha az oldal döntő része bejelentkezés mögött van: ügyfélportál, tagi felület, foglalási rendszer belső képernyői. Ezt a tartalmat nem szabad megosztott gyorsítótárba tenni, tehát pont az marad ki a CDN hatóköréből, ami a felhasználó idejének nagy részét kitölti.
És van egy szervezeti feltétel is: kell valaki, aki érti a beállítást, tudja üríteni a gyorsítótárat, és baj esetén vissza tud állni. Ha ez a valaki nincs meg, a CDN egy újabb réteg, ahol hibázni lehet, és ahol a hibát nehéz észrevenni.
Miért nem gyógyszer a CDN a lassú oldalra?
Ez a cikk saját nézőpontja, és a legfontosabb mondata: a CDN nem a lassú oldal gyógyszere, hanem a gyors oldal skálázója.
Ha az origin szervered másfél másodperc alatt állítja elő a HTML-t, akkor minden gyorsítótár-kihagyás továbbra is másfél másodperc lesz, csak most már egy extra közvetítővel. Az első látogató minden peremponton kihagyást okoz, a ritkán látogatott aloldalaknál pedig gyakorlatilag mindenki az első látogató. A CDN a jó számokat sokszorozza, a rosszakat nem javítja meg.
Ezért a sorrend szinte mindig ez: előbb szerveroldali gyorsítótár és a felesleges beépülő modulok kitakarítása, aztán a képek méretezése és modern formátumra váltása, aztán a betűtípusok és a szkriptek betöltési sorrendje, és csak ezután a CDN. Fordított sorrendben a CDN elfedi a tüneteket, és a valódi ok bent marad a rendszerben.
Melyek a leggyakoribb beállítási buktatók?
A hibák nagy része nem a sebességben, hanem a mellékhatásokban jelentkezik, és pont ezért nem veszi észre senki hetekig.
Kettős HTTPS-átirányítás
Klasszikus eset: a CDN a látogató felé HTTPS-t ad, de az origin felé HTTP-vel fordul, az origin viszont minden HTTP-kérést átirányít HTTPS-re. Ebből vagy végtelen átirányítási hurok lesz, vagy legalábbis felesleges kör minden kérésnél. A megoldás: a CDN és az origin között is titkosított kapcsolat (teljes, lehetőleg ellenőrzött módban), az origin tanúsítvánnyal, és egyetlen átirányítási szabály, egyetlen helyen. Ellenőrzés: curl -IL https://a-te-domained.hu, és nézd meg, hány 301-es lépcső van a végleges cím előtt. Egynél több már hiba.
Rossz gyorsítótár-fejlécek
A két véglet egyformán rossz. Ha mindenre max-age=0 megy, a CDN gyakorlatilag semmit nem tárol, és a bevezetés értelmetlen. Ha mindenre hosszú élettartam megy, akkor a következő tartalomfrissítést a látogatók egy része hetekig nem látja. Ésszerű alap: verziózott vagy tartalom-lenyomattal ellátott statikus fájlokra hosszú élettartam, HTML-re rövid, a felhasználóhoz kötött válaszokra semmi.
Cache-Control: public, max-age=31536000, immutable a hasított nevű CSS- és JS-fájlokra, Cache-Control: private, no-store a kosárra és a fiókoldalakra, és Vary: Accept-Encoding a tömörített változatok megkülönböztetéséhez.
Dinamikus oldalak gyorsítótárazása
A legdrágább hiba: a peremhálózat elmenti egy bejelentkezett felhasználó oldalát, és kiszolgálja valaki másnak. Webshopnál ez idegen kosarat, idegen nevet, rosszabb esetben idegen adatot jelent. Kötelező kihagyási szabályok: a kosár, a pénztár, a fiók és az adminfelület útvonalai, továbbá minden kérés, amiben bejelentkezési süti van. Az űrlapok egyszer használatos biztonsági tokenjei szintén elavulnak a gyorsítótárban, ezért a kapcsolati űrlapot tartalmazó oldalt vagy ki kell hagyni, vagy a tokent kell kliensoldalon, külön kéréssel betölteni.
Hibás valós IP-továbbítás a naplókban
CDN mögött a szervered a peremhálózat IP-címét látja, nem a látogatóét. Ha ezt nem javítod, három dolog romlik el egyszerre: a statisztikád (mindenki ugyanonnan jön), a védelmi modulod (néhány rossz kérés után kizárhatod az egész CDN-t, vagyis az összes látogatót), és a kéretlen üzenetek szűrése. A javítás a webszerveren történik, a szolgáltató IP-tartományainak felsorolásával és a megfelelő fejléc kijelölésével, például set_real_ip_from 198.51.100.0/24; real_ip_header CF-Connecting-IP; vagy a szabványos X-Forwarded-For használatával. Fontos, hogy csak a megbízható peremhálózattól fogadd el a fejlécet, különben bárki hamisíthatja.
Sütibanner-torzítás
Ha a hozzájárulás állapota a kiszolgált HTML-be van beleégetve, a gyorsítótár azt a változatot menti el, amelyik éppen odakerült. Ebből az lesz, hogy a banner visszatér annak is, aki már döntött, vagy éppen fordítva: a mérőkódok olyannak is elindulnak, aki nemet mondott. Ez adatvédelmi kockázat, nem csak kényelmi kérdés. A megbízható megoldás, hogy a hozzájárulás kezelése teljes egészében kliensoldalon fut, a süti értéke alapján, a kiszolgált HTML pedig minden látogatónak azonos. Süti szerinti gyorsítótár-változatokat csak nagyon indokolt esetben állíts be, mert szétaprózzák a találati arányt.
Mi legyen az élesítés utáni ellenőrzőlistán?
Nyolc pont, amit érdemes végigmenni még aznap, nem egy hét múlva:
- Átirányítási lánc.
curl -ILa főoldalra és két aloldalra: egyetlen 301 a végleges címre, hurok nélkül, HTTP-ről és www-ről indulva is. - Találati arány.
curl -Iegy CSS-re, egy képre és a főoldalra, és nézd a gyorsítótár-állapot fejlécet. A statikus fájloknak a második kérésre találatot kell adniuk. - Kihagyási szabályok. Jelentkezz be, tegyél terméket kosárba, majd inkognitóablakból nyisd meg ugyanazt az oldalt: nem láthatod a bejelentkezett állapotot.
- Valós IP. Nézz rá a hozzáférési naplóra és az oldalmotor bejelentkezési naplójára: valódi látogatói címeket kell látnod, nem egyetlen ismétlődő tartományt.
- Űrlapok és fizetés. Kapcsolati űrlap, visszahívás-kérés, keresés, ajánlatkérés, és ha van, a fizetési folyamat végigpróbálva, kétféle böngészőből.
- Feltérképezhetőség. A
robots.txt, a webhelytérkép és a kanonikus címek az eredeti tartalmat adják vissza, és a botvédelem nem dob emberi ellenőrzést a keresőrobotok elé. Ezt a Search Console élő URL-vizsgálatával is nézd meg. - Betűtípusok és képek. A betűtípusok betöltődnek (a hiányzó CORS-fejléc miatt szoktak eltűnni), és az automatikus képformátum-váltás nem rontotta el a látványt, főleg az átlátszó hátterű logóknál.
- Visszaállási terv. Legyen leírva, hogyan üríted a gyorsítótárat, hogyan kapcsolod ki a CDN-t, és mennyi a DNS-rekord élettartama. Az első héten tartsd alacsonyan, hogy a visszaállás percek, ne órák kérdése legyen.
Hogyan mérd, hogy tényleg nyertél-e vele?
Az egyetlen PageSpeed-futás nem mérés, hanem hangulatjelentés. A számok futásról futásra ingadoznak, és a laborteszt egy szimulált eszközön, szimulált hálózaton fut.
Hivatalosan igazolt: a Google a Core Web Vitals értékelésénél valós felhasználói adatokat használ, amelyek 28 napos gördülő ablakban gyűlnek. Ez azt jelenti, hogy a CDN élesítése után nem másnap, hanem hetek múlva látszik a teljes hatás a Search Console jelentésében.
Gyakorlati mérési terv: két héttel az élesítés előtt és két héttel utána, azonos hosszú, összehasonlítható időszakon. Rögzítsd a laborértékeket öt futás mediánjaként (LCP, TTFB, teljes letöltött méret), a valós adatokat a Search Console riportjából, a szerveroldali választ pedig parancssorból, például curl -o /dev/null -s -w '%{time_starttransfer}\n' https://a-te-domained.hu ismételve, különböző napszakokban. Külön mérd a gyorsítótár-találati arányt: ha ez alacsony, a CDN nem dolgozik, hiába nézel jó összképet.
Saját tapasztalat: a leggyakoribb tévedés a hatás túltulajdonítása. Ha a CDN élesítése egybeesik egy képoptimalizálással és egy beépülőmodul-takarítással, utólag nem fogod tudni szétszálazni, melyik mit hozott. Ha teheted, egy hét különbséggel élesítsd a lépéseket, és mindegyik után jegyezd fel a számokat. A konverzióban jelentkező hatásra pedig legyél óvatos: a gyorsulás segítheti a vásárlási arányt, de egy KKV-forgalomnál a szezonalitás és a hirdetési aktivitás jóval nagyobb zajt ad, mint a néhány száz ezredmásodperces javulás, ezért a rövid távú eltérésből nem lehet ok-okozatot levezetni.
Mit jelent mindez az AI-keresők és válaszmotorok szempontjából?
A válaszmotorok ugyanúgy programozott ügyfélként kérik le az oldalt, mint a keresőrobotok, csak jellemzően kevésbé türelmesek, és sok esetben nem futtatnak JavaScriptet. Ha a CDN botvédelme szigorúra van állítva, előfordulhat, hogy a tartalmad emberi látogatónak elérhető, egy adatgyűjtő ügynöknek viszont ellenőrző képernyőt ad, tehát a rendszer szempontjából üres.
Hivatalosan igazolt: a Google Search Central leírja, hogy a szerver válaszideje és hibaaránya befolyásolja a feltérképezési ütemet, és hogy a robotokat kiszolgáló válasznak azonosnak kell lennie a felhasználónak adott tartalommal.
Szakmai feltételezés: a jó gyorsítótár-találati arány valószínűleg kedvez az automata lekéréseknek is, mert stabil, gyors és egységes válaszokat kapnak. Ez nem rangsorbeli előny, és nem garantál idézettséget, de kizár egy egész hibaosztályt, ami egyébként némán megeszi a láthatóságodat. Ha döntést hozol arról, mely adatgyűjtő robotokat engeded be, azt tudatosan tedd, és a döntést a peremhálózaton és a robots.txt fájlban is következetesen vezesd át.
A gyakorlati végkövetkeztetés egyszerű: nézd meg, hol van a látogatód, mit tölt le valójában, és mennyire ingadozik a forgalmad. Ha ezek közül egyik sem indokolja, ne kapcsold be csak azért, mert benne van a csomagban. Ha viszont indokolja, a bevezetést kezeld projektként, nem kapcsolóként: a fenti nyolc pont végigmenetele nagyjából annyi időt vesz igénybe, mint egy alapos délelőtt, és pontosan azokat a hibákat előzi meg, amelyek hónapokig észrevétlenek maradnak.
Források és további olvasnivalók
- Google Search Central, dokumentáció a feltérképezési költségkeretről és a szerver válaszidejéről
- Google Search Central, Core Web Vitals és az oldalélmény jelzései
- Chrome User Experience Report (CrUX) dokumentáció
- web.dev, LCP, INP és TTFB útmutatók
- MDN Web Docs, HTTP gyorsítótárazás és a Cache-Control fejléc
- MDN Web Docs, X-Forwarded-For és Forwarded fejlécek
- W3C, Web Performance munkacsoport specifikációi
- Cloudflare Docs, gyorsítótár-szabályok és SSL/TLS üzemmódok
- nginx dokumentáció, ngx_http_realip_module
- Nemzeti Adatvédelmi és Információszabadság Hatóság tájékoztatói a sütikezelésről
- A CDN nem a lassú oldal gyógyszere, hanem a gyors oldal skálázója: ha az origin lassan válaszol, a gyorsítótár-kihagyás ugyanolyan lassú marad.
- A leggyakoribb kár nem a sebességben, hanem a naplókban, a sütikezelésben és a dinamikus oldalak téves gyorsítótárazásában keletkezik.
- Kizárólag magyar közönség és magyar szerver mellett a nyereség jellemzően a mérési hibahatár közelében mozog.
- Élesítés után nyolc pontot kell végigellenőrizni, mielőtt bárki azt mondaná, hogy kész.
- A javulást előtte-utána, azonos hosszú időszakon, valós felhasználói adatokon mérd, nem egyetlen PageSpeed-futáson.
Gyakori kérdések
Ingyenes CDN-nel is érdemes elindulni?
Igen, egy magyar KKV-oldalnál az ingyenes szint jellemzően bőven elég a statikus fájlok kiszolgálására és az alap botvédelemre. A korlát nem a szolgáltatás, hanem a beállítás minősége: rosszul konfigurált ingyenes CDN több kárt okoz, mint amennyit egy fizetős csomag hozna.
Honnan tudom, hogy egyáltalán van-e már CDN az oldalam előtt?
Futtass egy curl -I parancsot a domainedre, és nézd meg a válaszfejléceket: a szolgáltató neve, a gyorsítótár-állapot fejléc vagy a kiszolgálópont azonosítója általában elárulja. Ugyanezt látod a böngésző fejlesztői eszközeinek hálózati fülén is, az első kérés fejlécei között.
Ront-e a CDN a keresőoptimalizáláson?
Önmagában nem, de három beállítási hiba ronthat rajta: ha a botvédelem kizárja a keresőrobotokat, ha az átirányítási lánc többlépcsős lesz, vagy ha a robotnak más tartalom megy ki, mint a felhasználónak. Mindhárom ellenőrizhető a Search Console élő URL-vizsgálatával.
Mennyi idő alatt látszik a hatás a mérőeszközökben?
A laborértékek azonnal változnak, a valós felhasználói adatok viszont 28 napos gördülő ablakban gyűlnek, ezért a Search Console jelentésében jellemzően több hét után áll be a teljes kép. Emiatt érdemes az élesítés napját feljegyezni, és ahhoz viszonyítva olvasni a görbét.
Webshopnál mit kell máshogy csinálni?
A kosarat, a pénztárt, a fiókoldalakat és minden bejelentkezési sütit tartalmazó kérést ki kell hagyni a gyorsítótárból, a termékoldalakat viszont rövid élettartammal lehet tárolni. Élesítés után teljes vásárlási kört kell végigpróbálni, mert a hibás gyorsítótárazás itt nem lassulást, hanem rossz adatot okoz.
Ha a CDN bekapcsolása után lassabb lett az oldal, mi lehet az ok?
A leggyakoribb ok a nulla közeli találati arány, vagyis hogy a CDN mindent továbbenged az originhez, és csak egy extra kört ad a lánchoz. Nézd meg a gyorsítótár-állapot fejléceket, az élettartam-beállításokat, és azt, hogy nem süti szerint aprózódik-e szét a tárolt változatok halmaza.
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.