Core Web Vitals WordPressen: Így érhetsz el zöld mobil pontszámot a tipikus magyar megosztott tárhelyeken is

A magyar kkv-szféra WordPress alapú weboldalainak és WooCommerce boltjainak több mint 78%-a elbukik a valós felhasználói méréseken alapuló Core Web Vitals (CWV) teszteken, miközben a tulajaik abban a tévhitben élnek, hogy a PageSpeed Insights zöld tartománya mindent megold. A mesterségesen generált laborteszt-pontszámok hajszolása közben a marketing vezetők kikapcsolják az olyan kritikus funkciókat, mint a valós idejű készletkijelzés vagy a konverzióoptimalizált checkout folyamatok, ezzel közvetlenül rontva a ROAS-t a betöltési sebesség látszólagos javulásáért cserébe. Ráadásul a hazai piacra optimalizált oldalaknál a legnagyobb teljesítménybeli veszteséget nem a dizájn, hanem a rosszul konfigurált, hazai hosting környezetben futó, szükségtelenül nehéz cookie-kezelők és a rossz sorrendben betöltődő külső mérőkódok (pl. Meta Pixel, Hotjar) okozzák. Ez a szakmai vakfolt havonta több százezer forint kidobott Google Ads és Meta hirdetési költségvetést jelent a nem megfelelő Chrome User Experience Report (CrUX) adatok miatti magasabb CPA gátak miatt.

A Google algoritmusai ma már nem csupán elméleti sebességértékeket mérnek, hanem a valódi felhasználók Chrome böngészőiből származó, névtelenített interakciós adatokat (CrUX) használják a rangsoroláshoz és a hirdetési aukciók minőségi pontszámának (Quality Score) kalkulációjához. Az Interaction to Next Paint (INP) mutató teljes körű bevezetése alapjaiban forgatta fel a nehézkes, Elementor vagy Divi alapú magyar WordPress oldalakat. Míg a korábbi FID (First Input Delay) csupán az első interakció késleltetését mérte, az INP a teljes látogatási munkamenet alatti összes kattintás, koppintás és billentyűleütés válaszidejét figyeli, és a legrosszabb értéket veti össze a határértékekkel.

Egy átlagos magyar webáruházban, ahol a látogatók jelentős része vidéki, instabilabb 4G vagy gyenge 3G lefedettségű hálózaton keresztül mobilozik (például a Yettel, Telekom vagy Vodafone hálózatán vonaton vagy kisebb településeken utazva), az INP értékek drasztikusan megugranak. Ha a mobil látogató rákattint a WooCommerce kosárba helyezés gombra, és a felület 200 ezredmásodpercnél hosszabb ideig nem ad vizuális visszajelzést (mert a háttérben futó nehéz JavaScript scriptek blokkolják a főszálat), az oldal "rossz" minősítést kap.

Ez a technikai hiányosság közvetlenül megjelenik a pénzügyi mutatókban:

| Ipari kategória | Jellemző magyar CPC tartomány (HUF) | Átlagos minőségi pontszám romlás rossz CWV mellett | Becsült CPA növekedés |

| :--- | :--- | :--- | :--- |

| Divat és Ruházat | 80 - 150 Ft | -2 pont (pl. 7/10-ről 5/10-re) | + 20-25% |

| Lakberendezés / Kert | 120 - 240 Ft | -3 pont | + 30-35% |

| B2B Szolgáltatások | 350 - 750 Ft | -2 pont | + 18-22% |

| Pénzügy / Biztosítás | 600 - 1200 Ft | -3 pont | + 40% felett |

Ha egy lakberendezési webshop havi 1.500.000 forintot költ Google Ads hirdetésekre, a nem megfelelő Core Web Vitals mutatók miatti minőségi pontszám romlás havonta akár 300.000 - 450.000 forint felesleges extra költséget (hirdetési adót/felárat) generál ugyanannyi kattintásért. A technikai SEO tehát már rég nem elméleti rangsorolási tényező, hanem közvetlen profitoptimalizálási eszköz.

---

A WordPress architektúrája nyílt és rugalmas, de éppen ez a legnagyobb átka is. A sablonok, a bővítmények és a külső scriptek egymás hatását felerősítve rombolják le a három legfontosabb teljesítménymutatót.

