CDN: teljes útmutató

A CDN (Content Delivery Network, tartalomkézbesítő hálózat) földrajzilag szétszórt szerverek hálózata, amely a webhely fájljainak másolatát a látogatóhoz közeli pontról szolgálja ki. Ettől csökken a válaszidő, tehermentesül a saját szerver, és stabilabb lesz a webhely forgalmi csúcsok idején. SEO szempontból közvetett a haszna: gyorsabb betöltés, kevesebb szerverhiba, zavartalanabb feltérképezés.

Alapfogalmak

A CDN lényege egyszerű: ahelyett, hogy minden kérés egyetlen, egy adott helyen álló szerverhez futna be, a tartalom egy része a látogatóhoz közelebb eső szervereken is ott van. A látogató böngészője a legközelebbi vagy a legkedvezőbb elérésű ponthoz kapcsolódik, és onnan kapja meg a fájlt. Minél rövidebb az út, annál kevesebb idő megy el a hálózati oda-vissza utakra, és annál hamarabb indul a letöltés.

A CDN nem helyettesíti a webhely saját szerverét. A tartalom eredeti forrása továbbra is a webhely szervere marad, a CDN ennek a tartalomnak a közvetítője és gyorsítótára. Ha a CDN nem találja a kért fájlt a saját tárolójában, vagy a tárolt példány elavult, a kérést továbbítja az eredeti szervernek, a választ pedig eltárolja a következő látogatónak.

A legfontosabb fogalmak

Fogalom	Jelentés	Miért fontos
Origin (eredeti szerver)	A webhely saját szervere, ahol a tartalom eredetileg él	Innen tölti fel magát a CDN, és ide fut vissza minden kérés, amit nem tud kiszolgálni
Edge szerver, PoP	A CDN egy-egy földrajzi pontján álló kiszolgáló (Point of Presence)	Ez van közel a látogatóhoz, ez adja a gyorsulást
Cache hit	A kért fájl ott van az edge szerveren, onnan megy ki	Ilyenkor a legnagyobb a nyereség
Cache miss	A fájl nincs az edge szerveren, az originről kell lekérni	Ilyenkor a CDN inkább csak egy közbenső lépés
TTL	Meddig tekinthető frissnek egy tárolt példány	Ez dönti el, milyen gyorsan jut el a változás a látogatókhoz
Purge (érvénytelenítés)	A tárolt példányok kézi vagy automatikus törlése	Enélkül egy javítás napokig láthatatlan maradhat

Mit szolgál ki egy CDN?

A klasszikus felhasználás a statikus fájlok kiszolgálása: képek, stíluslapok, JavaScript fájlok, betűtípusok, videók. Ezek mindenkinek ugyanúgy néznek ki, ezért könnyű őket gyorsítótárazni. Egyre gyakoribb, hogy a CDN a teljes webhely elé kerül, és a HTML oldalakat is közvetíti. Ilyenkor a CDN nemcsak gyorsít, hanem átveszi a TLS kapcsolat kezelését, szűri a támadásokat, és egyes szolgáltatásoknál kódot is futtat a kérés útjában.

Mi nem CDN?

A tárhely. A CDN nem a tartalom otthona, hanem egy réteg előtte.
A böngésző gyorsítótára. Az a látogató saját gépén él, a CDN a hálózatban.
Egy gyorsabb szerver. Ha a lassúság oka az adatbázis vagy a lassú alkalmazáskód, és a HTML nem tárolható, a CDN keveset segít a HTML-en.

Hogyan működik?

A működés a névfeloldással kezdődik. Amikor a látogató beírja a webhely címét, a böngésző a DNS segítségével kideríti, melyik IP-címhez kell kapcsolódnia. CDN használatakor a domain vagy egy aldomain a CDN hálózatára mutat, és a CDN dönti el, melyik edge szerver címe kerüljön a válaszba. Egyes szolgáltatók ugyanazt az IP-címet hirdetik sok helyről, és a hálózati útválasztás viszi a kérést a legközelebbi ponthoz.

