A weboldal sebessége 2026 őszén: ami már nem elég és ami tényleg számít

A weboldal sebessége 2026 őszén már nem az a téma, amelyet a fejlesztő egyszer letudott az átadáskor, aztán mindenki elfelejtette. A Google web.dev oldala szerint a Core Web Vitals három mérőszáma és azok küszöbértékei ugyan nem változtak, a Chrome 149-es és 150-es kiadásai viszont olyan eszközöket hoztak, amelyekkel sok korábbi JavaScript-trükk kiváltható, a Next.js 16.3 pedig fejlesztés közben akár 90%-kal kevesebb memóriát használ. Közben az AI-alapú keresési felületek miatt kevesebb kattintás érkezik, így minden látogató többet ér, egy lassú oldal pedig pont őket riasztja el.

A jó hír az, hogy a sebesség mérhető, tehát számon is kérhető. A folytatásban 2026. szeptember 22-i állapot szerint végigvesszük, mit mér ma pontosan a Google, miért nem látszik a görgetés a hivatalos számokban, mit érdemes kezdeni a képekkel és a betűtípusokkal (a magyar ő és ű betűkkel együtt), melyik keretrendszer mire való, végül kapsz egy ellenőrzőlistát is, amelyet fejlesztő nélkül, egy kávé mellett végig tudsz menni.

Röviden

• A Core Web Vitals 2026-ban is három mérőszámból áll: a betöltést mérő LCP legfeljebb 2,5 másodperc, a reakcióidőt mérő INP legfeljebb 200 ezredmásodperc, a vizuális stabilitást mérő CLS legfeljebb 0,1 lehet a látogatások 75. percentilisén.
• A HTTP Archive 2025-ös Web Almanac jelentése szerint a weboldalaknak mobilon mindössze 48%-a teljesíti mindhárom küszöböt (asztali gépen 56%-a), vagyis egy jól beállított oldal még mindig előnyt jelent.
• A görgetés simaságát a Core Web Vitals nem méri, mert a web.dev leírása szerint az INP a görgetést kifejezetten kihagyja, ezért itt a saját telefonos teszted és a görgetéshez kötött JavaScript CSS-re cserélése számít.
• A mobilos oldalak 76%-ánál egy kép a legnagyobb tartalmi elem, így a leggyorsabb javulást általában a nyitókép átméretezése, modern formátuma és helyes betöltési prioritása hozza, nem egy újabb gyorsítóbővítmény.
• Keretrendszer-választásnál a WordPress a legtöbb KKV-nak továbbra is megfelel, ha könnyű a téma és kevés a bővítmény, a Next.js webalkalmazásokhoz, az Astro tartalomközpontú oldalakhoz, a statikus HTML pedig néhány oldalas bemutatkozó- és kampányoldalakhoz ideális.
• A Lighthouse-féle 100 pont önmagában már nem elég, mert a Google a valódi látogatóktól gyűjtött terepi adatot nézi, ezért havonta érdemes a PageSpeed Insightsban és a Search Console-ban is ránézni a számokra.

Miért számít a weboldal sebessége 2026 őszén is?

A Google a Core Web Vitals mérőszámait olyan jelzésként kezeli, amely összhangban van azzal, amit a rangsorolási rendszerei jutalmazni akarnak, a lassú oldal pedig pont azokat a látogatókat veszíti el, akik az AI-válaszok korában még egyáltalán rákattintanak. A sebesség emellett pénz is, mert a hirdetési céloldal minőségét és a vásárlási arányt is befolyásolja.

A Google Search Central 2025. december 10-én frissített dokumentációja szerint a Core Web Vitals azt méri, amit a Google alapvető rangsorolási rendszerei is jutalmazni igyekeznek, ezért a cég azt javasolja az oldaltulajdonosoknak, hogy érjenek el jó értékeket, ha sikeresek akarnak lenni a keresésben. Ezt a mondatot józanul érdemes olvasni, mert a sebesség nem varázspálca: egy lassabb, de pontosan a keresett kérdésre válaszoló oldal megelőzheti a villámgyors, de semmitmondó konkurenst. Hasonló minőségű tartalmak között viszont a jobb felhasználói élmény billentheti el a mérleget, a gyenge mobilos élmény pedig olyan hátrány, amelyet a legjobb szöveg sem tud teljesen ellensúlyozni.

A második ok a keresési felületek átalakulása: a Numinix 2026. szeptemberi SEO-összesítése szerint a Google AI Overviews augusztus vége óta dinamikusan bővül és egyre inkább az AI Mode-ra hasonlít, az organikus találatok pedig lejjebb csúsznak. Az AI Overviews havi aktív felhasználóinak száma az összesítés szerint 2,5 milliárd, az AI Mode-é több mint 1 milliárd. Kevesebb kattintásnál minden látogató értékesebb, aki pedig a telefonján négy másodpercig üres képernyőt néz, jó eséllyel visszalép és inkább az AI-választ vagy a következő találatot választja.

A fizetett hirdetéseknél ugyanez még közvetlenebbül látszik, hiszen a Google Ads minőségi mutatója (Quality Score) három összetevőből áll: a várható átkattintási arányból, a hirdetés relevanciájából és a céloldali élményből. A céloldali élményben a gyorsan betöltő, mobilon is kényelmesen használható oldal számít, így egy lassú landing page (az a céloldal, ahová a hirdetés visz) ronthatja a minőségi mutatót, ami drágább kattintásokhoz és gyengébb hirdetési pozícióhoz vezethet. Magyarán a lassú oldalért kétszer fizetsz: egyszer a drágább kattintással, egyszer pedig azokkal a látogatókkal, akik a betöltés előtt feladják.