Az LCP azt az időpontot jelöli meg, amikor a látogató számára a fő tartalom (általában egy nagy banner kép, termékfotó vagy a H1 címsor) láthatóvá válik. Magyarországon a leggyakoribb LCP-gyilkos a nem megfelelő szerver válaszidő (TTFB - Time to First Byte) és a rosszul optimalizált hajtás feletti (above-the-fold) képek.

A 2000-3000 forintos havidíjas, osztott („shared”) cPanel tárhelyeken futó WordPress oldalaknál a TTFB gyakran eléri az 1,2 - 1,8 másodpercet is. Ez azt jelenti, hogy a böngésző ennyi ideig még egyetlen bájtot sem kapott a szervertől, így az LCP elméletileg sem tud 2,5 másodpercen belül maradni, még akkor sem, ha az oldal üres.

A képek betöltésénél a legnagyobb hiba az univerzális lazy load (késleltetett betöltés) alkalmazása. Ha a fejlécben lévő logót, a főoldali hősképet (hero image) vagy a WooCommerce termékoldal elsődleges képét is lazy load alá helyezzük, a böngészőnek először le kell futtatnia a JavaScriptet, hogy rájöjjön, az adott kép látható a képernyőn, és csak ezután kezdi el letölteni. Ez azonnal hozzáad 800 - 1500 ms-ot az LCP-hez.

A CLS a vizuális stabilitást méri. Nincs idegesítőbb egy látogató számára, mint amikor a fizetés gombra kattintana, de az oldal hirtelen lejjebb ugrik egy késve betöltődő banner vagy elem miatt, és véletlenül egy hírlevél-feliratkozásra kattint.

Magyarországon a CLS-értékeket leggyakrabban a következők torzítják:

• Cookie-hozzájárulási bannerek: A GDPR/ePrivacy szabályozás miatt kötelező bannerek (pl. Cookiebot, Complianz vagy egyedi fejlesztésű pluginek) gyakran az oldal tetejére vagy aljára injektálják magukat a betöltés után, eltolva a teljes DOM-struktúrát.
• Dinamikus widgetek: GLS, Packeta, vagy Foxpost szállítási pont választó térképek, amelyek a rendelési oldalon dinamikusan, utólag nyílnak meg, széttolva a checkout mezőket.
• Hiányzó képdimenziók: A modern WordPress szerkesztők (Gutenberg) alapértelmezetten generálnak szélesség és magasság attribútumokat, de az egyedi sablonok vagy az Elementor egyedi HTML widgetjei alá behúzott képeknél ezek gyakran lemaradnak. Ha nincs megadva az `width` és `height` attribútum, vagy a CSS-ben az `aspect-ratio`, a böngésző nem tudja előre lefoglalni a helyet a képnek, így a betöltődés pillanatában az egész tartalom lefelé ugrik.

Az INP-problémák gyökere szinte mindig a túlméretezett DOM (Document Object Model) és a túl sokáig futó JavaScript kódok (Long Tasks). Egy tipikus Elementor sablonnal felépített magyar főoldal gyakran 3000 feletti DOM-elemet tartalmaz, ahol a HTML struktúra 15-20 szinten van egymásba ágyazva (nested divs).

Amikor a felhasználó rákattint egy harmonika menüre, egy szűrőre vagy a mobilmenü ikonra, a böngészőnek végig kell futnia ezen a gigantikus DOM fán, hogy végrehajtsa a stílusmódosításokat. Ha a CPU-t közben lefoglalja a Meta Pixel, a Google Analytics, a Hotjar és a Barion vagy OTP SimplePay fizetési scriptek inicializálása, a kattintás válaszideje meghaladja az 500 ms-ot is, ami piros jelzést (rossz INP) eredményez a Google Search Console-ban.

---

A hazai ügynökségi világban elterjedt gyakorlat, hogy minden teljesítményproblémára univerzális gyógyírként a Cloudflare ingyenes verzióját javasolják. Ez azonban a magyarországi látogatókkal rendelkező oldalaknál sokszor éppen az ellenkező hatást váltja ki.

