Core Web Vitals 2026-ban: mit néz a Google, és mennyit tud ebből a tárhely

Szlávik Péter
Szlávik Péter Közzétéve:
Tárhely Weboldal
Lehet 95-ös a PageSpeed Insights pontszámod, miközben a mobil látogató még mindig lassan reagáló, ugráló oldalt kap. A Core Web Vitals azt mutatja meg, mit él át valójában: mikor jelenik meg a fő tartalom, milyen gyorsan reagál az oldal egy kattintásra, és stabil marad-e az elrendezés.
Fejlesztőként vagy ügynökségként ezért nem az a legfontosabb kérdés, hogy kell-e gyorsabb tárhely, hanem az, hogy a késés melyik rétegben keletkezik. A Google 2026-ban is az LCP, az INP és a CLS hármast nézi; a jó döntéshez valós felhasználói adat és pontos diagnózis kell.
Sybell szuperhős szétzúzza a lassan betöltő oldalt, és gyors weboldalt indít útjára — Core Web Vitals mutatók: LCP, INP, CLS

Miért nem ugyanaz a PageSpeed-pontszám és a jó Core Web Vitals?

A PageSpeed Insights két külön nézőpontot mutat. A Lighthouse laboreredmény egy ellenőrzött szimuláció: jó arra, hogy lásd, melyik CSS, JavaScript vagy kép fogja vissza az oldalt. A mezőadat viszont valós látogatásokból jön, és a Google ezt használja annak megértéséhez, milyen élményt kapnak ténylegesen a felhasználók.

A Core Web Vitals értékelés 28 napos gördülő ablakban, külön mobil- és asztali környezetre, a 75. percentilis alapján történik. Ez a gyakorlatban azt jelenti, hogy nem a saját gépeden futó egyetlen mérés számít, hanem az, hogy a látogatók többsége tényleg jó élményt kap-e.
Ezért lehet zöld a Lighthouse, miközben a Search Console még mindig javítandó URL-csoportot mutat. Először mindig a mezőadatból döntsd el, van-e valódi probléma, és csak utána használd a laboradatot a hiba okának feltárására.
Egy közepes mobiltelefonon teljesen más élmény születhet, mint egy erős fejlesztői laptopon. Ha ügyféloldalt optimalizálsz, mindig abból indulj ki, amit a valós látogató kap, ne abból, amit te látsz a saját gépeden.

Mit néz a Google 2026-ban a Core Web Vitals részeként?

A három mutató három külön területet mér, és együtt adnak értelmezhető képet.

LCP – Largest Contentful Paint: a legnagyobb, látható tartalmi elem megjelenését méri. Jó érték: legfeljebb 2,5 másodperc. 2,5–4 másodperc között javítandó, 4 másodperc felett rossz.
INP – Interaction to Next Paint: azt mutatja, mennyire gyorsan reagál az oldal a kattintásra, koppintásra vagy billentyűzetes interakcióra. Jó érték: 200 ms vagy kevesebb. 200–500 ms között javítandó, 500 ms felett rossz.
CLS – Cumulative Layout Shift: a betöltés közbeni váratlan elmozdulásokat méri. Jó érték: 0,1 vagy kevesebb. 0,1–0,25 között javítandó, 0,25 felett rossz.

LCP: mikor jelenik meg a fő tartalom?

Az LCP lehet egy hero-kép, egy nagy termékfotó vagy a fő címsor tartalmi blokkja. Nem a teljes oldal készültségét méri, hanem azt, mikor válik láthatóvá a felhasználó számára legfontosabb nagy elem.
A szerver első válaszideje és a cache késleltetheti ezt az egész láncot, de egy túl nagy vagy későn betöltött kép problémáját nem oldja meg automatikusan a gyorsabb hosting. Ilyenkor a képformátumot, a betöltési prioritást és a renderelést blokkoló erőforrásokat is vizsgálni kell.

INP: mit érez a felhasználó kattintás után?

Az INP nem csak az első kattintást méri. A felhasználói input késleltetését, az eseménykezelő futását és a következő képkocka megjelenéséig tartó renderelést együtt nézi, ráadásul több interakcióból számol.
A tipikus okok: hosszú JavaScript-feladatok, túl nagy bundle, sok DOM-módosítás és nehéz harmadik féltől érkező kód. A szerver itt akkor számít igazán, ha a kattintás mögött lassú API- vagy adatbázis-kérés áll.