Az edge szerver ezután megnézi, van-e érvényes példánya a kért fájlból. Ha van, azonnal visszaküldi. Ha nincs, vagy a példány lejárt, a kérést továbbítja az originnek, megkapja a választ, továbbadja a látogatónak, és ha a szabályok engedik, eltárolja. A következő látogató, aki ugyanebből a régióból ugyanezt a fájlt kéri, már a tárolt példányt kapja.

Mitől függ, hogy mit tárol a CDN?

A tárolás szabályait két helyen lehet meghatározni. Az egyik az origin által küldött HTTP-fejlécek, elsősorban a Cache-Control. A max-age a böngészőnek és a közbenső gyorsítótáraknak is szól, az s-maxage csak a megosztott gyorsítótáraknak, például a CDN-nek. A private azt jelzi, hogy a válasz csak a látogató saját böngészőjében tárolható, a no-store pedig azt, hogy sehol. A másik hely a CDN saját beállítási felülete, ahol szabályokkal felülírhatók vagy kiegészíthetők a fejlécek. A két réteg közti ellentmondás a leggyakoribb hibaforrások egyike, erről a cache útmutató részletesebben szól.

A kérés útja egy példán

A látogató megnyitja a termékoldalt. A HTML-t a CDN továbbítja az originről, mert a beállítás szerint a HTML nem tárolható.
A böngésző a HTML-ben talált képeket és stíluslapokat is kéri. Ezek az edge szerveren már ott vannak, cache hit, gyors válasz.
Egy frissen feltöltött termékkép még nincs az edge szerveren. Cache miss, a CDN lekéri az originről, és eltárolja.
A következő látogatónál már ez a kép is az edge szerverről jön.

A CDN és a keresőrobotok

A Googlebot a CDN szemszögéből ugyanolyan kliens, mint bármelyik látogató: kéréseket küld, válaszokat kap. Ha a CDN gyorsan és hibamentesen válaszol, a feltérképezés zavartalan. Ha a CDN biztonsági rétege gyanúsnak ítéli a robot kéréseit, és ellenőrző oldalt vagy tiltó választ ad, a kereső a tényleges tartalom helyett ezt kapja. Ezért a CDN bevezetése mindig technikai SEO kérdés is, nem csak üzemeltetési döntés.

Fő módszerek

A CDN bevezetésének több útja van, és nem mindegy, melyiket választod. A döntést az határozza meg, mekkora a webhely, mennyire dinamikus a tartalom, és mennyi kontrollt akarsz a gyorsítótárazás felett.

Csak statikus fájlok egy külön hoszton

A régebbi, ma is elterjedt megoldás, hogy a képek, stíluslapok és szkriptek egy külön aldomainről vagy a CDN saját hosztnevéről töltődnek be, a HTML pedig marad az originen. Egyszerű bevezetni, és a statikus fájloknál jól működik. Hátránya, hogy a böngészőnek egy újabb hoszthoz is kapcsolódnia kell, ami a preconnect nélkül késleltetheti az első fájlokat. SEO szempontból arra kell figyelni, hogy a külön hoszt ne tiltsa a keresőrobotokat a saját robots.txt fájljában, mert a Google a képeket és a megjelenítéshez szükséges fájlokat is lekéri.

Teljes webhely a CDN mögött

Ennél a megoldásnál a domain a CDN-re mutat, és minden kérés a CDN-en halad át. A statikus fájlok tárolódnak, a HTML pedig vagy továbbítódik, vagy rövid ideig szintén tárolódik. Ez adja a legtöbb lehetőséget: egy helyen kezelhető a HTTPS, a HTTP/2 és a HTTP/3, az átirányítások egy része és a támadások szűrése. Cserébe nagyobb a tét: egy rossz szabály az egész webhelyet érinti.

HTML gyorsítótárazás

Tartalmi webhelyeknél, ahol a cikkek ritkán változnak és mindenkinek ugyanúgy néznek ki, a HTML is tárolható az edge szervereken. Ez a legnagyobb gyorsulást adja az első bájtig eltelt időben, mert az origin sokszor egyáltalán nem kap kérést. A feltétel, hogy a webhely képes legyen érvényteleníteni a tárolt oldalakat, amikor egy cikk módosul. Személyre szabott oldalaknál, kosárnál, bejelentkezett felületnél a HTML tárolása kerülendő.