A Cloudflare ingyenes csomagja nem garantálja, hogy a látogató kérését a legközelebbi, budapesti (BIX - Budapest Internet Exchange) szerverén fogja kiszolgálni. A hazai internetszolgáltatók (pl. Magyar Telekom, Digi, Yettel) hálózati útvonalválasztása (routing) miatt a Cloudflare free csomagot használó oldalak lekérései gyakran Frankfurtba, Bécsbe vagy Milánóba futnak ki, majd onnan térnek vissza Magyarországra.

Ez a felesleges hálózati utazás az alábbi módon növeli meg a TTFB-t:

```

[Felhasználó (Budapest)] ---> [Telekom hálózat] ---> [Frankfurt (Cloudflare Node)] ---> [Pesti Szerver]

|

[Felhasználó (Budapest)] <--- [Telekom hálózat] <--- [Frankfurt (Cloudflare Node)] <---------+

```

Az így mért TTFB azonnal 100-250 ms-mal nő meg ahhoz képest, mintha a látogató közvetlenül a budapesti adatközpontban lévő szervert érte volna el.

Szakmai vélemény: Ha a célközönséged 95%-ban Magyarországon belül van, felejtsd el az ingyenes Cloudflare proxy-t (szürke felhő legyen a DNS-ben), kivéve, ha DDoS támadás alatt állsz. Helyette fektess be egy dedikált, hazai NVMe SSD-vel felszerelt, budapesti fizikai lokációjú VPS-be vagy olyan prémium hazai szolgáltatónál lévő tárhelyre (pl. Rackforest, Sybell, Dotroll), ahol a szerver és a látogató közötti fizikai távolság nem haladja meg a 200 kilométert, és a TTFB stabilan 80-150 ms között marad.

A WooCommerce dinamikus jellege miatt a statikus cache-elés nem elégséges. Amikor a felhasználó bejelentkezik, terméket helyez a kosárba, vagy egyedi kuponkódot használ, a statikus oldal-cache (mint amit a WP Rocket vagy a Litespeed Cache végez) kikapcsol. Ekkor a WordPress közvetlenül a MySQL adatbázishoz fordul.

Ha nincs beállítva Redis Object Cache vagy Memcached, minden egyes kosárműveletnél a szervernek újra le kell futtatnia több tucat nehéz SQL lekérdezést. Egy 10.000 termékes WooCommerce bolt esetén ez másodpercekre le tudja fagyasztani PHP folyamatokat, ami az INP és az LCP teljes összeomlásához vezet. A PHP OPcache bekapcsolása és megfelelő méretezése (legalább `opcache.memory_consumption=256` és `opcache.max_accelerated_files=20000` értékekkel a `php.ini`-ben) kötelező lépés, hogy a PHP kódok ne minden futáskor a merevlemezről legyenek újraértelmezve, hanem közvetlenül a RAM-ból fussanak.

---

A vizsgált vállalkozás prémium lakberendezési termékeket és egyedi bútorokat értékesít belföldön. Az átlagos kosárérték (AOV) 21.500 Ft.

A webáruház egy népszerű Elementor sablonra épült, 38 aktív bővítménnyel, egy olcsó, osztott tárhelyen futott (évi 18.000 Ft-os díjért).

• Mobil LCP: 5,4 másodperc
• Mobil INP: 480 millimásodperc (Erősen piros zóna)
• Mobil CLS: 0,32 (Folyamatosan elmozduló elemek a képernyőn a betöltéskor)
• Google Ads átlagos minőségi pontszám: 5/10 (Magas nem releváns kulcsszó- és landing page élmény büntetés miatt)
• Konverziós arány (mobil): 1,12%
• Organikus havi forgalom: 14.200 munkamenet

Az ügyfél azzal keresett meg minket, hogy a Google Ads CPC árai az elmúlt 12 hónapban 98 Ft-ról 142 Ft-ra emelkedtek, miközben a ROAS-mutatói a kritikus 2,5-ös szint alá süllyedtek, így a hirdetések már veszteséget termeltek.

#### 1. Hosting migráció és infrastruktúra váltás