CLS: marad-e a helyén, amit a látogató lát?

A CLS akkor nő, amikor a már látható tartalom elmozdul. Ennek gyakori oka a méret nélküli kép vagy videó, a későn betöltődő iframe, a fontcsere vagy a dinamikusan beszúrt banner.
A megoldás itt többnyire frontendoldali: foglalj helyet előre a képeknek, videóknak és beágyazásoknak, és tervezz stabil font fallbacket. A gyors kiszolgálás segíthet, de nem fog helyet foglalni a layoutban.

Laboradat vagy mezőadat? Így olvasd a PageSpeed Insights riportját

A mezőadat azt mutatja meg, mit tapasztalnak a látogatók. A laboradat azt, hogy egy kontrollált mérésben mi okozza a lassulást. A kettő együtt működik jól: az egyik kijelöli a problémát, a másik segít szétszedni.
Ha elég forgalom van, a PageSpeed Insights URL-szintű és origin-szintű CrUX-adatot is mutathat; ha nincs, az origin-adat vagy a „nincs adat” jelzés önmagában még nem minősítés.
A helyes sorrend egyszerű: előbb Search Console és mezőadat, utána több azonos laborfuttatás ugyanazon az URL-en, végül visszamérés deploy után. Egyetlen PageSpeed-futtatásból ne dönts tárhelyváltásról.

LCP és TTFB: itt tud a legtöbbet adni a tárhely

Az LCP-t érdemes láncként nézned: kapcsolatfelépítés, szerveroldali feldolgozás, cache, első bájt, majd a HTML, a CSS, a JavaScript és az LCP-erőforrás letöltése után jelenik meg a fő tartalom.
A TTFB nem Core Web Vital, hanem diagnosztikai jelzőszám. Irányadó célként a 0,8 másodperc alatti érték jó, 1,8 másodperc felett viszont már erős jel arra, hogy a szerverválasz visszafogja a betöltést. Ettől még lehet jó TTFB melletti rossz LCP is, ha a fő kép túl nagy vagy későn derül ki a böngésző számára.
Gondolj a tárhelyre úgy, mint egy gyors konyhára. Ha a rendelés gyorsan beérkezik és a konyha nem torlódik fel, hamarabb indul a kiszolgálás. De ha az étel túl bonyolult, vagy a pincér rossz sorrendben viszi ki, a vendég nem ettől érzi gyorsnak az egészet.
A hosting ezekben tud ténylegesen segíteni:
  • kiszámítható szerveroldali válaszidőben;
  • megfelelő PHP-, adatbázis- és memória-erőforrásban;
  • jól beállított teljes oldal- és objektumcache-ben;
  • gyors cache-ürítésben és helyes kivételekben;
  • korszerű TLS- és HTTP/3-kiszolgálásban;
  • TTFB-, hibás válasz- és terhelésmonitorozásban.
A cache esetében az számít, hol helyezkedik el a láncban. Ha a tárhelyed LiteSpeed webszerver alatt fut, akkor a teljes oldalcache már a PHP-futtatás előtt kiszolgálja a kérést, a kivételeket pedig — kosár, pénztár, bejelentkezett munkamenet — a WordPress-bővítményen keresztül szabályozod. Ez a TTFB-n és az LCP szállítási oldalán látszik meg, nem a JavaScripten.
A WordPress LiteSpeed Cache bővítményt az alábbi leírás alapján tudod pár kattintással beállítani: LiteSpeed Cache bővítmény beállítása
A fejlesztőnél marad a túl nagy hero-kép, a blokkoló CSS és JavaScript, a kliensoldali renderelés, a felesleges plugin és a rosszul optimalizált lekérdezés. Egy WooCommerce-oldalon a szervercsere javíthatja a TTFB-t, de ha a slider blokkolja a főszálat és a fő kép túl nehéz, az LCP fő gondja nem tűnik el.
Különösen fontos ez akkor, ha kampányidőszakban, sok pluginnal vagy dinamikus WooCommerce-folyamatokkal dolgozol: ilyenkor a szerveroldali gyorsulás sokat számít, de csak akkor látszik az eredmény, ha a fő tartalmi elem és a frontendlánc is rendben van.

INP és CLS: miért nem oldja meg őket egy erősebb szerver?

