Mi az a CDN, és mikor van rá tényleg szükséged?

Ha a weboldalad vagy a webáruházad néha lassan tölt be, főleg a képeknél, biztos hallottál már róla, hogy egy úgynevezett CDN bevezetése segíthet rajta. De mi ez pontosan, és tényleg neked is kell? Ebben a cikkben egyszerűen, szakzsargon nélkül megyünk végig rajta. A végén egy saját méréssel is megmutatjuk, mennyit számít ez a gyakorlatban.

Ez a cikk egy háromrészes CDN-sorozat első része. Ha végigolvasod, ezt kapod a folytatásban is:

1. Mi az a CDN, és mikor van rá tényleg szükséged? (ez a cikk)
2. Mennyibe kerül egy CDN, és melyik szolgáltatót válaszd?
3. Hogyan épül fel egy előfizetéses videós platform CDN-nel? (esettanulmány)

Mi az a CDN, egyszerűen megfogalmazva?

Képzeld el, hogy eddig egyetlen raktárból szállítottad ki a termékeidet minden vásárlódnak, függetlenül attól, hogy Szegeden vagy Berlinben laknak. Egy CDN, magyarul nagyjából „tartalomkiszolgáló hálózat”, olyan, mintha ugyanezt az árut több városban is raktároznád. Mindenki a hozzá legközelebbi raktárból kapja meg a csomagját, nem a távoli központi raktárból.

A weboldaladnál ez konkrétan azt jelenti: a képeid, a betűtípusaid és néhány egyéb fájlod nem a te szerveredről érkeznek a látogatóhoz, hanem egy hozzá közelebbi szerverről, ami már tárol egy másolatot ezekből. Lehet, hogy a szervered messze van, ez a lényegen nem változtat. Rövidebb út, kevesebb várakozás, gyorsabb betöltés. Ennyi az egész.

A piacon nagyon sok cég kínál ilyen szolgáltatást, az ingyenestől a komoly, fizetős megoldásokig. A mi méréseinkhez hármat használtunk közülük: a jsDelivrt, a Cloudflare hálózatán futó cdnjs-t és az unpkg-ot. Hogy ezek közül, vagy egy másik szolgáltató közül melyiket érdemes választanod, és mennyibe kerül, azt a sorozat második részében nézzük meg részletesen.

Neked is szükséged van rá?

Ha a weboldalad azért lassabb, mert túl nagy, tömörítetlen képeket használsz, azon a CDN nem segít. Az egy másik probléma, amit előbb érdemes megoldani, erről lentebb még lesz szó. A CDN ott számít igazán, ha az alábbi három dolog közül legalább az egyik igaz rád:

• sok képet vagy egyéb fájlt szolgáltatsz ki a weboldaladról,
• a látogatóid nem csak egy szűk környékről, hanem az ország több pontjáról vagy külföldről is érkeznek,
• ugyanazokat a fájlokat több weboldal vagy webshop is a saját, közös forrásodból tölti be.

Ez utóbbira jó példa egy ügyfelünk esete. Egy központi rendszerből, egy ERP-ből három összekapcsolt webáruházat szolgáltunk ki. A termékképek egyetlen közös helyről jöttek, és mindhárom webshop onnan töltötte be őket, vagyis ugyanazok a képek háromszoros terhelés alatt futottak egyetlen szerveren. Amikor ezt kiváltottuk egy CDN-re, mindhárom webshop érezhetően felgyorsult.

Egy kisebb, néhány oldalas, magyar közönségű cégoldalnál a fenti három eset közül jellemzően egyik sem áll fenn igazán komolyan. Ott a CDN valószínűleg nem hozna érezhető változást, inkább máshol érdemes keresni a lassúság okát.

Mennyivel gyorsabb valójában? Amit a saját mérésünk mutatott

Ahelyett, hogy csak elmondanánk, inkább megmértük. 2026. augusztus 9-én egy magyarországi gépről letöltöttünk különböző fájlokat egyszer a saját szerverünkről, egyszer pedig három különböző CDN-ről, és megnéztük, mennyi idő alatt érkeztek meg. Minden fájlt hétszer töltöttünk le, és a középső eredményt vettük figyelembe, hogy egy véletlen kiugró érték ne torzítsa a képet.