Van egy harmadik, üzleti szempontból talán legfontosabb ok is: a sebesség mérhető, tehát számonkérhető. Aki 2026-ban weboldalt rendel vagy üzemeltet, konkrét célértékeket írhat a szerződésbe, a fejlesztő pedig havonta igazolhatja, hogy az oldal tartja őket.

Mik a Core Web Vitals mérőszámai és küszöbértékei 2026-ban?

A Core Web Vitals 2026-ban is három mérőszámból áll: az LCP a betöltést, az INP a reakcióidőt, a CLS a vizuális stabilitást méri. A web.dev szerint jó érték a legfeljebb 2,5 másodperces LCP, a legfeljebb 200 ezredmásodperces INP és a legfeljebb 0,1-es CLS, a látogatások 75. percentilisén mérve.

A Core Web Vitals a Google által meghatározott mérőszámcsomag, amely valódi látogatói adatok alapján értékeli egy weboldal felhasználói élményét. A web.dev hivatalos Web Vitals oldala 2026 szeptemberében is ugyanazt a három stabil mérőszámot és ugyanazokat a küszöbértékeket közli, az oldal utolsó frissítése 2024. október 31-i. A hármas összetétele 2024 márciusa óta változatlan, amikor az INP felváltotta a korábbi FID mérőszámot. Ha tehát egy blogon azt olvasod, hogy „2026-ban szigorodtak a küszöbök”, azt érdemes fenntartással kezelni, mert a hivatalos forrás mást mond.

Az LCP (Largest Contentful Paint, a legnagyobb tartalmi elem megjelenése) azt méri, mennyi idő alatt jelenik meg a képernyő látható részén a legnagyobb kép vagy szövegblokk, ami a legtöbb oldalon a nyitókép vagy a főcím. Az INP (Interaction to Next Paint, a következő kirajzolásig eltelt idő) azt méri, mennyit kell várni egy kattintás, koppintás vagy billentyűleütés után, amíg az oldal láthatóan reagál. A mérés a teljes látogatás interakcióit figyeli, nem csak az elsőt, a végső érték pedig nagyjából a leglassabb reakciót tükrözi. A CLS (Cumulative Layout Shift, halmozott elrendezés-elcsúszás) azt méri, mennyire ugrál a tartalom betöltés közben, például amikor egy későn érkező sáv lejjebb tolja azt a gombot, amelyre épp rá akartál koppintani.

A 75. percentilis azt jelenti, hogy a látogatások legalább háromnegyedének a küszöb alatt kell maradnia ahhoz, hogy az oldal az adott mérőszámon jó minősítést kapjon. Ez szándékosan szigorú mérce, mert nem az számít, milyen gyors az oldal a fejlesztő új laptopján, hanem az, hogy a régebbi telefonon, gyengébb mobilneten böngésző látogatók túlnyomó része is elfogadható élményt kap-e.

A HTTP Archive Web Almanac jelentésének 2025-ös teljesítményfejezete, amely a 2025. júliusi méréseken alapul, azt találta, hogy mobilon az oldalak 48%-a, asztali gépen 56%-a teljesíti mindhárom Core Web Vitals küszöböt, szemben az egy évvel korábbi 44%-kal és 55%-kal. Mérőszámonként mobilon az oldalak 62%-a jó LCP-ben, 77%-a INP-ben és 81%-a CLS-ben, asztali gépen ugyanez 74%, 97% és 72%.

Egy magyar KKV számára ebből főleg az következik, hogy mobilon az LCP a leggyengébb láncszem, vagyis a legtöbb oldal túl lassan mutatja meg a fő tartalmát, az INP 20 százalékpontos mobilos lemaradása pedig arra utal, hogy a gyengébb telefonok nehezen birkóznak meg a sok JavaScripttel.

Terepi adat vagy laboradat: melyik számít?

A terepi adat (field data) valódi látogatók böngészőjéből származik, a Google ezt a Chrome User Experience Report (CrUX) nevű adatbázisban gyűjti azoktól a Chrome-felhasználóktól, akik hozzájárultak a statisztikák küldéséhez. A PageSpeed Insights felső blokkja ezt mutatja az előző 28 nap összesítéseként. A laboradat ezzel szemben szimulált mérés, amelyet a Lighthouse nevű eszköz egy előre beállított, lassított telefonon és hálózaton futtat le: ebből jön a sokat emlegetett 0 és 100 közötti pontszám.

A Core Web Vitals értékelése a terepi adaton alapul, a laboradat inkább a hibakeresést segíti, mert megmutatja, melyik kép, szkript vagy betűtípus okozza a lassúságot. Kisebb forgalmú magyar oldalaknál gyakori, hogy a CrUX-ban nincs elég adat, ilyenkor a laboreredmény és a saját, valódi telefonon végzett teszted marad a támpont.

Hogyan mérjük a görgetést, ha a Core Web Vitals nem látja?

A Core Web Vitals a görgetés simaságát nem méri: a web.dev INP-leírása kifejezetten rögzíti, hogy a rámutatás, a nagyítás és a görgetés nem számít bele az INP-be. A görgetést ezért saját telefonos teszttel, fejlesztői eszközökkel és a görgetéshez kötött JavaScript visszanyesésével érdemes kézben tartani.