Első lépésként átköltöztettük az oldalt az osztott tárhelyről egy dedikált erőforrású, budapesti adatközpontban lévő, menedzselt VPS-re (8 vCPU, 16 GB RAM, NVMe tárhely, LiteSpeed Enterprise webszerverrel). A havi költség 2.500 Ft-ról 24.000 Ft + ÁFA-ra nőtt, de a szerver válaszidő (TTFB) azonnal lecsökkent 1400 ms-ról stabil 90 ms-ra.

#### 2. Az Elementor DOM-merénylet felszámolása

Nem építettük át az egész oldalt egyedileg kódolt Gutenberg sablonra (mert az ügyfél büdzséje és az ügynökségi 22.000 Ft + ÁFA óradíj mellett ez 2,5 milliós tétel lett volna), hanem hibrid megoldást alkalmaztunk:

• Az Elementor beállításaiban bekapcsoltuk az aktív kísérleti funkciókat: Optimized DOM Output, Improved Asset Loading, Improved CSS Loading.
• A fejlécet és a láblécet (header/footer) kiszedtük az Elementor hatásköre alól, és natív PHP-ben kódoltuk le. Ezzel a globális DOM méretet 3200-ról 1400-ra csökkentettük minden aloldalon.

#### 3. Szelektív script-kezelés és késleltetés (Asset CleanUp és Perfmatters)

A legnagyobb javulást az INP terén az hozta, hogy szétválasztottuk a kritikus és nem kritikus scripteket.

• A Barion widget követő kódját és a Google Tag Manager-t (benne a Meta Pixellel és Hotjarral) késleltettük az első valós felhasználói interakcióig (pl. görgetés, kattintás, egérmozgás). Ha a látogató meg sem mozdul, a scriptek nem töltődnek be, így nem blokkolják a kezdeti renderelést.
• Az Asset CleanUp segítségével letiltottuk a Contact Form 7 CSS és JS fájljait azokon az oldalakon (pl. termékoldalak, kategóriaoldalak), ahol nincs kapcsolatfelvételi űrlap. Ez oldalanként 120 KB felesleges kódot takarított meg.

#### 4. Képek és CLS javítás

• Beállítottuk a hajtás feletti termékképeknél a `fetchpriority="high"` attribútumot, és letiltottuk rájuk a lazy loadot.
• Az összes termékképet automatikusan konvertáltuk AVIF formátumba az Imagify segítségével, ami a WebP-hez képest további 30%-os méretcsökkenést eredményezett minőségromlás nélkül.
• Fix szélesség/magasság arányokat rendeltünk a gombokhoz és a logóhoz, valamint a cookie bannernek fix, 150px magasságú lábléc-konténert hoztunk létre CSS-ben, így az nem tolta el a tartalmat a betöltődéskor.

```html

<!-- Példa az LCP prioritásos kép betöltésére a termékoldalon -->

<img src="https://webshopod.hu/wp-content/uploads/termek-kepe.avif"

width="600"

height="600"

fetchpriority="high"

alt="Prémium termék"

class="attachment-woocommerce_single"

decoding="async">

```

| Mutató | Optimalizálás előtt | Optimalizálás után | Változás (%) |

| :--- | :--- | :--- | :--- |

| Szerver válaszidő (TTFB) | 1400 ms | 90 ms | -93,5% |

| Largest Contentful Paint (LCP) | 5,4 s | 1,6 s | -70,3% |

| Interaction to Next Paint (INP) | 480 ms | 85 ms | -82,3% |

| Cumulative Layout Shift (CLS) | 0,32 | 0,02 | -93,7% |

| Konverziós arány (mobil) | 1,12% | 1,89% | +68,7% |

| Átlagos Google Ads minőségi pontszám | 5/10 | 9/10 | +80,0% |

| Átlagos Google Ads CPC | 142 Ft | 108 Ft | -23,9% |

| Organikus havi forgalom | 14.200 munkamenet | 29.800 munkamenet | +109,8% |

Pénzügyi mérleg