Kép-CDN

Egyes szolgáltatások a képeket menet közben átméretezik és modern formátumba alakítják a böngésző képességei szerint. Ez sokat javíthat a képekkel teli oldalak betöltésén. Arra érdemes figyelni, hogy a kép URL-je stabil maradjon, mert a képkeresés a kép címét tekinti azonosítónak, és egy változó paraméterezés sok változatot hozhat létre ugyanabból a képből.

Döntési szabály

Helyzet	Javasolt megoldás
Kis webhely, egy országba szóló közönség, gyors origin	Statikus fájlok CDN-ről, vagy akár CDN nélkül is elég lehet
Nemzetközi közönség	Teljes webhely a CDN mögött, statikus fájlok hosszú tárolással
Tartalmi webhely, ritkán változó cikkek	Teljes webhely a CDN mögött, HTML rövid tárolással és purge folyamattal
Webáruház, személyre szabott oldalak	Statikus fájlok tárolása, HTML csak a nem személyes oldalakon
Sok kép, változó eszközök	Kép-CDN stabil URL-ekkel

Gyakori hibák

A CDN hibái ritkán látszanak a saját böngészőben, mert a fejlesztő gyakran bejelentkezve, egy adott régióból, már tárolt fájlokkal nézi a webhelyet. A kereső és a távoli látogatók viszont mást kaphatnak. Az alábbi hibák a leggyakoribbak.

A biztonsági réteg kizárja a keresőrobotot

A CDN-ek botvédelme ellenőrző oldalt, JavaScript kihívást vagy tiltó választ adhat azoknak a klienseknek, amelyeket gyanúsnak ítél. Ha ez a Googlebotot is érinti, a kereső a tényleges oldal helyett a kihívást látja, vagy 403, 429, illetve 5xx választ kap. A tartós hibaválasz a feltérképezés lassulásához, végső soron az oldalak kieséséhez vezethet. A megoldás a keresőrobotok ellenőrzött engedélyezése: a Google leírja, hogyan azonosítható a valódi Googlebot fordított DNS-lekérdezéssel vagy a közzétett IP-tartományokkal. A felhasználói ügynök szövegére önmagában nem szabad engedélyt építeni, mert azt bárki hamisíthatja.

Elavult HTML a gyorsítótárban

Ha a HTML tárolódik, és egy módosítás után nincs érvénytelenítés, a kereső és a látogatók a régi változatot kapják. Ez különösen kellemetlen, ha a módosítás SEO jelzést érint: egy javított canonical, egy eltávolított noindex, egy új belső link. A javítás ilyenkor csak a TTL lejárta után ér célba.

Hibaoldalak tárolása

Egyes beállításoknál a CDN a hibaválaszokat is eltárolja. Ha az origin egy pillanatra 5xx hibát ad, és ez a válasz tárolódik, a hiba a gyorsítótár élettartamáig megmarad, pedig az origin már rég helyreállt. Ugyanez igaz egy tévesen kiadott 404 válaszra.

Duplikált hosztok

Ha a CDN saját hosztneve a teljes HTML-t is kiszolgálja, a webhely két címen érhető el. Ha a kereső rátalál a CDN hosztnevére, duplikátumot lát. Megoldás: a CDN hosztja csak statikus fájlokat adjon ki, vagy a HTML oldalakon legyen önhivatkozó canonical a fő domainre, és a CDN hoszt HTML-je irányítson át.

Tévhit: a CDN önmagában javítja a rangsorolást

A CDN nem rangsorolási tényező. A haszna közvetett: gyorsabb betöltés, jobb Core Web Vitals értékek, kevesebb szerverhiba, stabilabb feltérképezés. Ha a webhely lassúságának oka a nagy JavaScript csomag vagy a rosszul optimalizált kép, a CDN csak a szállítás idejét rövidíti, a feldolgozásét nem.