Ez elsőre meglepő, hiszen a látogató egy mobiloldalon az ideje nagy részében görget, nem kattint. A Google persze nem hanyagolja el a témát, csak máshol foglalkozik vele. Petr Čermák, a Chrome szoftvermérnöke 2026. július 23-án a Google blogján leírta, hogyan csökkentették az androidos Chrome-ban a szaggatott görgetéseket, amelyek 2023 és 2026 között 48%-kal lettek ritkábbak. Szaggatott görgetésnek (janky scroll) azt tekintik, amikor a képernyő egy teljes frissítési cikluson át elavult görgetési pozíciót mutat, vagyis az ujjad már továbbment, a kép viszont egy pillanatra megakad.

A szerző saját fordításunkban úgy fogalmazott, hogy a nyers sebesség önmagában nem garantálja a jó élményt, a valódi kulcs a következetesség. Ez a mérés azonban a Chrome belső mérőszáma, amely nem jelenik meg sem Web Vitalként, sem a CrUX-ban, sem a Search Console-ban. A böngésző tehát a saját oldalán sokat javított, a te weboldalad viszont könnyen visszarontja az élményt, ha a görgetéshez nehéz JavaScript kapcsolódik.

Mi rontja el a görgetést egy átlagos céges oldalon?

• Parallaxhatások és görgetésre induló animációk, amelyeket egy JavaScript-könyvtár számol újra minden egyes görgetési eseménynél.
• Ragadós (sticky) fejléc, amely görgetés közben átméreteződik, így a böngészőnek újra és újra ki kell számolnia az elrendezést.
• Görgetésfigyelő szkriptek (hőtérkép, olvasási mélység mérése, felugró ablak időzítése), amelyek a fő szálon futnak, így a kattintásokkal is versenyeznek.

Mit hozott a Chrome 146 és 150 között a görgetésben?

A Google I/O 2026 webes felületekről szóló összefoglalója (Bramus és Una Kravets, 2026. július 1.) több olyan CSS-funkciót sorol fel, amely korábban JavaScriptet igénylő görgetési mintákat vált ki. A görgetésre induló animációk (scroll-triggered animations) a Chrome 146-tól egy hagyományos, időalapú CSS-animációt indítanak el, amikor a látogató átgörget egy adott ponton. A scroll-state lekérdezések a Chrome 148-tól lehetővé teszik, hogy egy konténer görgetési állapota alapján változzon a stílus, így például a lefelé görgetéskor eltűnő, felfelé visszatérő fejléc szkript nélkül is megoldható. A Chrome 149-ben érkezett scroll-target-group pedig a görgetési pozíció alapján automatikusan kiemeli a navigációban az éppen olvasott szakasz linkjét, amit eddig szinte mindenhol JavaScript végzett.

Szintén a Chrome 149 újdonsága a görgetősáv-tudatos viewport-egység: ha a gyökérelemen állandó görgetősáv vagy fenntartott görgetősáv-hely (scrollbar-gutter) van beállítva, a vw egység automatikusan levonja a görgetősáv szélességét, így megszűnik az a klasszikus hiba, hogy egy teljes szélességű sáv miatt az oldal vízszintesen is elgördíthető. Minden, amit a böngésző natívan, CSS-ből intéz, lekerül a JavaScript fő száláról, amely így szabadabb marad a kattintások kiszolgálására, ez pedig az INP-n is meglátszik. A többi friss CSS-funkcióról és az oldalak közötti animált átmenetekről (View Transitions) külön cikkekben írtunk, itt csak a sebességet érintő részt emeltük ki.

A gyakorlatban a legjobb görgetésteszt egy két-három éves, középkategóriás androidos telefon. Görgesd végig a főoldalt és egy hosszabb aloldalt gyorsan, majd lassan, közben figyeld, hogy akad-e a kép, ugrál-e a szöveg és időben megjelennek-e a képek. A fejlesztő a Chrome fejlesztői eszközeinek Performance paneljével ennél pontosabban is látja, mi foglalta le a fő szálat görgetés közben.

Ami 2026-ban már nem elég a gyors weboldalhoz

Sok cégnél még mindig olyan rutinok élnek, amelyek öt éve rendben voltak, ma viszont hamis biztonságérzetet adnak: hasznosak, csak önmagukban kevesek.

• A Lighthouse-pontszám: egyetlen szimulált mérés egy előre beállított eszközön, a Core Web Vitals viszont a valódi látogatók 28 napos terepi adatán alapul, így egy 95 pontos oldal is elbukhat a valós méréseken, egy 70 pontos pedig átmehet.
• Asztali gépes, irodai wifis teszt: a mobilos eredmények rendszerint gyengébbek, sok KKV-oldalon pedig a forgalom nagyobb része telefonról érkezik.
• Egyszeri optimalizálás az átadáskor: minden új bővítmény, marketingpixel, csevegőablak vagy felugró ablak visszarontja az értékeket, ezért a sebesség üzemeltetési feladat, nem a projektzárás egyik pipája.
• Egyetlen gyorsítóbővítmény: a gyorsítótár (cache) a szerver válaszidején sokat javít, a túl sok JavaScript okozta lassú reakción (INP) és a méret nélküli képek okozta ugráláson (CLS) viszont semmit.
• A FID-korszak gondolkodása: a 2024 márciusáig használt First Input Delay csak az első interakció késését mérte, az INP viszont a látogatás összes kattintását figyeli, így egy később megnyitott menü vagy termékszűrő lassúsága is beleszámít.
• Drága, erős tárhely: a gyors szerver szükséges feltétel, de ha a böngészőnek utána több megabájtnyi JavaScriptet kell feldolgoznia egy gyengébb telefonon, a szerveren megspórolt idő a látogató oldalán elvész.

