Gyors weboldal: miért számít, és hogyan mérd? A Core Web Vitals érthetően
„Lassú az oldalam?” — erre a kérdésre ma ingyenes és pontos válasz kapható. Közérthetően elmagyarázzuk, mit mér a Google, hol vannak a jó értékek határai, hogyan mérheted meg saját magad öt perc alatt, és mi lassítja a legtöbb weboldalt.
Ez a cikk magyar nyelvű.

Miért számít a sebesség?
Először is a látogatók miatt. Aki egy lassan betöltődő oldalon vár, könnyen visszalép a találati listára, és a következő vállalkozást nézi meg. A forgalom nagyobb része ráadásul mobilról érkezik — a StatCounter adatai szerint 2026 szeptemberében a magyarországi oldalmegtekintések 56,27%-a —, mobilon pedig, változó minőségű hálózaton, minden felesleges kilobájt érződik.
Másodszor a Google miatt. A Google az oldalak mobilos változatát használja az indexeléshez és a rangsoroláshoz, és a saját dokumentációja szerint a Core Web Vitals mutatókat a rangsoroló rendszerei is felhasználják. Fontos azonban a teljes kép: ugyanez a dokumentáció hangsúlyozza, hogy a Google mindig a legrelevánsabb tartalmat igyekszik megmutatni, akkor is, ha az oldal élménye nem tökéletes, és hogy a jó mutatók önmagukban nem garantálnak előkelő helyezést. A sebesség tehát nem helyettesíti a jó tartalmat — de a jó tartalmat sem érdemes egy lassú oldallal hátráltatni.
A három mutató érthetően
LCP — mikor jelenik meg a lényeg?
A Largest Contentful Paint azt méri, mennyi idő alatt jelenik meg az oldal legnagyobb látható eleme — jellemzően a fő kép vagy a nagy címsor. Jó érték: legfeljebb 2,5 másodperc a betöltés kezdetétől.
INP — milyen gyorsan reagál az oldal?
Az Interaction to Next Paint azt méri, mennyi idő telik el egy kattintás, koppintás vagy billentyűleütés és a látható reakció között. Jó érték: legfeljebb 200 ezredmásodperc. Az INP 2024. március 12-én váltotta le a korábbi reakcióidő-mutatót, az FID-t.
CLS — ugrál-e az oldal?
A Cumulative Layout Shift azt méri, mennyire mozdulnak el váratlanul az elemek betöltés közben — például amikor egy későn megjelenő kép vagy sáv miatt pont mellé koppintasz. Jó érték: legfeljebb 0,1.
| Mutató | Mit mér? | Jó érték |
|---|---|---|
| LCP | a fő tartalom megjelenését | legfeljebb 2,5 s |
| INP | a reakcióidőt a felhasználói műveletekre | legfeljebb 200 ms |
| CLS | a váratlan elmozdulásokat | legfeljebb 0,1 |
A web.dev ajánlása szerint az oldalmegjelenítések 75. percentilisét érdemes nézni, mobilon és asztali gépen külön. Egyszerűbben: akkor jó egy mutató, ha a látogatások legalább háromnegyedénél a jó tartományba esik.
Laborérték és valós adat — mi a különbség?
Kétféle mérés létezik. A labormérést (például a Lighthouse-t) egy szimulált eszközön és szimulált hálózaton futtatják: gyors, megismételhető, és megmutatja a hibák okát. A valós felhasználói adatok azt mutatják, mit tapasztaltak a valódi látogatók a saját eszközeiken — ezek a Chrome felhasználói élmény-jelentéséből (angol rövidítéssel CrUX) származnak, és a Search Console Core Web Vitals-jelentése is ezekre épül.
Kis forgalmú oldalaknál valós adat gyakran még nem áll rendelkezésre, mert ahhoz elegendő számú látogatás kell. Ilyenkor a laborérték a legjobb kiindulópont.
Így méred meg öt perc alatt
- Nyisd meg a PageSpeed Insights oldalt, és írd be a weboldalad címét.
- Először a Mobil fület nézd. Felül a valós felhasználói adatokat látod (ha vannak), alatta a labormérés eredményét és a javítási javaslatokat.
- Ha van Google Search Console-fiókod, a Core Web Vitals jelentés megmutatja, mely oldalcsoportok jók, és melyek javítandók.
- Végül nyisd meg az oldalt a saját telefonodon, mobilinternetről, és figyeld: mikor jelenik meg a lényeg, és ugrál-e valami betöltés közben.
A leggyakoribb lassító tényezők
- Túl nagy, tömörítetlen képek. Egy telefonról feltöltött fotó gyakran több megabájtos. Megfelelő méretre vágva, modern formátumban (WebP, AVIF) ugyanaz a kép a töredékére csökkenthető.
- Minden kép azonnal letöltődik. Az oldal lejjebb lévő képeit elég akkor betölteni, amikor a látogató odagörget (késleltetett betöltés, angolul lazy loading).
- Felesleges külső szkriptek. Csevegőablak, többféle mérőkód, közösségimédia-beágyazások — mindegyik extra letöltés és processzoridő.
- Mobilon is letöltődő nehéz videók. Egy háttérvideó asztali gépen látványos lehet, mobilon viszont sokszor csak lassít.
- Külső betűtípus-szolgáltatók. Minden külső kiszolgáló plusz kapcsolatfelvételt jelent; a saját tárhelyről kiszolgált, előre betöltött betűtípus gyorsabb.
- Lassú tárhely. Ha a szerver lassan válaszol, a többi optimalizálás csak részben segít.
- Méret nélküli képek és későn megjelenő sávok. Ezek okozzák az ugráló elrendezést, vagyis a rossz CLS-t.
A saját oldalunkon is így dolgozunk: ami nem látszik az első képernyőn, az csak akkor töltődik be, amikor a látogató odaér; mobilon a nehéz háttérvideó le sem töltődik; a betűtípusokat pedig saját tárhelyről, előre betöltve szolgáljuk ki.
Mit kérj a weboldal-készítődtől?
- mobilra tervezett és mobilon tesztelt oldalt;
- optimalizált képeket: megfelelő méret, modern formátum, késleltetett betöltés;
- csak a valóban szükséges külső szkripteket;
- a szerveren bekapcsolt tömörítést és gyorsítótárazást;
- átadáskor egy PageSpeed Insights-mérést mobilra és asztali gépre is.
Ezek nem extrák, hanem a gondos munka alapjai — nálunk a gyors betöltés minden csomag része. Hogy mi kerüljön még egy jó kisvállalkozói weboldalra, azt 15 pontos ellenőrzőlistánkban gyűjtöttük össze.