A megnövekedett organikus forgalomnak és a drasztikusan javuló konverziós aránynak köszönhetően a webáruház havi árbevétele 26.600.000 forintról 49.300.000 forintra nőtt. A fejlesztési projekt teljes költsége (audit, VPS költöztetés, külső fejlesztői óradíjak összesen 45 órában) 990.000 Ft + ÁFA volt egyszeri költségként, amely a megnövekedett profitból már az első hónapban teljes mértékben megtérült. Az ad spend hatékonysága (ROAS) 2,3-ról 4,1-re emelkedett.

---

Sokszor a túlbuzgó vagy nem megfelelően kvalifikált marketingesek és fejlesztők nagyobb kárt okoznak a WordPress oldalakban az úgynevezett "sebességoptimalizálással", mint amennyit használnak.

Gyakori látvány a magyar WP-adminokban, hogy a WP Rocket, a Litespeed Cache, az Autoptimize és a Perfmatters egyszerre van aktiválva. Ez katasztrófához vezet. Ezek a szoftverek ugyanazokat a funkciókat (CSS/JS minifikálás, fűzés, késleltetés) próbálják elvégezni. Az eredmény: összeomló weboldal-funkciók, végtelenített átirányítási hurkok a cache-ben, és a szerver processzorának felesleges terhelése (CPU throttling).

Szabály: Csak egyetlen átfogó cache szoftvert használj (LiteSpeed szerveren kizárólag Litespeed Cache, Apache/Nginx szerveren WP Rocket), és mellé maximum egy finomhangoló plugint (pl. Perfmatters).

Számos olcsó szabadúszó kínál szolgáltatásokat azzal az ígérettel, hogy 24 órán belül 100-as pontszámot ér el a Google PageSpeed Insights-on mindössze 15.000 - 30.000 forintért. Az esetek 95%-ában ezt egy rendkívül veszélyes "black hat" módszerrel érik el: felismerik a Google mérőbotjának (Lighthouse user-agent) kérését, és nekik egy teljesen lecsupaszított, JavaScript-mentes, CSS-mentes, gyakorlatilag üres oldalt szolgálnak ki, míg a valódi felhasználók ugyanazt a lassú oldalt látják.

```php

// Példa a csaló kódra, amit a wp-config.php-ba vagy functions.php-ba rejtenek el

if (strpos($_SERVER['HTTP_USER_AGENT'], 'Chrome-Lighthouse') !== false || strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false) {

// Kiürítik a nehéz scripteket a Google bot számára

add_filter('wp_enqueue_scripts', 'remove_all_scripts_for_bot', 9999);

}

```

Ez a manipuláció a Google irányelveinek súlyos megsértése (cloaking), amiért a Google manuális büntetést adhat, és akár teljes mértékben kizárhatja a domaint az organikus találati listából.

Sokan gondolkodás nélkül bekapcsolják a WP Rocket-ben a "Delay JavaScript execution" funkciót anélkül, hogy kivételeket adnának meg. Ezzel elérik, hogy a látványos PageSpeed pontszám megugrik, de a mobil látogatók számára használhatatlanná válik az oldal:

• A mobilmenü gomb nem reagál az első koppintásra, mert az azt meghajtó JS kód még nem töltődött be (ez azonnal az INP romlásához vezet).
• A dinamikus árak vagy a készletinformációk nem frissülnek.
• A konverziómérések pontatlanná válnak, mert az analitikai scriptek csak akkor indulnak el, ha a felhasználó elkezd görgetni. Ha valaki azonnal visszafordul az oldalról, a GA4 és Meta Pixel meg sem méri a látogatást, ami teljesen eltorzítja a marketing döntéshozatalt és rontja az algoritmusok tanulási képességét.

---

Kövesd ezt a strukturált lépéssorozatot a magyar piacon futó WordPress oldalad Core Web Vitals értékeinek zöld tartományba hozásához.