Külön érdemes szétválasztani a fejlesztői és a látogatói sebességet. A Next.js 2026. augusztus 3-án kiadott 16.3-as verziója fejlesztés közben akár 90%-kal kevesebb memóriát használ, a buildelés és a renderelés pedig gyorsabb lett. Ez a fejlesztőnek valódi előny, a látogató viszont nem a fejlesztőgép memóriáját érzékeli, hanem a letöltött képeket, betűtípusokat és szkripteket, így egy gyorsabb fejlesztői eszköz még nem jelent automatikusan gyorsabb weboldalt. Ha egy ajánlatban a keretrendszer sebességéről olvasol, kérdezz rá, hogy a fejlesztési vagy a látogatói oldalról beszélnek-e.

Hogyan optimalizáld a képeket, hogy ne a nyitókép rontsa el az LCP-t?

Úgy, hogy a nyitóképet a tényleges megjelenítési méretre vágod, modern formátumban (AVIF vagy WebP) szolgálod ki, nem töltöd lustán, magas betöltési prioritást adsz neki és minden képnek megadod a szélességét és a magasságát. Ez a néhány lépés a legtöbb KKV-oldalon többet hoz, mint bármilyen gyorsítóbővítmény.

A HTTP Archive Web Almanac 2025-ös teljesítményfejezete szerint a mobilos oldalak 76%-ánál, az asztali oldalak 85,3%-ánál egy kép a legnagyobb tartalmi elem. Az oldalak nagyjából 16 vagy 17 százaléka ráadásul pont ezt a képet tölti lustán, vagyis késlelteti azt, amit a látogatónak elsőként kellene látnia. A lusta betöltés (lazy loading) olyan technika, amely a képernyőn kívül eső képeket csak akkor tölti le, amikor a látogató a közelükbe görget, ezért a lejjebb lévő galériánál hasznos, a nyitóképnél viszont kifejezetten káros. A jelentés szerint a mobilos oldalak 62%-án, az asztaliak 65%-án legalább egy kép méretmegadás nélkül szerepel a kódban, ami elrendezés-ugráshoz, így rosszabb CLS-hez vezet.

Egy balatoni panzió nyitóképe számokban

Vegyünk egy képzeletbeli balatoni panziót, amelynek a főoldalán egy telefonnal fotózott, 4 000 képpont széles, 4,2 MB-os JPEG naplementekép fogadja a látogatót. Egy okostelefon képernyője CSS-ben nagyjából 400 képpont széles, háromszoros pixelsűrűséggel ez 1 200 fizikai képpontot jelent, a kép tehát a szükségesnél több mint háromszor szélesebb, területben pedig több mint tízszer nagyobb.

Tegyük fel, hogy a látogató mobilkapcsolata ténylegesen 10 Mbit/s-os letöltési sebességet ad. Egyszerűsített becslésünk szerint a 4,2 MB-os kép letöltése így nagyjából 3,4 másodperc (4,2 MB × 8 = 33,6 Mbit, osztva 10 Mbit/s-mal), ami egymagában elviszi a teljes 2,5 másodperces LCP-keretet, pedig a szerver válaszideje és a betűtípusok még hozzá sem adódtak. Ha ugyanezt a képet 1 200 képpont szélesre méretezed és AVIF formátumban mented, jellemzően néhány száz kilobájtos fájlt kapsz, egy 200 kB-os változat letöltése pedig ugyanazon a kapcsolaton 0,16 másodperc körül van. A számítás a hálózati késleltetést és a párhuzamos letöltéseket figyelmen kívül hagyja, a nagyságrendi különbség viszont valós. Ezt a hibát ráadásul gyakran maga a tulajdonos viszi be az oldalra, amikor a telefonjáról feltölt egy friss fotót.

A képoptimalizálás szabályai röviden

• Méretezd a képet a legnagyobb tényleges megjelenítési méretre, a különböző kijelzőkhöz pedig készíts több változatot, a srcset és a sizes attribútum segítségével a böngésző maga választja ki a megfelelőt.
• Használj AVIF vagy WebP formátumot, a JPEG maradjon tartaléknak, a PNG-t pedig csak átlátszó grafikákhoz, logókhoz tartsd meg.
• A nyitóképet soha ne töltsd lustán, helyette kapjon fetchpriority attribútumot high értékkel, hogy a böngésző elsőként kérje le.
• Minden képnek add meg a szélességét és a magasságát (vagy CSS-ben az aspect-ratio arányt), így a böngésző előre lefoglalja a helyét és nem ugrik a szöveg.
• A CSS-háttérképként beállított nyitóképet a böngésző későn fedezi fel, ezért ilyenkor előtöltéssel (preload) kell jelezni, vagy jobb esetben rendes képelemre cserélni.
• A körhinták (sliderek) helyett válassz egyetlen erős nyitóképet, mert a több képből álló, JavaScripttel vezérelt slider szinte mindig lassabb LCP-t és gyakran ugráló elrendezést ad.

A WordPress alapból több méretváltozatot készít a feltöltött képekből és megpróbálja felismerni, melyik a nyitókép, a nehezebb oldalépítő bővítmények (page builderek) és a háttérképként beállított fejlécek azonban gyakran kijátsszák ezt a logikát. Ne bízz tehát vakon a rendszerben, a PageSpeed Insights diagnosztikájában nézd meg, melyik elemet találja az eszköz LCP-elemnek.

Betűtípusok magyar ékezetekkel, text-box és text-fit

A betűtípus a képek mellett a másik gyakori rejtett fék, csak ritkábban veszik észre. Ha egy oldal négy betűcsaládot és családonként három vastagságot tölt be, az könnyen tizenkét külön fájl, amelyek vagy késleltetik a szöveg megjelenését, vagy menet közben lecserélik a betűket, ami a sorok elcsúszásával jár.