Az INP és a CLS mutatja meg a legjobban, miért veszélyes minden teljesítményproblémát infrastruktúra-oldalról nézni.
INP-nél a lassú interakciót kell megtalálnod: melyik kattintás indít hosszú feladatot, mennyi ideig fut az eseménykezelő, és mi történik utána a renderelésben. A javítás gyakran kód felosztása, scriptkésleltetés, rövidebb eseménykezelő vagy kevesebb harmadik féltől érkező kód.
CLS-nél a konkrét elmozduló elemet keresd. Ha a cookie-banner lenyomja az egész oldalt, vagy egy kép helyfoglalás nélkül érkezik meg, a gyorsabb PHP nem fogja stabilizálni a felületet.
Röviden így oszlik meg a felelősség:
  • Elsősorban hosting: TTFB, cache-találat, szerverkapacitás, szerveroldali feldolgozás.
  • Elsősorban fejlesztés vagy téma: LCP-erőforrás, JavaScript, DOM, CSS, képméretek, dinamikus elemek.
  • Közös terület: CDN, cache-kivételek, külső szolgáltatások, pluginok, monitorozás.

Hogyan diagnosztizáld a problémát tárhelycsere előtt?

A jó hibakereséshez nem több grafikon kell, hanem fegyelmezett sorrend.
  1. Nézd meg a Search Console Core Web Vitals jelentését és a PageSpeed Insights mezőadatait.
  2. Döntsd el, melyik a valódi gond: LCP, INP vagy CLS.
  3. Bontsd fel az LCP-t TTFB-re, erőforrás-letöltésre és renderelésre.
  4. Hasonlítsd össze a hideg és meleg cache-es állapotot.
  5. Profilozd az INP-t DevToolsban, és keresd a hosszú feladatokat.
  6. Keresd meg a CLS konkrét forrását: kép, font, iframe, popup vagy banner.
  7. Egy változót módosíts egyszerre: kódot, cache-t vagy tárhelyet.
  8. Mérj vissza laborban gyorsan, mezőadatban pedig türelmesen.
A leggyakoribb félrediagnosztizálás ma is ugyanaz: alacsony pontszám = rossz tárhely. Ez sokszor túl gyors következtetés.
Ha az ügyfél felé is dokumentálni kell, hol áll az oldal, a Sybell Hosting WordPress karbantartási csomagjaiban elérhető Kezdeti weboldal audit használható kiindulásnak: a WordPress-verziót, a bővítményeket, a sablont, a sebességproblémákat és a technikai kockázatokat együtt vizsgálja.

Mit várj el egy tárhelytől 2026-ban?

Fejlesztőként ne csak a lemezterületet vagy a névleges erőforrást nézd. Olyan környezet kell, ahol terhelés alatt is kiszámítható a szerverválasz, dokumentálható a cache viselkedése, és van biztonságos visszaállítási vagy tesztelési lehetőség.
Érdemes rákérdezned a PHP- és adatbázis-kapacitásra, a HTTP/3- és TLS-támogatásra, a cache-kivételekre és arra is, hogyan kapsz támogatást, ha egy frissítés után romlik a teljesítmény. Az uptime kevés: a TTFB, a hibaarány és a PageSpeed-trend sokkal használhatóbb döntési alap.
Ha nem egy, hanem több ügyfél oldalát üzemelteted, egy további szempont is belép: mennyire tartod kézben magát a környezetet. Az számít, hogy te tudsz-e dönteni a kapacitásról és a beállításokról, nem az, hogy minden változtatásnál külön egyeztetned kelljen.

Összegzés: előbb diagnosztizálj, utána válassz beavatkozást

A 2026-os Core Web Vitals mérés három kérdésre válaszol: mikor jelenik meg a fő tartalom, mennyire gyorsan reagál az oldal, és stabil marad-e a felület. A tárhely legközvetlenebbül a TTFB-re és az LCP szállítási oldalára hat; az INP és a CLS jelentős része továbbra is frontend- és fejlesztői feladat.
Ha a diagnózis után a szerveroldali réteg marad a szűk keresztmetszet, a Sybell Hosting Viszonteladói tárhely csomagjaiban magad hozod létre és kezeled az ügyfeleid tárhelyeit. A tárhelyek cPanel felületen érhetők el és LiteSpeed alatt futnak, így minden ügyfélnél ugyanazt a környezetet ismered, a cache viselkedése pedig kiszámítható és dokumentálható marad. Nem kell minden beállításnál külön egyeztetned — te pedig arra koncentrálhatsz, ami valóban a te dolgod a Core Web Vitals javításából.
Nézd meg viszonteladói csomagjainkat »