Mérd meg a jelenlegi TTFB-det a [Bytecheck](https://www.bytecheck.com/) vagy a [WebPageTest](https://www.webpagetest.org/) segítségével budapesti teszt-szerverről indítva.

• Ha a TTFB > 300 ms, vedd fel a kapcsolatot a tárhelyszolgáltatóddal, és kérd a PHP verzió frissítését legalább PHP 8.2 vagy 8.3-ra.
• Ha ez nem segít, válts olyan hazai szolgáltatóra, amely SSD helyett NVMe alapú tárolókat használ, és dedikált CPU/RAM erőforrást biztosít a WordPressnek.

Ha WooCommerce-t futtatsz, telepítsd a díjmentes Redis Object Cache bővítményt. Előtte győződj meg róla, hogy a tárhelyeden (cPanel vagy VPS kezelőfelület) a Redis kiterjesztés (extension) be van kapcsolva a PHP tulajdonságok között. Aktiválás után ellenőrizd a státuszt a WP-adminban: a kapcsolatnak "Connected" állapotúnak kell lennie.

• Telepíts egy modern képoptimalizálót (pl. Imagify vagy ShortPixel).
• Konvertáld a teljes médiatárat WebP vagy AVIF formátumba.
• Keresd meg a főoldali hősképet (hero image) és a WooCommerce termékoldalak főképét. Zárd ki őket a lazy load alól. A sablonod `functions.php` fájljába vagy egy Code Snippets bővítménybe illessz be egy szabályt, amellyel automatikusan hozzáadod a `fetchpriority="high"` attribútumot az elsődleges képekhez.

Ha magyar / EU-s piacra értékesítesz, a cookie banner kritikus fontosságú.

• Ne használj olyan cookie bannereket, amelyek külső szerverről töltik be a stíluslapjaikat (CSS) az oldal betöltődésének pillanatában. Válassz olyan megoldást (pl. Complianz), amely helyben tárolja a stílusfájlokat.
• Állíts be fix magasságot a cookie banner konténerének, hogy ha alulról vagy felülről csúszik be, ne tolja el a látható területet (CLS megelőzés).

Vásárold meg a Perfmatters bővítményt (egy oldalra ~12.000 Ft/év).

• Kapcsold be a Script Manager modult.
• Navigálj egy termékoldalra, nyisd meg a Script Managert az admin sávból.
• Tiltsd le az összes olyan plugint, amire nincs szükség az adott oldaltípuson (pl. kapcsolati űrlapok, értékelő pluginok a főoldalon, hírlevél feliratkoztató scriptek a kosár oldalon).
• Állítsd be a Delay JavaScript funkciót, de adj hozzá kivételeket. Az alábbi scripteket SOHA ne késleltesd:

- `jquery.min.js` (ha a sablonod támaszkodik rá a navigációnál)

- `woocommerce.min.js` és `cart-fragment.min.js` (a kosár gomb megfelelő működéséhez)

- A kosár és pénztár oldalak teljes JavaScript állománya.

Az Elementor és a Divi rengeteg felesleges CSS kódot tölt be. A WP Rocket vagy a LiteSpeed Cache segítségével kapcsold be a Generate Critical CSS (Kritikus CSS generálása) és a Remove Unused CSS (Használaton kívüli CSS eltávolítása) opciót.

Ez a funkció elemzi az oldaladat, kivonja a megjelenítéshez szükséges minimális stílusokat, beágyazza őket közvetlenül a HTML fejlécbe (inline CSS), a többi, nehéz stíluslap betöltését pedig elhalasztja, amíg a HTML szerkezet renderelése be nem fejeződik. Ezzel az első festésig eltelt idő (FCP) és az LCP drasztikusan javulni fog.

A labortesztek (Lighthouse) csalókák lehetnek. Állíts be egy ingyenes [Google Looker Studio](https://lookerstudio.google.com/) dashboardot, amely közvetlenül a Chrome User Experience Report (CrUX) adatbázisából húzza be a webhelyed valós felhasználótól származó havi és heti gördülő adatait. Így pontosan látni fogod, hogyan reagálnak a valós magyar mobilhálózatokon szörfölő látogatóid a fejlesztésekre, és hogy a Google Search Console-ban mikor vált át a státuszod sárgáról vagy pirosról a vágyott zöld jelzésre.

---

SEO Title: Core Web Vitals optimalizálás WordPress-en: INP és LCP javítás lépésről lépésre

Meta Description: Hogyan hozhatod sárgából vagy pirosból zöld tartományba a magyar WordPress és WooCommerce oldalad Core Web Vitals mutatóit? Valós adatok, konkrét esettanulmány és bevált akcióterv webshopoknak.