Miért lesz más az ő és az ű?

A magyar oldalak sajátos buktatója az ékezetkészlet: az ő és az ű betű nem az alap latin karakterkészletben, hanem a Latin Extended-A Unicode-blokkban található. Ha a fejlesztő a fájlméret csökkentése érdekében csak a latin részhalmazt (subsetet) tölti be, ezek a betűk tartalék betűtípussal jelennek meg. Az eredmény ismerős: a „tűzőgép” szóban az ű egy kicsit más, mint a többi betű, vastagabb vagy vékonyabb, esetleg el is csúszik az alapvonalról. A Google Fonts ezért külön latin-ext részhalmazt kínál, magyar oldalon ezt is be kell tölteni, lehetőleg csak a ténylegesen használt vastagságokban.

A legegyszerűbb ellenőrzés az „Árvíztűrő tükörfúrógép” mondat, amely az összes magyar ékezetes magánhangzót tartalmazza. Kérd meg a fejlesztőt, hogy tegye ki egy tesztoldalra a címsor és a szövegtörzs betűtípusával, majd nagyítva nézd meg, hogy minden betű ugyanabból a családból jön-e.

A betűtípusok gyors betöltése

• Legfeljebb két betűcsaládot használj, családonként két-három vastagsággal, vagy válassz egyetlen változó betűtípust (variable font), amely egy fájlban hordozza az összes vastagságot.
• A betűtípus WOFF2 formátumban, saját tárhelyről érkezzen, így a böngészőnek nem kell külön kapcsolatot nyitnia egy külső betűszerver felé.
• A font-display tulajdonság swap értékkel azonnal megjeleníti a szöveget tartalék betűvel, az optional érték pedig lassú kapcsolaton inkább a tartalék betűnél marad, így a szöveg nem ugrik meg.
• A tartalék betűtípus méreteit a size-adjust és az ascent-override tulajdonsággal az egyedi betűhöz lehet igazítani, így a csere pillanatában alig mozdul el a sor.
• A főcímhez használt egy-két betűfájlt érdemes előtöltéssel korán lekérni, de csak azt, mert a túl sok előtöltés a nyitóképtől veszi el a sávszélességet.

text-box: pontos igazítás trükközés nélkül

A text-box CSS-tulajdonság a Google I/O 2026 összefoglalója szerint levágja a szöveg feletti és alatti függőleges ráhagyást, így a szöveg pontosan igazítható és középre tehető. A gyakorlatban ez azt jelenti, hogy egy gomb felirata vagy egy kártya címe végre ott ül, ahol a tervező megrajzolta, ehhez pedig nem kell negatív margó, extra burkolóelem vagy betűtípusonként kikísérletezett térköz. A régebbi böngészők figyelmen kívül hagyják a tulajdonságot és a megszokott térközzel jelenítik meg a szöveget, így kockázat nélkül bevethető.

h1, .gomb {
  text-box: trim-both cap alphabetic;
}
.kampanycim {
  text-fit: grow per-line-all;
}

text-fit: a sorhoz igazodó betűméret, egyelőre kísérletként

A text-fit a Google összefoglalója szerint úgy skálázza a betűméretet, hogy a szöveg sorai pontosan kitöltsék az őket tartalmazó elem szélességét. Ezt eddig jellemzően JavaScripttel oldották meg: a szkript a betöltés után megmérte a szöveget, majd átméretezte, ami egy pillanatnyi ugrással és plusz munkával járt a fő szálon. A text-fit ma még kísérleti státuszú, ezért éles oldalon csak úgy használd, hogy nélküle is rendben legyen a megjelenés, a meglévő JavaScript-alapú megoldásokat pedig akkor cseréld le, amikor stabilan elérhetővé válik.

Ide tartozik a Chrome 150-ben megjelent text-scale nevű meta címke is, amellyel az oldal jelezheti, hogy a gyökérelem betűmérete kövesse az operációs rendszer és a böngésző szövegméret-beállítását. Ez akadálymentességi előrelépés, egyben figyelmeztetés is: ha a látogató nagyobb betűt kér, a dizájnnak szétesés nélkül kell alkalmazkodnia, ezért bekapcsolás előtt nézd meg az oldalt a telefon legnagyobb betűméret-beállításával is.

Külső szkriptek, sütibanner, csevegőablak: itt vész el az INP

A reakcióidő (INP) tapasztalatunk szerint a legtöbb KKV-oldalon nem a saját kódon, hanem a ráaggatott külső szolgáltatásokon bukik el. A Web Almanac szerint asztali gépen az oldalak 97%-ának jó az INP-je, mobilon csak 77%-ának, a különbség oka pedig jellemzően az, hogy egy gyengébb telefon processzora sokkal lassabban dolgozza fel ugyanazt a JavaScriptet, ezért a kattintásnak meg kell várnia, amíg a fő szál felszabadul.

Vegyünk egy képzeletbeli, 12 fős kecskeméti asztalosüzemet, amelynek a weboldalán az évek során összegyűlt a Google Címkekezelő, a Google Analytics 4, a Meta-képpont, egy csevegőablak, egy beágyazott Google-térkép, két YouTube-videó, a sütikezelő sáv, az ajánlatkérő űrlap reCAPTCHA-ellenőrzése és egy Instagram-hírfolyam bővítmény. Egyenként mindegyiknek megvolt az oka, együtt viszont egy olcsóbb telefonon másodpercekre lefoglalhatják a fő szálat, így a menüre koppintó látogató azt érzi, hogy az oldal „nem reagál”.

