A legtöbb cégvezető rossz kérdést tesz fel a weboldala teljesítményéről. Nem az foglalkoztatja, mennyire gyors az oldala, vagy zöld pipát mutat-e a Search Console. A valódi kérdés az, hogy elveszít-e látogatót és bevételt, mielőtt az oldala egyáltalán betöltene, és ki felel azért, hogy ez ne így legyen.
A Core Web Vitals nem a Google-nak szánt technikai vizsga. Üzleti mérőszám, aminek forintban mérhető következménye van. Egy lassú oldal nem a Google-nek fáj, hanem a vállalkozásnak.
Egy ügyfél ritkán ír azért, mert éppen a Core Web Vitals riportot nézegeti. Azért ír, mert azt látja a Search Console-ban, hogy problémák vannak, és fogalma sincs, ez mennyire súlyos, kinek a hibája és mibe fog kerülni a javítása. Ilyenkor a legrosszabb, amit egy digitális partner tehet, hogy technikai zsargonnal válaszol. A jó válasz azzal kezdődik, hogy elmagyarázzuk, mit mér valójában ez a három szám, és miért nem csak a Google-nak, hanem az ügyfél bevételének is számít.
Mielőtt bármilyen riportba belemennénk, érdemes magunkon kipróbálni. Nyissuk meg a saját termék- vagy szolgáltatásoldalunkat mobilon, mobilneten, egy átlagos telefonon. Görgessünk le, majd koppintsunk egy gombra. A fél másodperces akadás kattintás után, a helyéről elugró gomb, a rángatva beugró kép — pontosan ez az, amit a Google is mér és pontosan ez az, amit a látogató is átél, mielőtt továbblép egy versenytárshoz.
A három mérőszám nem elvont technikai adat. A felhasználó valós türelmetlenségének lefordítása számmá.
Egy dolgot érdemes fejben tartani: egy eszköz meg tudja mérni a bajt, de hogy melyik bajt éri meg megjavítani, azt valakinek el kell döntenie. Ez a döntés a különbség egy zöld pipa és egy tényleg jobban konvertáló oldal között.
Mi az a Core Web Vitals, valójában
A Core Web Vitals három mérőszámból áll. Mindhárom azt méri, amit egy valós látogató a saját böngészőjében ténylegesen megél, nem azt, amit egy laborteszt mutatna ideális körülmények között.
- LCP (Largest Contentful Paint): mennyi idő alatt jelenik meg az oldal legnagyobb, vizuálisan meghatározó eleme, tipikusan egy hero vagy egy címsor. Jó érték: 2,5 másodperc alatt.
- INP (Interaction to Next Paint): mennyi idő telik el egy kattintás, érintés vagy billentyűleütés és a látható válasz között. Jó érték: 200 ezredmásodperc alatt.
- CLS (Cumulative Layout Shift): mennyire ugrálnak el az elemek betöltés közben, vagyis a vizuális stabilitás. Jó érték: 0,1 alatt.
Az INP 2024 márciusában váltotta le a First Input Delay nevű korábbi mérőszámot. Az régen csak az első interakció késleltetését nézte. Az INP viszont az oldalon történő összes interakciót figyeli, ezért sokkal szigorúbb és valósághűbb képet ad arról, mennyire érzi gördülékenynek egy látogató az oldalt.
Amit a legtöbb ügyfél félreért a mérésben
A leggyakoribb félreértés, hogy az ügyfél a saját gépén futtat egy sebességtesztet, jó eredményt kap, és nem érti, miért jelez mégis problémát a Search Console.
A magyarázat egyszerű, csak ritkán mondja el valaki. A Core Web Vitals nem laboratóriumi mérés, hanem valós felhasználói adat, amelyet a Google a Chrome böngészőt használó látogatóktól gyűjt össze, egy gördülő 28 napos időszakra vetítve. Az oldal akkor számít megfelelőnek egy adott mérőszámban, ha a látogatások legalább 75%-a éri el a jó tartományt. Egyetlen gyors teszt tehát semmit nem mond a valós teljesítményről, csak a sok látogató valós tapasztalatának összesített képe számít.
A másik gyakori félreértés, hogy az ügyfél az egész weboldalra vonatkoztatja az eredményt, miközben a Google URL-szinten értékel. Lehet, hogy a főoldal kiváló, miközben a termékoldalak gyengén teljesítenek, és ez a különbség könnyen elsikkad, ha valaki csak egy összesített számot néz.
Miért nem csak SEO-kérdés ez
Itt fordul át a technikai riport üzleti kérdéssé. Szerencsére nem kell a szavunkat adnunk rá, elég a számokat nézni.
A Core Web Vitals hivatalosan rangsorolási tényező, a gyakorlatban azonban ritkán önmagában dönt egy pozícióról. Inkább akkor billenti el a mérleget, amikor két, hasonlóan releváns oldal verseng ugyanazért a helyért a találati listán. A valódi tétje ennél sokkal kézzelfoghatóbb, és nem kell elméleti szinten maradni, mert a Google maga is közzétett dokumentált esettanulmányokat arról, mi történik, amikor egy cég ténylegesen javítja ezeket a mérőszámokat.
A Vodafone Olaszország egy A/B tesztben hasonlított össze két, vizuálisan és funkcionálisan azonos landing page-et, ahol az egyetlen különbség az LCP volt. A 31%-al jobb LCP-jű változat 8 százalékkal több eladást, 15 százalékkal jobb lead-to-visit arányt és 11 százalékkal jobb kosárba-tett arányt hozott, kizárólag a sebesség javításából.
Az indonéz Tokopedia 55%-al javította az LCP-jét a betöltő elemek előtöltésével és a képoptimalizálással. Ennek eredményeként az átlagos munkamenet-hossz 23%-al nőtt.
A francia Cdiscount mindhárom mérőszámot javította, és ez a Black Friday-i akciójuk idején 6%-os bevételnövekedéshez vezetett.
A Google megbízásából a Deloitte 37 európai és amerikai márka több mint 30 millió mobilos munkamenetét elemezte a Milliseconds Make Millions kutatásban. Már 0,1 másodpercnyi gyorsulás is 8,4 százalékkal növelte a kiskereskedelmi konverziót és 9,2 százalékkal az átlagos kosárértéket, utazási oldalakon pedig 10,1 százalékkal a konverziót. Egy tized másodperc, annyi, amit tudatosan észre sem veszel.
Ezek a számok azért fontosak egy ügyfélnek, mert lefordítják a technikai riportot üzleti nyelvre. Egy lassú, imbolygó oldal nem azért rossz, mert a Google azt mondja. Azért rossz, mert a látogató otthagyja, mielőtt megvárná, hogy betöltsön, vagy véletlenül egy rossz gombra kattint, amikor az oldal alóla mozdul el.
A 100 pontos PageSpeed nem üzleti cél. A konvertáló látogató az.
Az INP, a mérőszám, amit a legnehezebb javítani
Ha egy ügyfélnek egyetlen dolgot kell megértenie a három mérőszám közül, az az, hogy nem mindegyik egyformán nehéz javítani.
Az LCP és a CLS javítása jellemzően jól bejáratott technikai lépésekkel megoldható: a képek előtöltése, a kritikus CSS beágyazása, a betűtípusok előtöltése, vagy a képeknek és videóknak explicit méret megadása, hogy ne mozduljon el körülöttük a tartalom. Az INP javítása ezzel szemben a JavaScript-architektúra alapvető átgondolását igényli, azt, hogy a fejlesztő hogyan bontja fel a hosszú, a böngésző fő szálát blokkoló műveleteket kisebb, megszakítható darabokra. Ez jóval időigényesebb és drágább feladat, mint egy kép tömörítése vagy egy cache beállítása. Ha egy ügyfél azt kérdezi, miért nem javítható egy hét alatt az INP, erre a különbségre érdemes rávilágítani.
Hétköznapi példával ez könnyen érzékelhető. A látogató mobilon rányom a kosár gombra vagy egy szűrőre, és az oldal egy pillanatig nem reagál. Számára ez csak egy röpke bizonytalanság, de gyakran pont ennyi elég ahhoz, hogy bezárja az oldalt, mert azt hiszi, elakadt valami. Ez az a pillanat, amit az INP mér.
Egy pontosítás, mert könnyű félreérteni: az INP a legdrágább javítani, de statisztikailag nem ezen bukik el a legtöbb oldal. A Web Almanac-adat mobilon 77 százalékos INP- és 81 százalékos CLS-megfelelést mutat, LCP-ből viszont csak 62 százalékosat. A legtöbb oldal tehát a betöltésen hasal el, nem a reakcióidőn. Ha valaki egyből a JavaScript újraírásával kezdené nálad, érdemes megkérdezni, miből gondolja, hogy pont az INP a szűk keresztmetszet.
És pont ez teszi 2026-ot fordulóponttá. Az INP 2024 márciusa óta éles mérőszám, de rengeteg oldal még mindig azon a JavaScript-architektúrán fut, amit a régi, elnézőbb First Input Delay korában építettek. Ezeken az oldalakon most jön elő a számla, és nem egy kép tömörítésével, hanem komolyabb fejlesztői munkával lehet rendezni. Aki idén nem néz rá, jövőre drágábban fogja.
És 2026-ban maga a mérce is mozdul egyet. A Chrome-csapat a Chrome 151-től alapértelmezetten bekapcsolja az úgynevezett soft navigation mérést. Eddig egy React- vagy Vue-alapú oldalon, ahol a kattintás után nem töltődik újra a teljes oldal, gyakorlatilag csak a legelső betöltést mérte a Google, a köztes lépések, ahol a látogató valójában dönt, kiestek a képből. Mostantól ezek is mérhetővé válnak. Hogy pontosan hogyan jelenik meg mindez a Google adatbázisában, azt a Chrome-csapat még maga sem közölte. Az irány viszont egyértelmű: egyre kevesebb olyan pontja marad a weboldaladnak, amit senki nem mér.
Milyen eszközökkel mérjük, és mit mutat valójában mindegyik
Az ügyfelek gyakran összekeverik a különböző eszközöket, pedig teljesen mást mérnek.
A Lighthouse és a PageSpeed Insights Diagnosztika füle laboratóriumi adatot ad, egyetlen szimulált betöltés eredményét egy adott hálózati és eszközkörnyezetben. Ez segít megérteni, mi okozza a problémát, de nem ez alapján dönt a Google. A Search Console Core Web Vitals riportja és a Chrome UX Report (CrUX) ezzel szemben valós felhasználói adatot mutat, ez alapján történik a rangsorolási értékelés. Ha egy oldalhoz kevés a valós látogatói adat, a Google URL-csoport vagy akár domainszintű adatra vált, ezért jelenhet meg egy vadonatúj oldal eleinte máshogy a riportban, mint néhány hónappal később.
A gyakorlatban ez azt jelenti, hogy egy fejlesztői csapat a PageSpeed Insights segítségével diagnosztizál és iterál, de a valódi visszaigazolást csak a Search Console-ban, néhány héttel a javítás után lehet látni, mert a 28 napos gördülő ablaknak be kell épülnie az új adatba.
Mi okozza leggyakrabban a problémát WordPress-oldalakon
A WordPress-alapú oldalaknál a teljesítményprobléma szinte sosem a keretrendszerből fakad. Néhány visszatérő ok szokott állni mögötte:
- Nem optimalizált kiemelt kép — tömörítés és megfelelő formátum (pl. WebP vagy AVIF) nélkül kerül fel az oldalra, és önmagában lerontja az LCP-t.
- Túlzsúfolt pluginlista — minden újabb plugin saját CSS-t és JavaScriptet tölt be, sokszor olyan oldalakon is, ahol nincs is rá szükség.
- Harmadik féltől származó szkriptek felhalmozódása — chat widgetek, hirdetési pixelek, analitikai eszközök egyenként ártalmatlannak tűnnek, együtt viszont komoly terhelést jelentenek az INP-re.
- Gondatlanul beállított vizuális page builderek — hajlamosak feleslegesen sok, egymásba ágyazott elemet generálni, ami mind a betöltési sebességet, mind a vizuális stabilitást rontja.
Egy drága, jól ismert téma vagy page builder önmagában nem garantál semmit. A legtöbb teljesítményprobléma a rárakódó pluginokból, szkriptekből és optimalizálatlan médiaanyagokból ered, nem a keretrendszerből.
A zöld pipa, amit meg lehet venni
Van egy ajánlattípus, amivel érdemes óvatosnak lenni: a garantált zöld Core Web Vitals. Ez ugyanaz a hamis ígéret, mint annak idején a garantált első hely a Google-ben, csak technikásabb köntösben. A Core Web Vitals valós látogatói adatból számol, amit nem te és nem a szolgáltatód állít elő, hanem a látogatóid, a saját telefonjukon, a saját mobilnetükön. Ezt senki nem tudja garantálni.
A gyakorlatban ez általában úgy néz ki, hogy valaki a laborszámot javítja meg, nem a valóságot. Felkerül egy optimalizáló plugin, a PageSpeed Insights felmegy 90 fölé, a riport szépen mutat, a Search Console viszont egy hónappal később ugyanazt jelzi, mint korábban, mert a látogatók élménye nem változott.
A másik visszatérő ajánlat a platformcsere: cseréld le a WordPress-t, mert lassú. Van benne igazságmag. A Search Engine Journal a Google saját adataiból dolgozó Core Web Vitals Technology Report alapján azt mérte, hogy a WordPress-oldalaknak nagyjából 44 százaléka teljesíti mind a három mérőszámot, míg a zárt, központilag karbantartott platformoknál ez az arány 85 százalék körül van. Csakhogy ez nem azt jelenti, hogy a WordPress lassú. Azt jelenti, hogy a WordPress rád bízza a döntést, és ha nem hoz senki döntést, az eredmény átlagos lesz. A platform a padlót szabja meg, nem a plafont: egy fegyelmezetten felépített WordPress-oldal simán zöld, egy szkriptekkel telepakolt zárt platform pedig simán bukik.
Egy magyar kkv-nál ez különösen fontos különbség, mert egy platformváltás ára tipikusan sokszorosa annak, amennyibe a meglévő oldal rendbetétele kerülne. Aki tehát a Search Console-riportra azonnal új weboldallal válaszol, az nem a problémát oldja meg. Egy nagyobb számlát ad el.
Mikor ne kezdj bele, és miért mondjuk el ezt is
Legyünk őszinték: nem minden oldalon éri meg belevágni, és ezt ritkán mondja el egy megrendelőnek bárki.
Ha a webhely havonta néhány száz látogatót lát, a Search Console figyelmeztetése valós, de nem ez a legdrágább probléma, előbb a forgalom és az ajánlat a kérdés, nem a fél másodperc. Ha a valódi gond az, hogy a látogató nem érti, mit kínál az oldal, vagy nem bízik benne, egy gyorsabb oldal csak gyorsabban veszíti el. És ha az INP rendbetétele a teljes JavaScript-architektúra újraírását igényelné egy oldalon, amit amúgy is lecserélnek fél éven belül, akkor a pénzt az új rendszerbe érdemes tenni, ne a régi toldozgatásába.
Ilyenkor mi azt mondjuk: most ne ezzel foglalkozz. Egy beszállító eladja a csomagot, amit kértek tőle. Egy partner időnként lebeszél róla, mert az ügyfél üzleti eredménye a tét, nem a számlázott óra.
Sokszor nem az a kérdés, min kell optimalizálni, hanem az, hogy a jelenlegi technikai felépítés egyáltalán mennyire támogatja a kereséseket és a modern, AI-alapú keresőrendszereket. Egy oldal lehet gyors és mégis láthatatlan, ha a struktúrája nem érthető sem az embereknek, sem a gépeknek. Ez az a pont, ahol egy AI Visibility felmérés többet ér, mint egy újabb sebességoptimalizálási csomag, mert megmutatja, hol áll az oldal valójában, mielőtt bármibe belefognánk.
És itt a két réteg ugyanabban a pontban ér össze. A Vercel és a MERJ szerverlog-elemzése szerint a nagy AI-crawlerek, a GPTBot, a ClaudeBot, a PerplexityBot, letöltik ugyan a JavaScript-fájlokat, de nem futtatják le őket. Csak azt látják, ami a szerver által küldött HTML-ben eleve benne van. Ugyanaz a nehéz, kliensoldali JavaScript-réteg tehát, ami az INP-det rontja, gyakran a tartalmadat is elrejti az AI-rendszerek elől. Nem két külön projekt: egyetlen technikai döntés, két következménnyel.
Amit valóban el kell mondani az ügyfélnek
Amikor egy ügyfél Core Web Vitals problémával keres meg minket, három dolgot mindig tisztázunk, mielőtt bármilyen technikai részletbe mennénk:
A probléma nem feltétlenül azt jelenti, hogy valaki hibázott. Egy weboldal teljesítménye folyamatosan változik, minden új blogbejegyzés képe, minden új harmadik féltől származó szkript, minden új funkció hatással van rá. A Core Web Vitals nem egyszeri feladat, hanem folyamatos karbantartás kérdése.
A szám mögött mindig konkrét, azonosítható ok áll, és ez az ok URL-enként eltérő lehet. Az első lépés ezért sosem a találgatás, hanem a mérés, enélkül könnyen olyan javításokba kezd egy csapat, amelyek nem is azt a problémát oldják meg, ami a valós forgalmat rontja.
A javítás szinte soha nem egyetlen nagy projekt, hanem sok kicsi, egymásra épülő döntés eredménye. Egy jól karbantartott oldalon ez folyamatos figyelmet igényel, nem egy féléves nagyprojektet.
A gép megméri a problémát. Hogy melyiket érdemes megoldani, azt mindig az üzleti cél dönti el.
Tipikus tévhitek, amelyekkel érdemes leszámolni
Az egyik elterjedt tévhit, hogy elég egyszer megjavítani, és onnantól nyugalom van. A Core Web Vitals dinamikus mérőszám, egy új marketingeszköz beillesztése, egy új banner vagy akár egy hirdetési pixel is visszavetheti az eredményt, ezért a rendszeres monitorozás legalább annyira fontos, mint az első javítás.
A másik tévhit, hogy a mobil és a desktop teljesítmény ugyanaz. A Google jellemzően szigorúbban méri a mobilos élményt, és mivel a legtöbb weboldal forgalmának nagy része mobilról érkezik, ezt a nézetet érdemes elsőként rendbe tenni.
A W5labs megközelítése
Nálunk a Core Web Vitals sosem önálló technikai feladatként kerül elő, hanem a projektek indulásától fogva a fejlesztési folyamat része. Amikor egy ügyfél weboldalán teljesítményproblémát találunk, az első lépés mindig a mérés és a konkrét okok feltárása, nem egy általános optimalizálási csomag ráhúzása. Két, egyformán rosszul teljesítő oldal mögött teljesen más ok állhat, és a megoldás is ennek megfelelően más lesz.
A gyors oldal önmagában nem versenyelőny, a lassú oldal viszont egyértelmű versenyhátrány. A Core Web Vitals csak egy réteg. Egy gyors oldal, ami mögött nincs világos üzleti stratégia, jó tartalom és olyan technikai struktúra, amit az emberek és az AI-keresők egyaránt értenek, még mindig csak egy néma, gyors oldal marad. A sebesség, a tartalom, a kommunikáció, a kereshetőség és az AI-láthatóság ugyanannak az egy rendszernek a rétegei. Mi nem egy mérőszámot foltozunk, hanem azt nézzük, hogy az egész rendszer szolgálja-e az üzleti növekedést.
A W5labs olyan digitális rendszereket tervez és épít, amelyekre a vállalkozások növekedése épül. A Strategy megtervezi a rendszert, a Creative kialakítja a kommunikációját, a Development felépíti, a Support pedig működésben tartja és védi — mert a Core Web Vitals nem egyszeri javítás, hanem folyamatos figyelem. Együtt ez adja azt a digitális infrastruktúrát, amely a stratégiától a növekedésig végigkíséri az ügyfelet.
Egy eszköz továbbra is meg tudja mérni a bajt, de hogy melyik bajt éri meg megjavítani, mit érdemes úgy hagyni, ahogy van, és mikor nem az oldalsebességgel kell foglalkozni, ez emberi döntés. Nálunk minden ilyen döntés mögött egy szakember áll, aki a nevét adja hozzá.
Ha valaki kíváncsi rá, végignézzük együtt, mennyire támogatja a jelenlegi weboldal, tartalom és digitális jelenlét az üzleti növekedést, és mennyire látható mindez a modern, AI-alapú keresők számára. Nem egyszerűen gyorsabb oldalakat készítünk, hanem digitális növekedési rendszereket építünk, amelyek hosszú távon is versenyelőnyt jelentenek.