Egyéb gyakori hibák röviden

A Vary fejléc rossz használata. Túl sok változó mentén tárolt válasz szinte soha nem lesz cache hit.
Követő paraméterek miatt szétszórt tárolás. Ha minden kampányparaméter külön tárolt példányt kap, a találati arány romlik.
Az átirányítások megduplázása. A CDN és az origin is átirányít, így átirányítási lánc vagy akár átirányítási hurok keletkezik.
Vegyes tartalom. A CDN-ről HTTP-n betöltött fájl HTTPS oldalon blokkolódhat.

Mérés

A CDN hatását három szinten érdemes mérni: működik-e egyáltalán a tárolás, gyorsult-e a betöltés a valós látogatóknál, és rendben van-e a keresőrobot kiszolgálása. Mindhárom szinthez van ingyenes eszköz.

Tárolás ellenőrzése a válaszfejlécekből

A legegyszerűbb ellenőrzés a válaszfejlécek megnézése a böngésző fejlesztői eszközeiben vagy parancssorból, például curl -I paranccsal. Az Age fejléc szabványos: azt mutatja, hány másodperce van a válasz a gyorsítótárban. A legtöbb CDN saját fejlécet is küld, amely jelzi, hogy cache hit vagy miss történt; ennek neve szolgáltatónként eltér, a dokumentációjukban megtalálható. Ha ugyanazt a fájlt kétszer egymás után kéred, és másodszorra sincs találat, a tárolási szabályokban van hiba.

Sebesség a valós látogatóknál

A laborméréseknél többet mond a terepi adat. A PageSpeed Insights a Chrome felhasználói adatai alapján mutatja az első bájtig eltelt időt és az LCP értéket, ha a webhelynek elég forgalma van. A Search Console Core Web Vitals jelentése oldalcsoportonként mutatja ugyanezt. A CDN bevezetése előtt és után érdemes a trendeket összevetni, és nem egy-egy mérésből következtetni, mert a terepi adatok gördülő időablakban frissülnek.

A keresőrobot kiszolgálása

A Search Console feltérképezési statisztikái jelentésében válaszkód, fájltípus és hoszt szerint látható, mit kapott a Googlebot. Egy CDN bevezetése utáni hirtelen 403 vagy 5xx növekedés szinte mindig a biztonsági réteg beállítására utal. Az URL-ellenőrző eszköz élő tesztje megmutatja, mit lát a Google egy adott oldalon: ha ott ellenőrző oldal jelenik meg a tartalom helyett, a CDN kizárja a robotot. A crawl budget szempontjából a válaszidő grafikonja is sokat elárul.

Ellenőrzőlista CDN bevezetés után

Statikus fájloknál a második kérésre cache hit a válasz.
A HTML tárolása csak ott történik, ahol szándékos, és van purge folyamat.
Hibaválaszok nem tárolódnak hosszan.
Az URL-ellenőrző élő tesztje a valódi tartalmat mutatja.
A feltérképezési statisztikákban nem nőtt a 4xx és 5xx arány.
A CDN hosztneve nem ad ki indexelhető HTML-t.
Az átirányítások egy lépésben érnek célba.

Kidolgozott példa: nemzetközi tartalmi webhely

Egy magyar nyelvű szakmai blog olvasóinak jelentős része külföldön élő magyar. Az origin egy hazai szerveren fut. A tulajdonos a teljes webhelyet CDN mögé teszi, a képekre és a stíluslapokra hosszú tárolást állít be verziózott fájlnevekkel, a HTML-re rövid tárolást, és a tartalomkezelőt úgy köti be, hogy egy cikk mentésekor a CDN érvénytelenítse az adott URL-t. Az első napokban a feltérképezési statisztikákban megjelenik néhány 403-as válasz: a botvédelem egyes Google-kéréseket kihívással fogadott. A tulajdonos engedélyezi az ellenőrzött keresőrobotokat, a 403-ak eltűnnek. Az eredményt nem egy számmal méri, hanem a terepi adatok trendjével a következő hetekben.