A megoldás nem az, hogy mindent kidobsz, hiszen a mérés és a hirdetésoptimalizálás nélkülük nem működik, a kérdés inkább az, hogy mi, mikor és hogyan töltődik be:

• Homlokzat (facade) technika: a YouTube-videó és a csevegőablak helyén először csak egy kép vagy gomb jelenik meg, a valódi szkript csak akkor töltődik be, amikor a látogató rákattint.
• A beágyazott térképet a kapcsolat oldalon egy statikus kép is kiválthatja, amely a Google Térképre mutató linkként működik.
• A Címkekezelőben évente legalább egyszer érdemes takarítani, mert a régi kampányok címkéi és a duplán beállított képpontok csendben tovább futnak.
• A reCAPTCHA csak azon az oldalon töltődjön be, ahol az űrlap van, ne az egész webhelyen.
• A sütikezelő sáv a tartalom felett lebegjen, ne tolja lejjebb a teljes oldalt, mert az utóbbi minden új látogatónál elrendezés-ugrást okoz.

Kevésbé ismert szempont a vissza-előre gyorsítótár (back/forward cache, röviden bfcache), vagyis az a böngészőfunkció, amely a Vissza gomb megnyomásakor azonnal, újratöltés nélkül adja vissza az előző oldalt. A Web Almanac szerint a mobilos oldalak 10%-a, a legnépszerűbb 1 000 webhely közül pedig mobilon 20%-a használ olyan unload eseménykezelőt, amely ezt a gyorsítótárat meghiúsíthatja. Ilyen kódot jellemzően egy régebbi bővítmény vagy mérőszkript hoz magával, a fejlesztő pedig a Chrome fejlesztői eszközeiben néhány perc alatt megnézheti, hogy az oldal alkalmas-e a bfcache-re.

Szerver és tárhely: a TTFB az LCP alapja

A TTFB (Time to First Byte, az első bájtig eltelt idő) azt méri, mennyi idő telik el a kérés elküldése és a szerver válaszának első bájtja között. Nem tartozik a Core Web Vitals hármasába, a weboldal sebességének mégis ez az alapja, hiszen amíg a HTML meg nem érkezik, a böngésző sem képet, sem betűtípust nem kezdhet letölteni. A web.dev iránymutatása szerint a TTFB-t érdemes 0,8 másodperc alatt tartani, ennél lassabb szervernél a 2,5 másodperces LCP-keret több mint harmada már az első bájtra ráment.

WordPress-oldalaknál a lassú TTFB tipikus okai: nincs oldalszintű gyorsítótár, így minden látogatásnál újra lefut az összes PHP-kód és adatbázis-lekérdezés, a PHP verziója elavult, az adatbázis tele van évek óta felhalmozott revíziókkal és ideiglenes adatokkal, a tárhely pedig egy túlzsúfolt osztott szerveren fut. A PHP-verzió a biztonság miatt is sürgető kérdés: a WooCommerce a 11.5-ös verziótól, 2027 januárjától már nem támogatja a PHP 7.4-et és a 8.0-t, erről külön cikkben írtunk.

A szerver földrajzi helye sem mellékes: egy magyar közönségnek szóló oldalnál egy magyarországi vagy közeli európai adatközpont rövidebb hálózati utat jelent, mint egy tengerentúli szerver. A képeket és a statikus fájlokat emellett egy tartalomkézbesítő hálózat (CDN) is kiszolgálhatja, vagyis egy olyan szerverhálózat, amely a fájlok másolatait több földrajzi ponton tárolja és mindig a látogatóhoz legközelebbiről küldi.

A legtöbb KKV-nak nem a legdrágább tárhelycsomag kell, hanem olyan szolgáltató, amely naprakész PHP-verziót, oldalszintű gyorsítótárat, HTTP/2 vagy HTTP/3 támogatást és Brotli- vagy gzip-tömörítést ad. Ha a PageSpeed Insights tartósan lassú szerverválaszt jelez, először ezeket kérdezd meg a szolgáltatótól, a nagyobb csomagon csak utána gondolkodj.

WordPress, Next.js, Astro vagy statikus oldal: melyik a leggyorsabb választás?

Önmagában egyik sem gyors vagy lassú: a statikus oldal és az Astro alapból a legkevesebb JavaScriptet küldi a böngészőnek, a Next.js webalkalmazásokhoz ideális, a WordPress pedig jól beállítva a legtöbb KKV-nak bőven elég gyors. A választásnál az számít, ki szerkeszti az oldalt, milyen gyakran és mennyi interaktív funkció kell.

WordPress: gyors lehet, ha nem terheled túl

A WordPress a KKV-oldalak egyik legelterjedtebb motorja, mert a marketinges maga is szerkesztheti. A sebessége jórészt a témán, az oldalépítőn és a bővítmények számán múlik: egy könnyű blokktémával épített oldal kényelmesen hozza a jó Core Web Vitals értékeket, egy nehéz oldalépítővel és harminc bővítménnyel összerakott oldal viszont ritkán.

A WordPress 6.8 óta a rendszer alapból spekulatív betöltést használ. A spekulatív betöltés olyan böngészőfunkció, amely a következő oldalt már azelőtt elkezdi letölteni, hogy a látogató ténylegesen megérkezne rá. Felix Arntz 2025. március 6-i bejelentése szerint a WordPress előtöltést (prefetch) alkalmaz óvatos (conservative) beállítással, vagyis akkor indul a letöltés, amikor a látogató elkezd rákattintani egy linkre. A funkció bejelentkezett felhasználóknál nem működik, ahogy azokon az oldalakon sem, ahol ki vannak kapcsolva a keresőbarát állandó hivatkozások (permalinkek). A korábbi bővítményváltozatot használó oldalaknál a medián LCP nagyjából 1,9%-kal javult, ami egyetlen ingyenes funkciótól tisztességes eredmény.

