Mitől lesz gyors egy weboldal?
A betöltési idő nem csak technikai kérdés: közvetlenül hat arra, hányan maradnak az oldalon és hányan lesznek ügyfelek.
Egy weboldal lehet látványos, informatív és szakmailag kifogástalan. Ha azonban a látogatónak várnia kell rá, könnyen előfordulhat, hogy mindebből semmit sem lát.
A weboldal sebessége ezért nem egyszerűen fejlesztői részlet. Része a felhasználói élménynek, az ügyfélszerzésnek és a keresőoptimalizálásnak is. Egy gyors weboldal a látogató első másodperceiben dől el.
Amikor valaki mobilról, gyengébb internetkapcsolatról vagy egy kevésbé erős eszközről érkezik az oldaladra, nem azt vizsgálja, miért lassú. Nem érdekli, hogy túl nagy a hero kép, sok JavaScript fut vagy lassan válaszol a szerver. Egyszerűen azt érzi:
várnia kell.
A webes teljesítmény üzleti hatását több nagyobb vizsgálat is kimutatta. A Vodafone egy A/B teszt során 31%-kal javította az LCP értékét és az optimalizált változatnál 8%-kal több értékesítést mért. Egy frissebb, 2026-os Nuvemshop esettanulmányban a jelentős LCP-javulás mellett a vizsgált mobilos organikus forgalomban 8,9%-kal magasabb konverziós arányt mértek. Ezek természetesen egyedi esetek és nem jelentik azt, hogy minden weboldal ugyanekkora növekedést ér el, de jól mutatják, hogy a teljesítmény üzleti kérdés is lehet.
Mit jelent valójában az, hogy gyors egy weboldal?
Sokan egyetlen számot keresnek: „Hány másodperc alatt tölt be?” A valóság ennél összetettebb.
A felhasználó nem feltétlenül azt érzékeli, hogy mikor töltődött le az utolsó fájl. Sokkal fontosabb, hogy mikor jelenik meg előtte az érdemi tartalom, mikor tud használni egy gombot vagy űrlapot és közben ugrálnak-e az elemek a képernyőn.
Ezért a Google sem egyetlen betöltési idővel írja le a felhasználói élményt. A jelenlegi Core Web Vitals három különböző területet mér:
A Google ezeket a határértékeket a felhasználói látogatások 75. percentilisén vizsgálja. Vagyis nem az a cél, hogy egyetlen tesztben egyszer jó eredményt kapjunk, hanem hogy a látogatók nagy többsége megfelelő élményt kapjon.
Az LCP: mikor látja a felhasználó azt, amiért érkezett?
A Largest Contentful Paint, vagyis LCP azt méri, hogy mennyi idő alatt jelenik meg a képernyőn a legnagyobb fontos tartalmi elem. Ez lehet például egy nagyméretű főoldali kép, egy banner, egy nagy címsor vagy egy másik domináns tartalmi elem.
Ha a látogató megnyitja az oldalt és hosszú ideig csak egy üres vagy félig elkészült felületet lát, számára az oldal lassú lesz akkor is, ha a háttérben már rengeteg fájl betöltődött.
A Google ajánlása szerint jó felhasználói élményhez az LCP értékének 2,5 másodpercen belül kell lennie.
Mi ronthatja az LCP-t?
Gyakori ok a túlméretezett hero kép, a lassú szerver, túl sok renderelést blokkoló CSS vagy JavaScript, rosszul kezelt betűkészletek vagy az, hogy a böngésző túl későn fedezi fel a legfontosabb erőforrást.
Különösen gyakori hiba, hogy a főoldal tetején található kép ugyanaz a több megabájtos fájl, amelyet eredetileg nyomtatáshoz vagy közösségi médiához készítettek. A böngészőnek viszont ezt mobilon is le kell töltenie. A látogató pedig vár.
Az INP: gyorsan reagál vagy gondolkodik az oldal?
Egy weboldal attól még nem gyors, hogy hamar megjelenik. Használhatónak is kell lennie.
Rákattintasz a menüre. Nem történik semmi. Megnyomod az ajánlatkérő gombot. Egy pillanatra megakad az oldal. Kiválasztasz valamit egy kalkulátorban. A felület késve reagál.
Az Interaction to Next Paint, vagyis INP azt méri, milyen gyorsan reagál a weboldal a felhasználó interakcióira. A Google szerint a jó INP célérték 200 milliszekundum vagy annál kevesebb.
Itt gyakran már nem a képek jelentik a legnagyobb problémát. Hanem a JavaScript. A túl sok vagy rosszul optimalizált JavaScript hosszabb ideig lefoglalhatja a böngésző fő szálát. Ilyenkor a látogató kattintása megtörtént, de a böngésző éppen mással van elfoglalva.
Különösen sok problémát okozhatnak a külső szolgáltatásokból érkező szkriptek, például chat modulok, videóbeágyazások, hirdetési rendszerek, analitikai eszközök és különféle marketing pluginek. A web.dev szerint ezek további hálózati kéréseket, feldolgozási terhelést és renderelési késést is okozhatnak.
Ezért nem mindig igaz az, hogy „Van még egy jó plugin, tegyük fel ezt is.”
Minden új elemnek ára lehet teljesítményben.
A CLS: amikor ugrál alattad a weboldal
Valószínűleg találkoztál már ezzel: meg akarsz nyomni egy gombot, de közvetlenül kattintás előtt betöltődik fölé egy kép és az egész oldal lejjebb ugrik. Vagy elkezdesz olvasni egy szöveget és a betűtípus betöltése után minden átrendeződik.
Ez a vizuális instabilitás. A Cumulative Layout Shift, vagy CLS ezt méri. A megfelelő célérték 0,1 vagy kevesebb.
Gyakori problémát jelentenek a méret nélküli képek, később betöltött beágyazások, dinamikusan megjelenő tartalmak és bizonyos webfont-megoldások.
A gyors oldal tehát nem csak hamar jelenik meg. Stabilan is jelenik meg.
A gyors weboldal alapja a jó technikai háttér
A frontend optimalizálás sokat számít, de ha a szerver lassan válaszol, már a folyamat elején időt veszítünk. A böngésző ugyanis csak azután kezdhet igazán dolgozni, hogy megkapja az oldal HTML-jét. Ezért fontos a szerver válaszideje és a Time to First Byte, vagyis TTFB.
A web.dev LCP-optimalizálási útmutatója kiemeli, hogy a lassú TTFB minden utána következő lépést késleltethet. Sem a képek, sem a CSS, sem a JavaScript betöltése nem tud megfelelően elkezdődni, ha az első válasz későn érkezik.
A tárhely tehát számít. De nem igaz az sem, hogy egy drága szerver önmagában gyors weboldalt eredményez. Gyenge kódot, óriási képeket és több megabájtnyi felesleges JavaScriptet nem old meg egy erősebb szerver.
A gyors weboldal a megfelelő infrastruktúra és a megfelelő fejlesztés együttese.
A képek gyakran a legnagyobb fájlok az oldalon
Egy modern weboldal látványvilágának fontos részei a képek. Nem az a cél, hogy ezeket eltüntessük. Az a cél, hogy pont akkora és olyan formátumú fájlt töltsünk le, amire az adott eszközön valóban szükség van.
Egy telefon kijelzőjén nincs értelme egy 4000 pixel széles képet letölteni csak azért, mert az eredeti fotó ekkora. A megfelelő képoptimalizálásnál számít a méret, a tömörítés, a fájlformátum és a reszponzív kiszolgálás is.
A modern képfeldolgozás lehetővé teszi, hogy ugyanabból a képből különböző méretű változatokat adjunk a böngészőnek és az eszköz kiválassza a számára megfelelőt. A web.dev is külön kezeli a képek teljesítményét, mert a képek sok weboldalon az átvitt adatmennyiség jelentős részét adják.
Nem minden képet kell azonnal betölteni
Tegyük fel, hogy egy hosszú oldalon 30 referenciafotó található. A látogató érkezéskor csak az első néhányat látja. Miért töltenénk le rögtön mind a harmincat?
Erre szolgál többek között a lazy loading, vagyis a késleltetett betöltés. Az oldal alsó részein található képek és iframe-ek csak akkor tölthetők be, amikor a látogató közeledik hozzájuk. Így a kezdeti betöltéshez kevesebb adat szükséges.
Viszont ezt sem szabad vakon alkalmazni. A főoldal tetején található, LCP-t adó hero képet például általában nem érdemes lazy loadinggal késleltetni. A böngészőnek éppen ezt az erőforrást kell minél hamarabb megtalálnia és letöltenie.
A jó optimalizálás nem mindent késleltet. A fontos dolgokat előre veszi és a kevésbé fontosakat későbbre hagyja.
A túl sok JavaScript és effekt visszaüthet
Modern weboldalakon látványos animációkat, parallax effekteket, mozgó háttereket és interaktív komponenseket lehet készíteni. Ezek megfelelően használva rengeteget adhatnak az élményhez. De minden effekt mögött van valamilyen technikai munka.
Ha a weboldal túl sok JavaScriptet tölt le vagy túl sok számítást végez egyszerre, az oldal később reagálhat a felhasználó műveleteire. Ez különösen mobiltelefonokon jelentkezhet.
A megoldás nem az, hogy minden animációt törölni kell. Hanem az, hogy az effekt szolgálja a designt és az élményt, ne pedig uralja a weboldal technikai működését.
Egy prémium weboldalnak nem attól kell modernnek tűnnie, hogy minden eleme mozog. A jó animáció finom, tudatos és teljesítmény szempontjából is kontrollált.
A harmadik féltől származó eszközök rejtett lassulást okozhatnak
Egy weboldal idővel könnyen megtelik külső szolgáltatásokkal:
- Analytics
- Tag Manager
- Meta Pixel
- Chat
- Hotjar
- YouTube
- Google Maps
- Időpontfoglaló
- CRM-widget
- Cookie rendszer
- A/B tesztelő eszköz
Egyenként mindegyik indokoltnak tűnhet. Együtt viszont jelentős mennyiségű hálózati kérést és JavaScriptet eredményezhetnek. A web.dev ezért külön javasolja a külső szkriptek rendszeres auditálását és a felesleges vagy egymást átfedő szolgáltatások eltávolítását.
Nem az a cél, hogy egy weboldal minél több marketingeszközt tartalmazzon. Az a cél, hogy azok legyenek rajta, amelyek ténylegesen értéket teremtenek.
A betűtípus is lassíthat
Az egyedi tipográfia fontos része lehet a márkának. De egy weboldal akár több különböző betűcsaládot és rengeteg betűvastagságot is letölthet. Minden egyes fájl újabb adat. Ráadásul a betűk betöltési módja hatással lehet arra is, hogy milyen gyorsan jelenik meg a szöveg és mennyire stabil az oldal elrendezése.
A web.dev ajánlásai között szerepel a szükséges fontok körének csökkentése, a megfelelő formátumok használata és a betöltés tudatos kezelése. Bizonyos esetekben a fontok előtöltése is indokolt lehet, de a túl sok preload akár más kritikus erőforrásoktól is elveheti a sávszélességet.
Ez jól mutatja a webes teljesítmény egyik legfontosabb szabályát:
Nem az a cél, hogy minden technikai optimalizációt bekapcsoljunk. Az a cél, hogy a megfelelőeket alkalmazzuk a megfelelő helyen.
A gyorsítótárazás rengeteg felesleges letöltést spórolhat meg
Ha valaki már meglátogatta a weboldaladat, nem feltétlenül kell minden egyes visszatéréskor ugyanazokat a fájlokat újra letöltenie. Erre szolgál a gyorsítótárazás. Megfelelő cache-stratégiával a böngésző vagy egy köztes kiszolgáló újra felhasználhat korábban letöltött erőforrásokat.
Ennek jelentősége különösen akkor látszik, amikor a látogató több aloldalt néz meg. A logót, közös CSS-fájlokat, betűtípusokat és számos más erőforrást nem kell minden oldalváltáskor teljesen újra letölteni.
A modern böngészők emellett olyan technológiákat is használnak, mint a back/forward cache, amely bizonyos esetekben szinte azonnal vissza tudja állítani a korábban meglátogatott oldalt.
CDN: amikor a tartalom közelebb kerül a látogatóhoz
Egy CDN, vagyis Content Delivery Network a statikus erőforrásokat több földrajzi helyen is elérhetővé teheti. Így egy külföldi látogatónak nem feltétlenül ugyanarról az egyetlen szerverről kell minden fájlt letöltenie. Ez főként nemzetközi weboldalaknál, nagyobb forgalomnál vagy sok statikus tartalom esetén lehet hasznos.
A CDN azonban nem varázseszköz. Ha maga az oldal rosszul van optimalizálva, a CDN nem old meg minden problémát. Ugyanúgy igaz ez mint a tárhelyre:
Jó infrastruktúra kell, de jó kód nélkül önmagában kevés.
Miért lehet lassú egy WordPress weboldal?
Nem azért, mert WordPress. És egy egyedi fejlesztés sem automatikusan gyors csak azért, mert egyedi. A sebességet az implementáció minősége határozza meg.
WordPress esetén problémát okozhat például a rengeteg plugin, nehéz page builder, rosszul optimalizált sablon, felesleges JavaScript, lassú adatbázis-lekérdezések vagy nem megfelelő tárhely. Egyedi fejlesztésnél ugyanez megtörténhet rosszul felépített kóddal.
A technológia önmagában tehát nem garancia. Az számít, hogyan használják.
Mobilon kell igazán gyorsnak lennie
Az irodában egy gyors számítógépen és gigabites interneten sok weboldal gyorsnak tűnik. Ez azonban nem feltétlenül tükrözi az ügyfelek valós élményét. A látogató lehet mobilhálózaton, régebbi telefonon, gyenge Wi-Fi kapcsolaton vagy éppen útközben.
Ezért különösen fontos a mobilos teljesítmény vizsgálata. Nem elég azt mondani: „Nálam egy másodperc alatt megnyílik.” A kérdés az:
A látogatóknál hogyan működik?
PageSpeed Insights: fontos eszköz, de ne csak a pontszámot nézd
A Google PageSpeed Insights jó kiindulópont a weboldal teljesítményének vizsgálatához. Van azonban egy fontos különbség: laboradatokat és ahol elegendő információ áll rendelkezésre, valós felhasználóktól származó terepi adatokat is mutathat.
A terepi adatok a Chrome User Experience Report, vagyis CrUX adataiból származnak. A laborvizsgálatot a Lighthouse végzi szimulált környezetben. Ez azért fontos, mert előfordulhat, hogy egy Lighthouse teszt kiváló eredményt ad, miközben a valós látogatók egy része gyengébb élményt kap. És fordítva.
Ezért nem szabad kizárólag a nagy zöld számot hajszolni.
Nem a 100/100 a cél
Egy gyakori tévhit: ha a PageSpeed 100 pontot mutat, akkor tökéletes a weboldal. Nem. A Lighthouse pontszám egy diagnosztikai mutató. Hasznos. De nem üzleti KPI. Nem mondja meg önmagában:
- hány ajánlatkérést kapsz
- jó-e az ajánlatod
- megfelelő-e a szövegezés
- könnyű-e használni az oldalt
- jó helyen szerepelsz-e a Google-ben
A Google maga is arra figyelmeztet, hogy nem érdemes kizárólag a tökéletes Core Web Vitals vagy egyetlen page experience mutató megszerzésére koncentrálni SEO célból. A teljes felhasználói élmény és a releváns tartalom továbbra is fontosabb összképet alkot.
Egy 96 pontos oldal nem feltétlenül jobb üzletileg egy 91 pontosnál. Sokkal fontosabb, hogy gyorsnak érződjön, stabil legyen, jól reagáljon és megfelelően szolgálja a látogatót.
A sebesség és a SEO kapcsolata
A gyors weboldal önmagában nem fog első helyre kerülni a Google-ben. Egy gyenge tartalmú, kevésbé releváns oldal nem fog csak azért megelőzni egy sokkal jobb találatot, mert néhány tizedmásodperccel gyorsabb.
A Google ugyanakkor megerősíti, hogy a Core Web Vitals mutatókat a rangsorolási rendszerei használják és jó értékek elérését javasolja a keresési teljesítmény valamint a felhasználói élmény érdekében. A Google azt is egyértelművé teszi, hogy ez nem egyetlen, mindent eldöntő rangsorolási jel.
Ezért a helyes SEO-stratégia nem az, hogy „Mindenáron legyen 100-as PageSpeed.” Hanem:
Legyen gyors, technikailag stabil, jól használható és közben adja meg a kereső felhasználójának azt a választ, amiért érkezett.
A gyors weboldal az ügyfélszerzés része
Tegyük fel, hogy Google Ads hirdetésekre havi több százezer forintot költesz. Minden kattintásért fizetsz. Az érdeklődő rákattint. Majd egy lassú landing oldal fogadja. Ebben az esetben nem csak felhasználói élményt veszítettél. Fizettél azért, hogy valakit odavigyél egy olyan oldalra, amely akadályozhatja a továbblépését.
Ugyanez igaz a keresőoptimalizálásra. Hónapokig dolgozol azon, hogy előrébb kerülj a Google-ben. A látogató végre megtalál. Majd vár.
A sebesség ezért nem önálló technikai projekt. A marketingfolyamat része.
Mitől lesz tehát valóban gyors egy weboldal?
Nem egyetlen plugintól. Nem egy gyorsítótár bekapcsolásától. Nem attól, hogy veszünk drágább tárhelyet. És nem attól, hogy a PageSpeed egyszer 100 pontot mutatott. A jó teljesítmény sok kisebb döntés eredménye.
- A szervernek gyorsan kell válaszolnia.
- A fontos tartalmakat a böngészőnek hamar fel kell fedeznie.
- A képeknek megfelelő méretben kell érkezniük.
- A JavaScriptből csak annyit érdemes betölteni, amennyire valóban szükség van.
- A külső szolgáltatásokat kontrollálni kell.
- A fontokat tudatosan kell kezelni.
- A nem látható tartalmakat sok esetben később lehet betölteni.
- A gyorsítótárazást megfelelően kell beállítani.
És mindezt nem egyszer. Folyamatosan mérni kell.
A sebesség idővel romolhat
Egy weboldal az átadás napján lehet nagyon gyors. Fél évvel később már nem biztos. Felkerül néhány új plugin. Új chatrendszer kerül az oldalra. Beillesztünk egy videót. Marketinges szkriptek kerülnek be. Feltöltünk húsz optimalizálatlan képet. Új betűtípust használunk. Új funkció készül. A teljesítmény lassan romlik.
Ezért a sebességet nem érdemes egyszeri feladatként kezelni. A gyors weboldal fenntartása folyamatos kontrollt igényel.
Hogyan vizsgálnánk meg egy lassú weboldalt?
Elsőként nem „gyorsító plugint” telepítenénk. Megkeresnénk a probléma okát.
Megnéznénk a valós Core Web Vitals adatokat és a mobil valamint asztali teljesítményt. Megvizsgálnánk a szerver válaszidejét, az LCP elemet, a betöltött képeket, a CSS és JavaScript mennyiségét, a külső szkripteket, a fontokat és a gyorsítótárazást.
Ezután lehet sorrendet felállítani. Mert nem minden hiba ugyanolyan fontos. Ha egyetlen hero kép 4 MB, valószínűleg nem a 3 KB-os ikon optimalizálásával érdemes kezdeni.
Először azt javítjuk, ami a legnagyobb hatással van a felhasználóra.
Gyors weboldal vagy látványos weboldal?
A kettő nem zárja ki egymást. Egy modern weboldal lehet látványos, animált, interaktív, prémium és közben gyors is. A különbség a megvalósításban van.
Egy jó fejlesztésnél már a design fázisban figyelembe vesszük a teljesítményt. Nem utólag próbáljuk meg „felgyorsítani” azt, ami eleve túl nehézre épült. Ez az egyik legfontosabb különbség.
A teljesítmény nem az utolsó optimalizációs feladat. Már a tervezés része.
A gyorsaság nem önmagáért fontos
A látogatót nem érdekli az LCP rövidítés. Nem fogja megnézni az INP értékedet. És valószínűleg azt sem tudja, mi az a CLS. Csak ezt érzi: gyors volt vagy lassú. Kényelmes volt vagy idegesítő. Megtalálta, amit keresett vagy inkább továbbment.
A technikai mutatók azért fontosak, mert segítenek mérhetővé tenni ezt az élményt. A végső cél viszont nem egy zöld jelentés. Hanem egy olyan weboldal, amely nem akadályozza az ügyfeledet abban, hogy megismerjen, megbízzon benned és kapcsolatba lépjen veled.
A jó weboldal gyorsnak érződik és gyors is
Egy gyors weboldal mögött nincs egyetlen titkos beállítás. Megfelelő technikai alapok, optimalizált képek, kontrollált JavaScript, jól kezelt betűtípusok, tudatos erőforrás-betöltés, gyors szerver és rendszeres mérés dolgozik együtt.
Ezért a sebességoptimalizálást nem érdemes különválasztani a weboldal többi részétől. A design, a fejlesztés, a SEO és a felhasználói élmény ugyanannak a rendszernek a része.
Egy weboldal nem attól jó, hogy gyors egy tesztben. Attól jó, hogy a valódi látogatóknál is gyorsan és stabilan működik.