A táblázatból jól látszik: a CDN-ek nagyjából kétszer olyan gyorsan szolgálták ki a fájlokat, mint a saját szerverünk. Ugyanannyi adat átviteléhez kevesebb mint fele annyi idő kellett. Az első válasz is gyorsabban jött a CDN-eknél, ezt hívják a táblázatban TTFB-nek, vagyis azt az időt, amíg az első adatbájt megérkezik.

Ez pedig még a legkevésbé látványos eset volt. A saját szerverünk is Magyarországon üzemel, és mi magunk is Magyarországról mértünk, tehát a földrajzi közelség, ami a CDN legnagyobb előnye, ebben a tesztben szinte alig játszott szerepet. Egy külföldi látogatónál, mondjuk egy németnél vagy egy amerikainál, a különbség minden bizonnyal jóval nagyobb lenne. Ott ugyanis a mi szerverünk fizikai távolsága is hozzáadódna a várakozási időhöz.

Egy technikai apróság, egyszerűen elmondva: a CDN-ek egy újabb, gyorsabb internetes szabvány szerint (HTTP/3) szolgálták ki a fájlokat, a saját szerverünk viszont a régebbi szabvány szerint. Ez főleg gyengébb vagy mobilnetes kapcsolatnál számít sokat, mert kevesebbszer szakad meg és gyorsabban épül fel vele a kapcsolat.

Egy fontos megjegyzés: a lioner.hu-n a képek helyesen vannak beállítva ahhoz, hogy a böngésződ egy évig megjegyezze őket. Ez alapból jó. A CDN nem ezt javítja, ezt bármelyik jó tárhelyen be lehet állítani, hanem azt oldja meg, amit egyetlen szerver fizikailag nem tud: hogy közelebb legyen a látogatóidhoz.

Őszintén a méréshez: a saját szerverünkről egy képet mértünk, a CDN-ekről egy hasonló méretű CSS-fájlt, mert ugyanaz a fájl nem volt elérhető mindkét helyen. Mindent azonos gépről, azonos időben mértünk. Az arányok emiatt tájékoztató jellegűek, nem laboratóriumi pontosságúak. Ezt nyíltan vállaljuk.

Mikor elég a jó tárhely, és mikor kell CDN?

Sok esetben egyszerűen a jó tárhely önmagában elég. Ha annak idején körültekintően választottál tárhelyszolgáltatót, ami gyorsan válaszol és rendesen átmenetileg tárolja (cache-eli) a képeket, akkor egy magyar közönségű, napi pár száz látogatós cégoldalnál a CDN valószínűleg nem fog érezhető változást hozni. A CDN ott kezd igazán számítani, amikor egy közös forrásból sok fájlt szolgáltatsz ki több oldalnak, vagy amikor a látogatóid jelentős része nem Magyarországról érkezik.

Mit ne várj a CDN-től?

A CDN bevezetése nem néhány perces feladat. Fejlesztői munkával jár: át kell állítani, hogy a fájlok onnan töltődjenek be, meg kell oldani, hogy egy frissített fájl esetén a CDN is friss verziót adjon ki, és sokszor a képek generálását is hozzá kell igazítani. Ez egy plusz költség, amit be kell árazni. Nem minden weboldalnál térül meg annyira, mint elsőre tűnik.

Ha az oldalad azért lassú, mert túl nagy, optimalizálatlan képeket töltesz be, vagy mert a tárhelyed eleve gyenge, a CDN csak elfedi a bajt, nem oldja meg. Előbb érdemes azt rendbe tenni, hogy milyen képformátumot használsz a weboldaladon. Utána van igazán értelme a CDN-ről beszélni.

Ha nem vagy biztos benne, hogy nálad tényleg a képek vagy a tárhely okozza a lassulást, ezt magad is le tudod ellenőrizni. Öt ingyenes böngészőbővítménnyel tíz perc alatt kiderül, hol veszíted el a sebességet, és az is, hogy ott tényleg a CDN segítené, vagy előbb mást kell megoldani.

