Ugrás a tartalomra
Tervezés és technika

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.

A Website Factory csapata5 perc olvasás

Illusztráció: sebességmérő és a Core Web Vitals mutatói (LCP, INP, CLS)

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.

A Core Web Vitals mutatói és a „jó” tartomány határa
MutatóMit mér?Jó érték
LCPa fő tartalom megjelenésétlegfeljebb 2,5 s
INPa reakcióidőt a felhasználói műveletekrelegfeljebb 200 ms
CLSa váratlan elmozdulásokatlegfeljebb 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

  1. Nyisd meg a PageSpeed Insights oldalt, és írd be a weboldalad címét.
  2. 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.
  3. Ha van Google Search Console-fiókod, a Core Web Vitals jelentés megmutatja, mely oldalcsoportok jók, és melyek javítandók.
  4. 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.

MegosztásFacebookLinkedInE-mail

A Website Factory-rólGyors, egyedi weboldalakat készítünk kisvállalkozásoknak Budapestről. A blogon arról írunk, ami a gyakorlatban működik — ellenőrizhető tényekkel, kitalált számok nélkül.

Utoljára frissítve: 2026. október 12.

Kapcsolódó cikkek

Saját weboldalon gondolkodsz?

Írd meg, mivel foglalkozol — 48 órán belül tételes, fix áras ajánlattal válaszolunk, kötelezettség nélkül.