Nyisd meg a saját weboldaladat telefonon, és figyeld meg az első néhány másodpercet. Nem azt, hogy szép-e. Nem azt, hogy modern-e. Hanem azt, hogy mennyire gyorsan érzed azt: „rendben, ez az oldal működik.”
Ma már a látogató nem feltétlenül várja meg, amíg egy weboldal teljesen betölt. Megnyom egy gombot, görget egyet, megnyitja a menüt, és már az első pillanatokban kialakít egy benyomást arról, hogy az oldal gyors, lomha, stabil vagy éppen nehézkes.
Éppen ezért a weboldal sebessége már nem pusztán technikai kérdés. Része lett annak is, hogyan érzékeli a felhasználó a márkádat.
2026-ban ezért nem az a jó kérdés, hogy „hány másodperc alatt tölt be az oldalam?”, hanem az, hogy mikor érzi a látogató azt, hogy már használhatja.
A weboldal sebessége már nem csak a betöltésről szól
Sokáig úgy gondoltunk a weboldal sebességére, mint egy egyszerű stopperórás versenyre. Mikor jelent meg az oldal? Mikor töltődött be a kép? Mikor lett kész az egész?
Ez ma már túl kevés ahhoz, hogy megértsük a valódi felhasználói élményt.
A Core Web Vitals egyik kulcsfontosságú mutatója, az Interaction to Next Paint, vagyis INP azt vizsgálja, mennyire gyorsan reagál a weboldal a felhasználó műveleteire: kattintásra, érintésre és billentyűleütésre. A jó INP érték 200 milliszekundum vagy az alatti, 500 milliszekundum felett pedig már gyenge válaszkészségről beszélünk. Ezt a 75. percentilis, valós felhasználói adatok alapján kell nézni, nem egyetlen Lighthouse-mérésből.
Ez azt jelenti, hogy lehet egy oldal látványosan gyorsan betöltve, mégis rossz élményt adhat, ha a gombra kattintás után késik a menü, a keresés vagy egy űrlap reakciója. A görgetés önmagában nem INP-interakció, de a menü, a gomb és az űrlap igen.
A gyors weboldal nem egyszerűen az, amelyik gyorsan megjelenik. Az is gyorsnak számít, amelyik gyorsan reagál arra, amit a látogató csinál.
A böngészőben a JavaScript és más feladatok a fő végrehajtási szálon is futhatnak. Ha túl sok munka torlódik itt össze, a böngésző nehezebben tud időben reagálni a kattintásokra, érintésekre és egyéb felhasználói műveletekre.
Éppen ezért az INP javításának egyik fontos része a felesleges JavaScript, a túl nagy feladatok, valamint a szükségtelen, harmadik féltől származó kódok visszaszorítása.
A képek még mindig az egyik legnagyobb sebességgyilkosok
Hiába van gyors tárhelyed és jó szervered, egy hatalmas, feleslegesen nagy kép ugyanúgy képes visszafogni az oldalt.
Az egyik legfontosabb változás az elmúlt években az, hogy már nem egyetlen „legjobb” képformátumot kell keresni. A cél az, hogy a megfelelő formátumot, megfelelő méretet és megfelelő tömörítést add a megfelelő eszköznek.
Az AVIF például egy korszerű képformátum, amely jó tömörítést kínál, de nem jelenti azt, hogy minden képhez automatikusan ezt kell választani. A böngésző támogatása, a kép típusa és a weboldal megvalósítása egyaránt számít.
Még fontosabb a reszponzív képkezelés. A srcset és a sizes segítségével a böngésző a rendelkezésére álló információk alapján választhat megfelelő képméretet, így egy telefonra nem kell feleslegesen egy több ezer pixeles asztali képet letölteni.
A blog kiemelt képe, a hero kép és minden első képernyőn megjelenő vizuális elem külön figyelmet érdemel. Ezeket nem érdemes automatikusan lazy loadolni, ha valóban a látható területen vannak. A fontos LCP-kép esetében a megfelelő HTML-markup és szükség esetén a fetchpriority="high" is segíthet.
A weboldalnak nem csak gyorsnak, hanem stabilnak is kell lennie
Megvan az az érzés, amikor megnyitsz egy oldalt, elkezdesz olvasni, majd hirtelen minden lejjebb ugrik, mert megérkezett egy kép vagy egy reklám?
Ez nem egyszerűen idegesítő. Ez egy valódi felhasználói élményprobléma, amelyet a Core Web Vitals CLS, vagyis Cumulative Layout Shift mérőszáma is vizsgál.
A stabil oldalnál a böngésző előre tudja, mekkora helyet kell fenntartania a képeknek, betűknek és más elemeknek. Ezért fontos például a képek szélességének és magasságának megadása, és ezért számít az is, hogyan töltődnek be a webfontok.
A modern weboldal nem attól érződik prémiumnak, hogy minden mozog rajta. Sokszor éppen attól, hogy semmi sem ugrál, és nem vesz el kontroll nélkül a látogató előtt.
A böngésző már maga is okosabban dönti el, mit töltsön be
A modern böngészők nem egyszerűen sorban töltik le a weboldal összes erőforrását. Folyamatosan próbálják meghatározni, mi fontos, mi sürgős, és mi várhat.
Ehhez a fejlesztő is adhat segítséget a Fetch Priority segítségével. Egy fontos LCP-kép például kaphat fetchpriority="high" jelzést, míg egy kevésbé fontos kép alacsonyabb prioritást kaphat. Ez azonban csak egy hint a böngészőnek, és túlzott használata akár ronthat is a helyzeten.
A cél tehát nem az, hogy mindent magas prioritásúvá tegyünk. Éppen ellenkezőleg. A jó teljesítmény egyik része az, hogy tudjuk, minek kell elsőbbséget adni, és minek nem.
Hanem a jó sorrend. A böngészőnek először azt kell megkapnia, amire a látogatónak valóban szüksége van.
Mi történik az Edge mögött?
A weboldalak egyre több esetben használnak CDN-eket és edge infrastruktúrát, hogy bizonyos tartalmakat és feldolgozási feladatokat a felhasználóhoz földrajzilag közelebb lehessen kiszolgálni.
Az Edge azonban nem azt jelenti, hogy a klasszikus szerverek eltűntek. Inkább arról van szó, hogy a webalkalmazás egyes részei közelebb kerülhetnek a felhasználóhoz, miközben a háttérben továbbra is működhetnek központi adatbázisok és szerverek.
Ez különösen akkor lehet hasznos, amikor sok statikus tartalmat, gyorsítótárazott választ vagy földrajzilag érzékeny kérést kell kiszolgálni.
Egy átlagos magyar kisvállalkozói WordPress-weboldal esetében azonban nem feltétlenül az edge futtatás lesz az első és legfontosabb optimalizáció. Sokkal nagyobb eredményt hozhat a képek, a JavaScript, a cache, a CDN és a felesleges pluginok rendbetétele.
A böngésző már a következő oldalt is előkészítheti
Az igazán érdekes irány az, amikor a rendszer nem csak azt tölti be, amit a látogató már kért, hanem megpróbálja előre megjósolni, mi lehet a következő lépése.
Ennek egyik egyszerűbb formája az előzetes betöltés. Ha egy weboldal nagy valószínűséggel képes felismerni, hogy a következő navigáció például egy termékoldal vagy egy pénztár lehet, akkor a megfelelő erőforrásokat már korábban elkezdheti előkészíteni.
A modern böngészőkben ehhez már léteznek olyan mechanizmusok, mint a Speculation Rules API, amelyek bizonyos navigációk előzetes betöltését vagy előre renderelését is lehetővé teszik. Ez nem mesterséges intelligencia, hanem szabályalapú spekuláció. 2026-ban elsősorban a Chromium-alapú böngészőkben érhető el megbízhatóan.
A lényeg az, hogy a rendszer ne akkor kezdjen gondolkodni, amikor a látogató már kattintott.
Egy jó pincér nem várja meg, amíg kimondod, hogy szeretnél még egy pohár vizet, ha már látja, hogy elfogyott.
A jó weboldal sem feltétlenül várja meg a kattintást, ha biztonságosan és ésszerűen előre sejthető, mi lesz a következő lépés.
A JavaScriptből is könnyű túl sokat használni
Az elmúlt években rengeteg weboldal vált egyre összetettebbé. Több plugin, több script, több animáció, több külső szolgáltatás és több interaktív elem került ugyanarra az oldalra.
A probléma nem az, hogy a JavaScript rossz. A probléma az, amikor olyan munkát végez a böngészőben, amelyre valójában nincs szükség.
Egy modern weboldalnak nem kell minden elemét ugyanúgy JavaScriptből működtetnie. Ahol lehet, érdemes a böngésző natív képességeire, egyszerű HTML-re és CSS-re támaszkodni, és csak ott használni összetett JavaScriptet, ahol valódi felhasználói értéket ad.
Bizonyos modern architektúrák, például az Islands Architecture is ezt a gondolkodást követik: az oldal nagy része lehet statikus vagy szerverről érkező HTML, miközben csak a valóban interaktív részek kapnak kliensoldali JavaScriptet.
Egy weboldalon könnyű újabb és újabb funkciókat hozzáadni. Sokkal nehezebb megkérdezni, hogy valamire tényleg szükség van-e.
A Core Web Vitals és különösen az INP szempontjából a felesleges JavaScript, a régi marketingkódok, a túl sok plugin és a nehéz widgetek valódi teljesítményproblémát jelenthetnek.
Early Hints: amikor a szerver előre szól a böngészőnek
A web teljesítményének egyik érdekes technikai eszköze a HTTP 103 Early Hints.
Ennek az a lényege, hogy a szerver már a végleges válasz elkészülése előtt jelezheti a böngészőnek, milyen erőforrásokra lehet szükség. Így bizonyos fájlok letöltése vagy egy kapcsolat előkészítése hamarabb elkezdődhet.
Ez nem minden weboldalon lesz látványos gyorsulás. Akkor érdemes vele foglalkozni, ha a szerver és az infrastruktúra valóban profitál belőle. A lényeg ugyanaz, mint a többi teljesítménytechnikánál: először mérünk, utána optimalizálunk.
A sebesség nem csak technikai kérdés
Egy gyors weboldal nemcsak kellemesebb használni. Kevesebb adatot fogyaszt, kevésbé terheli a gyengébb eszközöket, és több ember számára teszi használhatóvá az információt.
Ez különösen fontos mobilon. Nem minden látogatód rendelkezik csúcskategóriás telefonnal, gyors Wi-Fi-vel vagy erős asztali géppel.
Egy olyan oldal, amely csak erős hardveren működik jól, valójában nem optimalizált. A jó weboldalnak nem a fejlesztő gépén kell gyorsnak lennie, hanem a valódi látogató valódi eszközén és hálózatán.
Ne azt kérdezd, hogy nálad gyors-e az oldal. Azt kérdezd, hogy a látogatódnál gyorsnak érződik-e.
8 dolog, amit most ellenőrizhetsz a saját weboldaladon
srcset és sizes segíthet abban, hogy a böngésző a megfelelő képméretet töltse le.
Egy egyszerű teszt, amit most azonnal elvégezhetsz
Nyisd meg a weboldaladat egy telefonon, lehetőleg mobilhálózaton.
Ne a PageSpeed pontszámot nézd először.
Csak figyeld meg azt a pillanatot, amikor először azt érzed: „most már használhatom.”
Mikor jelenik meg a fő tartalom? Mikor tudsz görgetni? Mikor működik a menü? Mikor reagál a gomb? Mikor áll meg végleg a layout?
Ha ezekre a kérdésekre sokáig kell várni, akkor a weboldalad valószínűleg nem csak egy szám alapján lassú. Felhasználói élményként is lassúnak érződik.
Amit nem kell megtenned a gyorsabb weboldalért
Minden új technológiai trendet rátenni az oldalra csak azért, mert gyorsnak hangzik.
Az Edge, a preload, a prefetch, a Web Worker vagy egy új JavaScript-architektúra nem automatikus teljesítményjavítás.
Kevesebb felesleges kód, megfelelően méretezett képek, jó cache-elés, ésszerű pluginhasználat és helyesen priorizált erőforrások.
Először azokat javítsd, amelyek valóban hatással vannak a felhasználói élményre.
A leggyorsabb weboldal sokszor az, amelyik a legkevesebbet csinál
2026-ban nem az nyer, akinek a weboldalán van a legtöbb animáció, a legtöbb JavaScript vagy a leglátványosabb technológia.
Hanem az, amelyik a lehető legkevesebb felesleges munkát végezteti el a böngészővel, és a lehető leggyorsabban adja át azt, amire a látogatónak szüksége van.
A jó teljesítmény tehát nem egyetlen trükkből áll.
Korrekt képek. Ésszerű JavaScript. Jó szerver és cache. Tudatos erőforrás-prioritás. Megfelelő CDN. Stabil layout. Gyors interakciók.
Ezek együtt adják azt az érzést, amit a látogató egyszerűen csak így fogalmaz meg:
És talán ez a legjobb teljesítményteszt.
A technológia a háttérben marad. A látogató pedig egyszerűen halad a célja felé.
A weboldalad gyorsnak érződik, vagy csak annak kellene lennie?
A sebességet nem érdemes egyetlen PageSpeed-pontszámból megítélni. Meg kell nézni, hogyan töltődik be az oldal, hogyan reagál a látogató műveleteire, és hol veszít időt a böngésző.
Ha szeretnéd megtudni, hol vannak a saját weboldaladon a felesleges lassulások és teljesítményproblémák, érdemes egy külső szemmel is átnézni.
Kérem az auditot!