Így nézd meg a PageSpeed Insights-ban, hogy tényleg a képek miatt vagy-e lassú

Van egy még konkrétabb, teljesen ingyenes eszköz is, ami kifejezetten erre a kérdésre ad választ: a pagespeed.web.dev. Írd be az oldalad címét, futtasd le a mérést a Mobil fülön (ez mutatja meg, milyen az élmény egy átlagos látogatónak, ami jellemzően rosszabb, mint amit asztali gépen mérnél), és ezt a három helyet nézd meg a riportban:

• Legnagyobb tartalmi elem (Largest Contentful Paint, LCP): ha ez az érték piros vagy sárga, vagyis 2,5 másodperc fölött van, a riport meg is mutatja, melyik elem a „legnagyobb tartalmi elem” – ha ez egy kép, az konkrét jele annak, hogy a látogatóid ténylegesen egy képre várnak a legtöbbet.
• „Képek betöltésének javítása” (Improve image delivery): ez a szekció név szerint felsorolja, mely képek töltődnek feleslegesen lassan, és mennyi adatot (KB-ot) spórolhatnál meg velük. Ha itt nagy megtakarítást ír ki, az szinte mindig azt jelenti, hogy a kép mérete vagy formátuma a hibás, nem a távolság – ilyenkor előbb a képformátumot és a tömörítést érdemes rendbe tenni, egy CDN önmagában ezen nem segít.
• „Kezdeti szerverválaszidő” (server response time / TTFB): ha ez lassú, az arra utal, hogy maga a szervered válaszol lassan induláskor – ez tárhelykérdés, amit szintén nem old meg egy CDN.

A CDN akkor jön ténylegesen a képbe, ha a fentieket már rendbe tetted – a képeid le vannak méretezve, jó formátumban vannak, a szervered gyorsan válaszol –, és a mérés mégis azt mutatja, hogy maguknak a fájloknak a letöltése tart sokáig. Ez tipikusan akkor jelentkezik, ha sok látogatód érkezik távolabbról, vagy ha – mint a korábban említett ügyfélpéldánkban – ugyanazokat a képeket több oldal is egyetlen közös forrásból tölti be. Görgesd le a riportban a képernyőképek idővonaláig (screenshot timeline) is: ha azon jól látszik, hogy egy kép vizuálisan csak jóval a többi elem után jelenik meg, az a saját szemeddel is megerősíti, amit a számok mutatnak.

Mit csinálunk mi ehhez a Lioner-nél?

A nálunk átadott admin felületeken minden feltöltött kép alapból három méretben mentődik le, és automatikusan a gyors, tömörített WebP formátumba alakul. Ezt minden ügyfelünk megkapja, külön kérés nélkül. Sok esetben ez önmagában is elég egy gyors oldalhoz, még mielőtt egyáltalán CDN-ben kellene gondolkodni.

A videók kezelése viszont ennél jóval többet igényel: nagyobb fájlméret, folyamatos lejátszás, azaz streamelés, és több formátum. Itt a CDN már nem luxus, hanem szükséges. Erről a sorozat harmadik részében írunk részletesen, egy konkrét esettanulmányon keresztül.

Összegzés

A CDN nem varázsszer, és nem is mindenkinek kell. Ha egy közös forrásból sok fájlt szolgáltatsz ki több oldalnak, vagy a látogatóid nagy része messziről érkezik, mindenképpen érdemes komolyan venni. A saját mérésünk szerint a különbség még a legkedvezőtlenebb esetben is kétszeres, távolabbi látogatóknál pedig ennél is nagyobb lehet. Ha viszont egy néhány oldalas, magyar közönségű cégoldalad van jó tárhelyen, rendezett képekkel, a CDN valószínűleg nem hoz érezhető változást. Helyette inkább a képeidet és a tárhelyedet érdemes rendbe tenni.

Te melyik esethez állsz közelebb? Ha nem vagy biztos benne, vagy szeretnéd, hogy megnézzük együtt, mennyit érne neked a váltás, keress minket, vagy nézd meg, hogyan gondolkodunk a weboldal készítésről nálunk.