A lassú weboldal Budapesten dupla hátrány: itt a legnagyobb a kereslet, de itt a legélesebb a verseny is. Egy budapesti kisvállalkozás forgalmának jelentős része mobilról érkezik, gyakran menet közben, ingadozó mobilhálózaton. Ha az oldal ilyenkor akadozik, a látogató nem vár, hanem visszalép a találati listára. A Core Web Vitals javítás pontosan ezt a valós, mobilos élményt méri és teszi jobbá. Ez az útmutató sorrendbe tett, végigcsinálható lépéseket ad, és megmutatja, hogyan mérd le tényszerűen a hatást.
Mi az a Core Web Vitals, és miért fontos egy budapesti kisvállalkozásnak?
A Core Web Vitals a Google három sebesség- és stabilitásmutatója, amely a valós felhasználói élményt írja le: a betöltés gyorsaságát, a válaszkészséget és a vizuális stabilitást. A három mérőszám: az LCP (a legnagyobb tartalmi elem megjelenése, célérték 2,5 másodperc alatt), az INP (mennyire gyorsan reagál az oldal a kattintásra, célérték 200 ezredmásodperc alatt) és a CLS (mennyit ugrál a tartalom betöltés közben, célérték 0,1 alatt).
Hivatalosan igazolt: a Google megerősítette, hogy a Core Web Vitals része a rangsorolási jelzéseinek, és 2024 tavaszán az INP váltotta le a korábbi FID mutatót. Szakmai feltételezés: a sebesség egy a sok rangsorolási tényező közül, ezért a javítás segítheti a helyezést, de önmagában nem garantál előrébb kerülést. Saját tapasztalat: a konverzióra viszont a mobil sebesség szinte mindig kimutatható hatással van, mert a lassú oldalon a látogató egyszerűen nem jut el az ajánlatkérésig vagy a foglalásig.
Hogyan mérd le a jelenlegi sebességet, mielőtt bármihez hozzányúlnál?
Előbb mérj, aztán javíts: labor- és mezei adatot is nézz, mert a kettő mást mond. A laboradat (lab data) egy szimulált teszt egyetlen eszközön, a mezei adat (field data) a valós látogatók, például a budapesti mobilfelhasználók tényleges élménye az elmúlt 28 napból.
- PageSpeed Insights: ide beírod az URL-t, és megkapod a labor- és a mezei értékeket is. A mobil fület nézd, ne az asztalit.
- Search Console Core Web Vitals jelentés: ez mutatja meg, hogy a teljes oldal mely aloldalai gyengék, csoportosítva. Ez a legjobb kiindulópont, ha eldöntenéd, hol éri meg dolgozni.
- Lighthouse: a Chrome beépített eszköze (jobb klikk, Vizsgálat, Lighthouse fül) részletes, elemenkénti diagnózist ad arról, mi lassítja az oldalt.
Saját tapasztalat: érdemes a mérést lassított, 4G-re állított mobil profilon futtatni, mert a fejlesztő gépén, gyors vezetékes neten minden gyorsnak tűnik. A valós budapesti forgalom nem így néz ki.
Milyen sorrendben javítsd a lassú oldalt?
A leggyorsabb nyereségtől a legdrágább felé haladj: képek, cache, szkriptek, végül a tárhely. Ez a sorrend nem véletlen: a képek optimalizálása hozza a legnagyobb javulást a legkevesebb kockázattal, a tárhelyváltás pedig a legnagyobb beavatkozás, amit csak akkor érdemes megtenni, ha a többi lépés már nem elég.
1. Képek: itt nyered a legtöbbet
A legtöbb lassú magyar kisvállalkozói oldalon a képek a fő bűnösök: túl nagy felbontású, tömörítetlen fájlok, amelyeket a böngésző kicsinyítve jelenít meg. Teendők:
- Tölts fel modern formátumban (WebP vagy AVIF) a régi JPG és PNG helyett. Ez jellemzően a fájlméret felét vagy harmadát jelenti látható minőségromlás nélkül.
- Méretezd a képet a tényleges megjelenítési mérethez. Ha a képet 800 pixelen mutatod, ne 4000 pixel széleset tölts fel.
- Kapcsold be a lazy loadingot a hajtás alatti (első képernyőn nem látszó) képekre:
<img loading="lazy" ...>. A legfelső, LCP-t adó képre viszont NE tedd ki, azt hagyd azonnal töltődni. - Adj meg fix szélességet és magasságot minden képnek, hogy ne ugráljon a tartalom (ez a
CLS-t javítja).
Saját tapasztalat: WordPress-oldalon egy jó képoptimalizáló bővítmény és a méretlimit beállítása gyakran önmagában több tized másodpercet farag az LCP-ből.
2. Cache: a második leggyorsabb nyereség
A cache azt jelenti, hogy a szerver nem építi fel újra minden látogatónál a teljes oldalt, hanem egy előre elkészített változatot ad ki. Teendők:
- Kapcsolj be oldal-cache-t (page cache) a rendszeredben vagy egy bővítménnyel.
- Állíts be böngésző-cache-t a statikus fájlokra (kép, CSS, JavaScript), hogy a visszatérő látogató ne töltse le újra ugyanazt. Ez a szerver fejlécében (
Cache-Control) állítható. - Fontold meg egy CDN (tartalomkiszolgáló hálózat) használatát. Szakmai feltételezés: egy tisztán budapesti, magyar közönségnél a CDN nyeresége kisebb, mint egy nemzetközi oldalnál, de a képek és statikus fájlok kiszolgálását így is gyorsíthatja.
3. Szkriptek: a láthatatlan lassítók
A JavaScript és a CSS gyakran több időt eszik, mint a képek, csak nem látszik. A tipikus okok: túl sok bővítmény, külső beágyazások (chat, térkép, több analitikai kód), renderelést blokkoló fájlok. Teendők:
- Halaszd vagy aszinkronizáld a nem kritikus szkripteket:
<script defer>vagy<script async>. Így nem blokkolják az oldal megjelenését. - Egyesítsd és kicsinyítsd (minify) a CSS- és JavaScript-fájlokat.
- Töröld a felesleges bővítményeket. Minden aktív bővítmény tölt valamennyi kódot, akkor is, ha alig használod.
- A külső beágyazásokat (például egy térkép vagy egy videó) töltsd be csak kattintásra, ne azonnal.
Saját tapasztalat: az INP romlásának leggyakoribb oka a túl sok, egyszerre futó szkript. A felesleges bővítmények kigyomlálása gyakran többet segít, mint bármilyen bűvös beállítás.
4. Tárhely: a legdrágább, de néha elkerülhetetlen lépés
Ha a mérésnél a szerver válaszideje (TTFB, az első bájtig eltelt idő) tartósan magas, hiába optimalizálod a képeket, az alap lassú marad. Ilyenkor a túlterhelt, olcsó megosztott tárhely a szűk keresztmetszet. Szakmai feltételezés: a gyorsabb tárhely vagy a jobb PHP-verzió gyakran érezhető javulást hoz a TTFB-ben, de ezt előbb méréssel érdemes igazolni, mert nem mindig ez a fő probléma. A tárhelyváltás legyen az utolsó lépés, amikor a többi már megvan.
Van rá egyszerű ellenőrzőlista?
Igen, ez a sorrend végigvezet a teljes folyamaton, a mérésétől a lezárásig.
- Mérj a PageSpeed Insightsban és a Search Consuله-ban, mobil nézetben, mezei adaton.
- Jegyezd fel a kiindulási LCP, INP és CLS értékeket.
- Konvertáld a képeket modern formátumra, méretezd őket, tedd rájuk a lazy loadingot.
- Adj meg fix méretet minden képnek és beágyazásnak a CLS ellen.
- Kapcsold be az oldal- és a böngésző-cache-t.
- Halaszd a nem kritikus szkripteket, kicsinyítsd a CSS-t és JavaScriptet.
- Töröld a felesleges bővítményeket és külső beágyazásokat.
- Ha a TTFB továbbra is magas, nézd meg a PHP-verziót és a tárhelyet.
- Várj legalább négy hetet, majd mérj újra mezei adaton.
Hogyan mérd le, hogy a munkád tényleg használt?
A valódi bizonyíték a mezei adat négy hét után, nem az egyszeri laborteszt. A laboradat azonnal mutat javulást a beavatkozás után, ez jó a fejlesztés közbeni ellenőrzésre. A mezei adat viszont a valós budapesti látogatók 28 napos élményét összegzi, ezért csak idővel áll be. Ne ess abba a hibába, hogy egyetlen gyors laborfutás alapján kihirdeted a sikert.
- A Search Console Core Web Vitals jelentésében figyeld, ahogy a "gyenge" és "javítandó" URL-ek átmennek a "jó" kategóriába.
- A GA4-ben nézd a mobil munkamenetek visszafordulási arányát és az oldalon töltött időt a beavatkozás előtti és utáni időszakban.
- Kösd össze a sebességet az üzleti eseménnyel: nőtt-e az ajánlatkérés, a hívás, a foglalás a mobilforgalomban.
Óvatos megfogalmazás: a Core Web Vitals javítása jó eséllyel segíti a mobil konverziót és támogathatja a rangsorolást, de a helyezést sok más tényező is befolyásolja, ezért a gyorsítás önmagában nem garantál előrébb kerülést. Budapesten, ahol a kereslet a vidékinek sokszorosa, de a verseny is a legerősebb, a stabilan gyors mobil oldal mégis olyan megkülönböztető pont, amit sok versenytárs elhanyagol.
Források és további olvasnivalók
- Google Search Central: dokumentáció a Core Web Vitals és a keresési rangsorolás kapcsolatáról
- web.dev (Google): Core Web Vitals mérőszámok (LCP, INP, CLS) magyarázata és optimalizálási útmutatók
- Google PageSpeed Insights és Lighthouse hivatalos dokumentáció
- Chrome User Experience Report (CrUX): a mezei adat forrása
- W3C: webteljesítmény-szabványok és a képformátumokra vonatkozó ajánlások
- Először mindig mérj mezei (field) adaton, ne csak laborteszten: a valós budapesti mobilfelhasználók élménye számít.
- A képek optimalizálása (modern formátum, méretezés, lazy loading) hozza a legnagyobb sebességugrást a legkevesebb munkával.
- A cache és a szkriptek karcsúsítása a második leggyorsabb nyereség, a tárhelyváltás a legdrágább, de néha elkerülhetetlen lépés.
- A Core Web Vitals javítás segítheti a rangsorolást és a konverziót, de önmagában nem garantál előrébb kerülést.
- A hatást négy hét mezei adaton mérd le, ne egyetlen laborfutáson: a valós javulás csak így válik láthatóvá.
Gyakori kérdések
Mi számít jó Core Web Vitals értéknek mobilon?
A Google szerint az LCP 2,5 másodperc alatt, az INP 200 ezredmásodperc alatt, a CLS pedig 0,1 alatt jó. Ezeket az értékeket mobil nézetben, a valós felhasználók mezei adatán érdemes elérni, mert a budapesti forgalom nagy része mobilról jön.
Melyik lépés hozza a legnagyobb gyorsulást?
A legtöbb magyar kisvállalkozói oldalon a képek optimalizálása: modern formátum (WebP vagy AVIF), a tényleges méretre való átméretezés és a lazy loading. Ez adja a legnagyobb javulást a legkevesebb kockázattal, ezért ezzel érdemes kezdeni.
Mennyi idő alatt látszik a javulás a Search Console-ban?
A laboradat azonnal mutat változást, a mezei adat viszont 28 napos időablakot összegez, ezért a Search Console Core Web Vitals jelentésében jellemzően több hét után áll be a javulás. Érdemes legalább négy hetet várni a mérés megismétlése előtt.
A gyorsabb oldal garantálja a jobb Google-helyezést?
Nem. A Core Web Vitals egy hivatalosan megerősített rangsorolási jelzés a sok közül, ezért a gyorsítás segítheti a helyezést, de önmagában nem garantál előrébb kerülést. A konverzióra viszont a mobil sebesség szinte mindig kimutatható hatással van.
Kell-e feltétlenül tárhelyet váltani a gyorsításhoz?
Nem feltétlenül. A tárhelyváltás a legnagyobb és legdrágább beavatkozás, ezért csak akkor érdemes, ha a szerver válaszideje (TTFB) a képek, a cache és a szkriptek optimalizálása után is tartósan magas marad. Ezt előbb méréssel érdemes igazolni.
Elég-e egy sebesség-optimalizáló bővítmény WordPressen?
Egy jó cache- és képoptimalizáló bővítmény sokat segíthet, de nem old meg mindent. A felesleges bővítmények, a renderelést blokkoló szkriptek és a túl nagy képek gyakran akkor is lassítanak, ha van optimalizáló plugin. A méréssel vezérelt, lépésről lépésre haladás megbízhatóbb, mint egyetlen bővítményre hagyatkozni.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.