2026-03-11 · Baduno szerkesztőség · 7 blog.readMin · Blog és tudás
Core Web Vitals megértése: a három érték, ami számít
LCP, INP, CLS – a rövidítések mögött három egyszerű kérdés áll: Milyen gyorsan látok valamit? Milyen gyorsan reagál az oldal? Ugrál-e betöltéskor?
LCP: az első benyomás
A Largest Contentful Paint azt méri, hogy mikor töltődik be a legnagyobb látható elem – általában a hero kép. Célérték: 2,5 másodperc alatt. Legnagyobb befolyásoló tényező: kép mérete, képformátum (WebP/AVIF) és a fő kép priorizálása.
INP: a reakciókészség
Az Interaction to Next Paint azt méri, hogy az oldal milyen gyorsan reagál a kattintásokra és beviteli eseményekre. Lassú oldalak szinte mindig túl sok JavaScriptet tartalmaznak – minden megtakarított szkript nyert reakcióidőt jelent.
CLS: a stabilitás
A Cumulative Layout Shift azt méri, hogy a tartalmak ugrálnak-e betöltés közben. Fő okok: méretmegadás nélküli képek, utólag betöltő reklámok és webfontok. A javítás általában egyszerű – width és height attribútumok, fenntartott területek.
Miért számít ez
A Google rangsorolási jelként használja ezeket az értékeket, de ami még fontosabb: a felhasználók érzik őket. Minden egyes másodperc betöltési idő mérhető konverzióveszteséget okoz. A statikus, karcsú oldalak – mint ez is – strukturálisan érik el a célértékeket, nem utólagos javítgatással.
Core Web Vitals mérése: eszközök és adatforrások
A Core Web Vitals megbízható méréséhez több eszköz áll rendelkezésre. A PageSpeed Insights mind a Chrome User Experience Report (CrUX) terepi adatait, mind a Lighthouse laboradatait szolgáltatja. A CrUX-jelentés a valós felhasználói élményt tükrözi, és elsődleges forrásként kell használni. A Lighthouse ezzel szemben egy közepes kapcsolatot szimulál, és jól használható célzott optimalizálási javaslatokhoz. Folyamatos monitorozáshoz ajánlott az olyan eszközökbe való integráció, mint a Search Console vagy harmadik féltől származó megoldások, amelyek történeti trendeket jelenítenek meg. Fontos: ne hagyatkozzon kizárólag a laborértékekre – azok eltérhetnek a valóságtól. Kombinálja mindkét perspektívát, és teszteljen különböző eszközökön és hálózatokon.
Gyakori hibák az optimalizálás során
Sok weboldal elbukik elkerülhető hibákon. Klasszikus példa: képek magasság- és szélesség megadása nélkül, ami CLS-t okoz. A látható tartalmak (Hero kép) késleltetett betöltése (Lazy Loading) rontja az LCP-t. További buktató a nem optimalizált betűtípusok – a `font-display: swap` használata ugyan megakadályozza a láthatatlan szöveget, de elrendezési eltolódást okozhat, ha a tartalék betűtípus más szélességű. A reagálóképesség (INP) esetében gyakori ok a hosszú főszál-feladatok, amelyeket harmadik féltől származó szkriptek, elemzőeszközök vagy nem aszinkron módon betöltött erőforrások okoznak. Túl sok CSS- és JS-fájl csomagolás nélkül szintén terheli a renderelési utat. Kerülje el ezeket a hibákat úgy, hogy minden változtatás hatását ellenőrzi a három metrikára, és betöltési időre és szkriptvégrehajtásra vonatkozó keretekkel dolgozik.
Az LCP, INP és CLS összjátéka
A három Core Web Vital nem független egymástól. Az egyik metrika optimalizálása hatással lehet egy másikra. Példa: a JavaScript csökkentése nemcsak az INP-t javítja, hanem a fő tartalom betöltési idejét (LCP) is, mivel a renderelési fa gyorsabban épül fel. Ugyanakkor a kevesebb dinamikus tartalom csökkenti az elrendezési eltolódások (CLS) kockázatát. Másik példa: a `font-display: optional` használata megakadályozza a szöveg láthatatlanságát, de azt is okozhatja, hogy a betűtípus soha nem töltődik be – ami rontja az olvashatóságot, de javítja a CLS-t. Itt kompromisszumokat kell kötni: priorizálja azt a metrikát, amely a legnagyobb hatással van a felhasználókra. Általában az LCP a legkritikusabb az észlelés szempontjából, ezt követi az INP interaktív oldalaknál, majd a CLS tartalomban gazdag elrendezéseknél.
LCP, INP, CLS – a rövidítések mögött három egyszerű kérdés áll: Milyen gyorsan látok valamit? Milyen gyorsan reagál az oldal? Ugrál-e betöltéskor?
Mobil és asztali: eltérő kihívások
Ugyanazok a küszöbértékek érvényesek LCP (2,5 s), INP (200 ms) és CLS (0,1) esetében mobilon és asztali eszközön is. Ennek ellenére az optimalizálási megközelítések eltérnek. A mobil eszközök gyengébb processzorral és lassabb kapcsolattal rendelkeznek, így a felesleges JavaScript különösen negatívan hat. A hálózati átviteli sebesség is alacsonyabb – a nagy képek jobban rontják az LCP-t. Ráadásul a kisebb képernyőméret miatt az utólag betöltődő elemek által okozott elrendezési eltolódások kevésbé tolerálhatók. Asztali gépen viszont a túl sok szkript ronthatja a reagálóképességet, mivel blokkolja a főszálat. Ezért mindig először mobilon teszteljen 3G kapcsolattal. Használja a Lighthouse throttling módját, vagy szimuláljon valós körülményeket. A mobilra optimalizált oldal általában asztalin is jó – fordítva nem.
Szerver- és hálózatoptimalizálás: A láthatatlan kar
A Core Web Vitals nem a böngészőben kezdődnek, hanem már a szerveren. A Time to First Byte (TTFB) azt mutatja, hogy a szerver mennyi idő alatt válaszol egy kérésre. A magas TTFB mindent késleltet – az LCP szenved, mivel az első tartalom később érkezik meg. Ezért optimalizálja a szerver infrastruktúráját: Használjon tartalomkézbesítési hálózatokat (CDN), hogy a tartalmakat földrajzilag közel hozza a felhasználókhoz. A statikus eszközök, mint a képek, CSS és JavaScript, kiválóan kézbesíthetők CDN-eken keresztül, míg a dinamikus tartalmak intelligens gyorsítótárazással vagy edge computinggal gyorsíthatók. Egy másik kar a tárhelyszolgáltató kiválasztása: A megosztott tárhely sok szomszéddal megnövelheti a TTFB-t. Válasszon dedikált szervereket vagy gyors kapcsolattal rendelkező felhőmegoldásokat. A szerveroldali renderelés (SSR) és a statikus oldalgenerálás (SSG) összehasonlítása is hatással van: az SSR dinamikusan hozza létre a HTML-t, ami növeli a TTFB-t, míg az SSG előre kiszámított HTML-fájlokat kézbesít, és rendkívül gyors. Sok webhely számára a hibrid modell ésszerű: statikus tartalom SSG-vel, dinamikus részek API-hívásokkal. Mérje rendszeresen a TTFB-t olyan eszközökkel, mint a WebPageTest, és törekedjen 200 ezredmásodperc alatti értékekre. Vegye figyelembe: minden ezredmásodperc szerverkésleltetés hozzáadódik a teljes betöltési időhöz – és a felhasználók türelmetlenek.
Teljesítményköltségvetések: A Core Web Vitals aktív irányítása
Ahelyett, hogy reaktívan optimalizálna, építse be a teljesítménykereteket a fejlesztési folyamatba. A teljesítménykeret kötelező felső határokat szab meg olyan metrikákra, mint az LCP, INP vagy CLS – hasonlóan egy pénzügyi kerethez, amelyet nem szabad túllépni. Határozzon meg minden fontos oldalhoz célértékeket, amelyek 10-20 százalékkal a hivatalos küszöbértékek alatt vannak, hogy legyen egy puffere az ingadozásokhoz. Figyelje ezeket a kereteket automatikusan a folyamatos integrációs folyamatában: minden build ellenőrzésre kerül, és ha egy keret túllépésre kerül, a build sikertelen lesz. Így megakadályozza, hogy az új funkciók rontsák a felhasználói élményt. Eszköztámogatást nyújtanak a Lighthouse CI, a Sitespeed.io vagy saját szkriptek, amelyek a Lighthouse-ból vagy valós felhasználói adatokból származó Core Web Vitalokat értékelik. Ügyeljen arra, hogy mind a labor-, mind a terepi adatokat figyelembe vegye. Az LCP keret lehet például 2,0 másodperc a laborban és 2,3 másodperc a terepen (75. percentilis). INP esetében 150 ms labor és 180 ms terep reális. A CLS 0,05 alatt maradjon. Kommunikálja ezeket a kereteket a csapatban, és tegye őket a Definition of Done szerves részévé. Így biztosítja, hogy a teljesítmény ne utólagos toldalék legyen, hanem kezdettől fogva figyelembe vegyék.
Szerveroldali optimalizálás: TTFB és renderelési keret
A Core Web Vitals nem javítható kizárólag frontend-optimalizálással. Gyakran alábecsült tényező a szerver válaszideje (Time to First Byte, TTFB). Egy lassú szerver késlelteti a teljes betöltési folyamat kezdetét. Törekedjen 800 ezredmásodperc alatti TTFB-re. Használjon gyorsítótárazási mechanizmusokat, mint a Redis vagy a Varnish, optimalizálja az adatbázis-lekérdezéseket, és válasszon gyors hosztolási infrastruktúrát. A tartalomszolgáltató hálózat (CDN) megválasztása is szerepet játszik: a CDN lerövidíti a földrajzi távolságot a felhasználóig, és gyorsabban szolgáltatja ki a statikus erőforrásokat. Ezenkívül érdemes renderelési keretet (rendering budget) meghatározni – egy rögzített korlátot a maximális szkriptvégrehajtási időre az oldal felépítése során. Ossza fel a keretet LCP, INP és CLS között. Például az LCP maximum 1,8 másodperc szerveridőt és 0,7 másodperc kliensidőt foglalhat el. Ellenőrizze a betartást olyan eszközökkel, mint a Lighthouse vagy a WebPageTest. Szerveroldali rendereléssel (SSR) vagy statikus generálással csökkentheti a kliens terhelését. Ne feledje azonban, hogy az SSR növelheti a TTFB-t – tesztelje a különböző megközelítéseket. A szerverteljesítmény és a CDN kiegyensúlyozott kombinációja stabil Core Web Vitalst biztosít.
Monitorozás és folyamatos felügyelet üzem közben
Az egyszeri optimalizálások nem elegendőek – a Core Web Vitalst folyamatosan figyelni kell. Integráljon valós felhasználói monitorozást (RUM) a tényleges felhasználói adatok gyűjtéséhez. Olyan eszközök, mint a Google Analytics a Web Vitals jelentéssel, vagy nyílt forráskódú megoldások, mint a Grafana a CrUX API-val, lehetővé teszik a történeti összehasonlításokat. Állítson be küszöbértékeket, és konfiguráljon riasztásokat, ha az értékek meghaladják a célokat (LCP > 2,5 s, INP > 200 ms, CLS > 0,1). Figyelje a trendeket: ha egy mutató hetek alatt romlik, szükség lehet átdolgozásra. Különösen rendszeres tartalomfrissítések (blog, webshop, hírek) esetén fontos a folyamatos nyomon követés. A külső változások – például új harmadik féltől származó szkriptek beépítése – szintén ronthatják az értékeket. Minden kiadás előtt végezzen Lighthouse-tesztet, és dokumentálja az eredményeket. Ezen kívül ajánlott szintetikus monitorozás több helyszínről, ellenőrzött körülmények között. Így időben észlelheti a problémákat, mielőtt azok befolyásolnák a felhasználókat. Ne feledje: a Core Web Vitals egy folyamatos folyamat, nem egyszeri projekt. Csak szisztematikus felügyelettel maradnak oldalai hosszú távon teljesítőképesek és versenyképesek a keresési találatok között.
blog.faqT
Hogyan javíthatom a Core Web Vitals-t a CMS-emben, például a WordPress-ben?
WordPress esetén egy optimalizált téma, egy gyorsítótár-bővítmény és a képek tömörítése segít. Kerülje a túlzott számú bővítményt, különösen azokat, amelyek JavaScriptet töltenek be. Használjon olyan teljesítménybővítményt, amely letiltja a képek lusta betöltését (a látható tartalomnál), és kivonja a kritikus CSS-t. Tesztelje az eredményeket a PageSpeed Insights segítségével.
A Core Web Vitals közvetlen rangsorolási jelzés a Google-től?
Igen, a Core Web Vitals 2021 júniusa óta a Page Experience jelzés részét képezi a rangsorolásban. Azonban ezek csak egy a sok tényező közül. A gyors betöltési idők és stabil elrendezések révén nyújtott jó felhasználói élmény mérhető hatással van a konverziókra és a visszafordulási arányokra – függetlenül a rangsorolástól.