A frissítési fegyelem is a képlet része, hiszen egy elhanyagolt oldal előbb-utóbb nemcsak lassú, hanem sérülékeny is lesz: a 2026. szeptember 17-én kiadott WordPress 7.1.1 tizenegy biztonsági hibát javított, erről külön cikkben írtunk.

Next.js: webalkalmazásokhoz, fejlesztői háttérrel

A Next.js a React-alapú webalkalmazások egyik legnépszerűbb keretrendszere. A 2026. augusztus 3-án kiadott 16.3-as verzió a fejlesztői memóriahasználat csökkentése mellett Instant Navigations néven olyan eszközöket hozott, amelyek egyoldalas alkalmazásokhoz hasonló, azonnali reakciót adnak az oldalváltásoknál, a kliensoldali állapot megőrzésével. Ügyfélportálhoz, bejelentkezős felülethez, sok egyedi logikát igénylő webshophoz jó választás.

Az érme másik oldala a karbantartás: a Next.js blogja szerint 2026. augusztus 25-én két kritikus sérülékenység miatt jelent meg a 16.3.3 és a 15.5.24, szeptember 22-én pedig egy külső függőség hibája miatt soron kívüli kritikus frissítés érkezett (16.3.6 és 15.5.26). Egy Next.js-oldal mögé tehát folyamatosan elérhető fejlesztői háttér kell, egy ötoldalas bemutatkozó oldalhoz ezért általában túlméretezett.

Astro: tartalomközpontú oldalakhoz

Az Astro tartalomközpontú weboldalakra készült nyílt forráskódú keretrendszer, amely alapból kész HTML-t küld a böngészőnek, JavaScriptet pedig csak azokhoz az interaktív részekhez tölt be, amelyeknek tényleg szükségük van rá. Az Astrót fejlesztő cég 2026. január 16-án jelentette be, hogy a Cloudflare-hez csatlakozik, a bejelentés szerint a keretrendszer ingyenes, nyílt forráskódú és MIT-licencű marad, a Cloudflare mellett pedig továbbra is sokféle tárhelyre telepíthető. Blogokhoz, marketingoldalakhoz kiváló, a marketinges kényelmes szerkesztéséhez viszont külön tartalomkezelő (headless CMS) kell, ami plusz rendszert és költséget jelent.

Statikus oldal: kevés oldal, ritka változás

A statikus oldal adatbázis és szerveroldali kód nélküli, előre elkészített HTML- és CSS-fájlokból áll, így a leggyorsabb, a legolcsóbban üzemeltethető és a legkisebb támadási felületű megoldás. Tegyük fel, hogy egy budapesti könyvelőiroda háromoldalas bemutatkozó oldalán évente kétszer változik valami: ide tökéletes, egy hetente bővülő bloghoz viszont nem, mert minden módosítás fejlesztői munka.

Röviden a döntési logika: ha havonta többször szerkesztesz és nincs saját fejlesztőd, maradj a WordPressnél egy könnyű témával. Ha felhasználói fiókok, egyedi üzleti logika és integrációk kellenek, a Next.js a jobb alap. Ha sok a tartalom, kiemelt a sebesség és van fejlesztői háttér, nézd meg az Astrót. Néhány ritkán változó oldalhoz pedig a statikus HTML a legésszerűbb. A Webflow külön kategória, a 2026 augusztusában megszűnt régi szerkesztőjéről és az új irányairól egy másik cikkben írtunk.

Mennyit ér forintban egy gyorsabb weboldal?

Ez a forgalmadon és a konverziós arányodon múlik: egy havi több tízezer látogatós webshopnál már a konverzió egytized százalékpontos javulása is havi százezres nagyságrendű árrést hozhat, egy havi néhány száz látogatós bemutatkozó oldalnál viszont a jó sáv elérése után a további gyorsítás ritkán térül meg.

Vegyünk egy képzeletbeli debreceni webshopot havi 30 000 látogatással, 1,4%-os konverziós aránnyal és 16 000 Ft-os átlagos kosárértékkel. Tegyük fel, hogy a weboldal sebességének javítása után a konverzió 1,5%-ra nő. Ez nem garantált eredmény, hanem egy óvatos feltételezés, amellyel megmutatjuk, mekkora téttel számolsz.

A plusz 30 rendelés havi 480 000 Ft többletbevétel, ebből 30%-os árréssel 144 000 Ft marad. Ha a gyorsítás 30 fejlesztői órát igényel, óránként 10 000 Ft-tal számolva a 300 000 Ft-os ráfordítás valamivel több mint két hónap alatt megtérül, egy év alatt pedig 1 728 000 Ft többletárrést hozhat. A valós hatást mindig mérd: jegyezd fel a konverziós arányt a módosítás előtt és után, a szezonális ingadozást pedig vesd össze az előző év azonos időszakával.

A fizetett forgalomnál egyszerűbb a számolás: ha havi 150 000 Ft-ot költesz Google Ads-kattintásokra, a fizetett látogatók tizede pedig feltételezésünk szerint a betöltés előtt feladja, havonta nagyjából 15 000 Ft-nyi kattintás ég el haszon nélkül, a minőségi mutatóra gyakorolt hatásról nem is beszélve.

A fordított eset legalább ilyen tanulságos: egy havi 600 látogatós, telefonos érdeklődésekből élő bemutatkozó oldalnál, amely már jó Core Web Vitals értékeket mutat, a Lighthouse-pontszám 85-ről 100-ra tornázása több fejlesztői órába kerülhet, mérhető üzleti hatása viszont valószínűleg nem lesz. Itt a cél a jó sáv elérése és megtartása, nem a pontvadászat.

Ellenőrzőlista, amelyet egy nem fejlesztő is végig tud menni

A weboldal sebességének ellenőrzéséhez egy laptop, egy telefon, a Search Console-hozzáférés és nagyjából egy óra kell, kódot viszont nem kell olvasnod.

• Nyisd meg a PageSpeed Insightsot. Írd be a főoldalad címét, majd a mobil nézetben nézd meg a lap tetején a valódi felhasználói adatokat mutató blokkot. Ha ott mindhárom mérőszám zöld, az oldal a Google szemében jó, a lenti pontszám ennél kevésbé fontos.
• Ismételd meg a legfontosabb aloldalakkal. A főoldal mellett mérd le a legforgalmasabb termék- vagy szolgáltatásoldalt, a kapcsolat oldalt és a hirdetések céloldalát, mert ezek eltérhetnek egymástól.
• Nézd meg a Search Console Core Web Vitals jelentését. A bal oldali menü felhasználói élményről szóló részében látod, hány URL jó, javítandó vagy gyenge, mobilon és asztali gépen külön. Ha nincs elég adat, azt is jelzi.
• Teszteld a saját telefonodon mobilnetről. Kapcsold ki a wifit, nyisd meg az oldalt, majd számold meg, hány másodperc múlva jelenik meg a nyitókép és a főcím. Koppints a menüre, egy szűrőre és egy gombra, közben figyeld, azonnal reagál-e.
• Görgess végig egy hosszabb oldalt. Figyeld, akad-e a görgetés, ugrál-e a szöveg és beugranak-e a képek vagy a hirdetési sávok.
• Nézd meg a képeket. A PageSpeed Insights diagnosztikájában keresd a képekkel kapcsolatos figyelmeztetéseket, majd ellenőrizd, melyik elem az LCP-elem. Ha az egy több megabájtos fotó, megvan az első feladat.
• Írd össze a külső szolgáltatásokat. Kérdezd meg a marketingest és a fejlesztőt, milyen képpontok, csevegőablakok, térképek, videók és bővítmények futnak az oldalon, közülük pedig melyikre van még ténylegesen szükség.
• Ellenőrizd a betűket. Írd be az „Árvíztűrő tükörfúrógép” mondatot egy keresőmezőbe vagy nézz meg nagyítva egy ő és ű betűs címsort, közben figyeld, hogy minden betű ugyanabból a családból jön-e.
• Kérdezz rá a frissítésekre és a tárhelyre. Milyen verziójú a WordPress vagy a keretrendszer, mikor volt az utolsó frissítés, milyen PHP-verzió fut, van-e oldalszintű gyorsítótár.
• Rögzítsd a számokat. Vezess egy egyszerű táblázatot havonta a három mérőszámmal és a konverziós aránnyal, így látni fogod, ha egy új bővítmény vagy kampány visszarontja az értékeket.

Mit kérj számon a fejlesztőtől, hogy a sebesség tartós maradjon?

Kérj írásban rögzített célértékeket (mobilon, a 75. percentilisen legfeljebb 2,5 másodperces LCP, 200 ezredmásodperces INP és 0,1-es CLS), havi riportot a terepi adatokról, új bővítmény vagy szkript előtti egyeztetést és határidőt a biztonsági frissítésekre. Így a sebesség üzemeltetési vállalás lesz, nem egyszeri ígéret.

Sokat segít a teljesítménykeret (performance budget) is, amely egy előre rögzített felső határ: megszabja, mekkora lehet egy oldal összsúlya, mennyi JavaScriptet tölthet be és mennyi idő alatt kell megjelennie. Ha egy új funkció vagy kampányelem túllépné a keretet, a fejlesztő jelez, utána pedig közösen döntötök, mit hagytok el helyette. Ez a legegyszerűbb védekezés a lassú, apránként összegyűlő romlás ellen.

Hogy a weboldal sebessége tartós maradjon, a szerződésben vagy a support-megállapodásban három dolog legyen benne: minden nagyobb frissítés újramérése élesítés előtt, a biztonsági frissítésekre vállalt reakcióidő, valamint a képek és betűtípusok automatikus optimalizálása, hogy ne a tartalomfeltöltőn múljon a sebesség. A szeptemberi WordPress- és Next.js-javítások megmutatták, hogy a biztonsági frissítések napokon belül érkeznek, a december 8. és 10. között várható WordPress 7.2 pedig újabb mérést tesz indokolttá. Arról, hogy egy új weboldal átadásakor még mit érdemes számon kérni az ügynökségtől, külön ellenőrzőlistát is készítettünk.

Miben segít a Convergo?

A Convergónál a weboldal sebességét nem egyszeri pontvadászatként, hanem üzemeltetési feladatként kezeljük. Webdesign és weboldalkészítés szolgáltatásunkban eleve rögzített Core Web Vitals célértékekkel, optimalizált képekkel és a magyar ékezetekre is felkészített betűtípusokkal építünk, legyen szó WordPressről vagy egyedi fejlesztésről. Meglévő oldalaknál a support, üzemeltetés és tárhely csomagunk (30 000 Ft/hó, benne 3 fejlesztői órával) fedezi a rendszeres frissítéseket, a havi mérést és a kisebb javításokat, a SEO és keresési láthatóság szolgáltatásunkkal pedig a sebességet a keresési eredményekkel is összekötjük. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük az oldalad jelenlegi mérési adatait és a legfontosabb teendőket.