Core Web Vitals WordPressen: Így húzd zöldbe a LCP és CLS mutatókat magyar tárhelyen

A legtöbb magyar WordPress-tulajdonos és SEO-ügynökség még mindig abban a hitben él, hogy a zöld PageSpeed Insights pontszám egyenlő a tökéletes felhasználói élménnyel, miközben a motorháztető alatt katasztrofális technológiai adósságot halmoznak fel. Az igazság az, hogy a piacon elterjedt „JS-késleltetési” trükkökkel elért 90+ mobil pontszámok csupán mesterségesen generált délibábok, amelyek teljesen tönkreteszik a GTM, Facebook Pixel és Google Analytics méréseket, miközben a valós látogatók továbbra is akadozó, lassan reagáló oldalakkal találkoznak. Webáruházak százai veszítenek el milliókat amiatt, mert a fejlesztők a szintetikus mérési adatok kozmetikázására fókuszálnak ahelyett, hogy a tényleges böngészési szűk keresztmetszeteket oldanák meg a hazai, gyakran alulméretezett szerverkörnyezetben.

A Google algoritmusa könyörtelenül bünteti azokat az oldalakat, amelyek nem felelnek meg a Core Web Vitals (CWV) irányelveinek, de a helyzet ennél sokkal összetettebb. A hazai e-commerce piac szereplői számára a mobil forgalom aránya ma már átlagosan 75% és 85% között mozog. Ez azt jelenti, hogy a teljes konverziós útvonal olyan eszközökön és hálózatokon zajlik le, amelyek messze elmaradnak a fejlesztőirodákban használt csúcskategóriás Macbookok és gigabites optikai internet sebességétől.

A valóság az észak-magyarországi kistelepüléseken utazó Telekom- vagy Yettel-ügyfél 4G hálózata, ahol a késleltetés (latency) nem 5 ms, hanem 80-120 ms, és a sávszélesség is ingadozik. Ha egy WooCommerce webáruház motorja 3 megabájt felesleges JavaScriptet próbál meg letölteni és végrehajtani a látogató telefonján, a lemorzsolódás garantált.

Az INP (Interaction to Next Paint) mutató végleg átvette a korábbi FID (First Input Delay) helyét. Az INP már nemcsak az első interakciót méri, hanem a látogató teljes munkamenete alatti összes kattintás, koppintás és billentyűleütés válaszidejét vizsgálja. Ha egy Elementorral épített, harminc pluginnel megterhelt WordPress oldalon a kosárba tétel gombra kattintás után 300 ms-nál hosszabb idő telik el, mire a felület vizuálisan reagál, a Google a vörös zónába sorolja az oldalt, a felhasználó pedig elhagyja a kosarat. A kosárelhagyási arány hazai átlagban 70% felett van, és ennek jelentős része közvetlenül a lassú válaszidőkre vezethető vissza.

---

A WordPress legnagyobb előnye egyben a legnagyobb átka is: az ezerféle plugin segítségével percek alatt építhető funkcionális webáruház. Azonban minden egyes feltelepített kiegészítő saját CSS- és JS-fájlokat injektál a weboldal fejlécébe és láblécébe.

A böngészők egyetlen szálon (Main Thread) hajtják végre a JavaScript kódokat, renderelik a HTML-t és számolják ki az elrendezést (styles). Ha egy marketinges telepakolja a WordPress oldalt popup-kezelőkkel, hírlevél-feliratkoztatókkal, melegségtérképes elemzőkkel (pl. Hotjar) és chatbotokkal, ezek a scriptek szó szerint megfojtják ezt az egyetlen végrehajtási szálat.

Amikor a látogató rákattint a menüre vagy a fizetési gombra, a böngésző nem tud azonnal reagálni, mert éppen egy harmadik féltől származó, rosszul optimalizált nyomkövető scriptet futtat. Az INP érték ekkor az egekbe szökik.

Az Elementor és a Divi vizuális oldalépítők csodálatosak a gyors prototípus-gyártásra, de kód szinten horrorisztikus eredményt produkálnak. Egyetlen egyszerű szövegdoboz megjelenítéséhez gyakran 10-15 egymásba ágyazott `<div>` konténert hoznak létre.

| Oldalépítő / Struktúra | Átlagos DOM-méret (elemek száma) | Felesleges CSS méret | INP hatás (mobil) |

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

| Elementor (alapbeállítás) | 1800+ elem | 800 KB - 1.2 MB | Magas (250 ms+) |

| Gutenberg (blokk alapú) | 600 - 800 elem | 150 KB - 300 KB | Alacsony (<100 ms) |

| Bricks Builder / Oxygen | 400 - 600 elem | 80 KB - 150 KB | Minimális (<50 ms) |

A hatalmas DOM-méret miatt a böngészőnek minden egyes stílusváltozásnál (pl. egy gomb fölé vitt egérnél) újra ki kell számolnia a teljes oldal elrendezését (Recalculate Style), ami drasztikusan rontja az INP mutatót.

---

Az LCP azt az időpontot jelzi, amikor a látogató számára az oldal legfőbb vizuális eleme (általában egy nagy banner kép vagy egy termékfotó) teljesen megjelenik. WordPress esetében az LCP-vel való küzdelem leggyakrabban a rossz szerverkonfigurációból fakad.

A piacon kapható évi 15 000 - 25 000 HUF értékű, osztott tárhelyek többsége alkalmatlan egy dinamikus WooCommerce oldal gyors kiszolgálására. Ha a TTFB (Time to First Byte) magasabb, mint 600 ms, akkor az esélytelenek nyugalmával indul az oldal az LCP versenyen.

A hazai szolgáltatók gyakran túlterhelik a fizikai szervereket (overselling), így hiába van elméletileg SSD a gépekben, ha a CPU-időért harcolnia kell a WordPressnek a másik 500 weboldallal, ami ugyanazon a vason fut. Ha a TTFB rossz, a böngésző csak késve kapja meg a HTML-t, így a képek letöltését is csak később tudja elkezdeni.

```

Nem optimalizált betöltés:

TTFB (800ms) ------------> CSS Letöltés (400ms) ------------> Kép felfedezés -> LCP megjelenés (2.8s)

Optimalizált betöltés (Redis + Preload + CDN):

TTFB (150ms) -> CSS + Preload (150ms) -> Kép letöltése paralell -> LCP megjelenés (0.9s)

```

Sokan elkövetik azt a hibát, hogy a főszezonban (például Black Friday idején) globális CDN-eket konfigurálnak be hibásan. Egy tisztán magyar célközönségű oldalnál egy távoli (például csak frankfurti szerverrel rendelkező) CDN használata növelheti a válaszidőt a közvetlen budapesti szervereléréshez képest. Ha CDN-t használunk, olyat kell választani, amelynek van hazai POP-ja (Point of Presence) – mint például a Cloudflare (amelynek van budapesti szervere is).

A képeket modern AVIF vagy WebP formátumban kell kiszolgálni. Az AVIF formátum átlagosan 30-50%-kal kisebb fájlméretet produkál, mint a WebP, azonos vizuális minőség mellett, ami a mobilhálózatokon másodperces nyereséget jelenthet az LCP-nél.

---

A CLS a vizuális stabilitást méri. Nincs idegesítőbb annál, mint amikor a felhasználó rákoppintana egy gombra, de az oldal hirtelen elugrik, mert egy kép vagy hirdetés éppen akkor töltődik be fölötte, és téves kattintást generál.

A reszponzív dizájn elterjedésével a fejlesztők elfelejtették megadni a képek fizikai méreteit a HTML-kódban. Ha hiányzik a `width` és `height` attribútum, a böngésző nem tudja előre lefoglalni a helyet a képnek. Amikor a kép letöltődik, a szöveg hirtelen lejjebb ugrik.

Ugyanez a helyzet a dinamikusan betöltődő Google AdSense hirdetésekkel vagy a hazai affiliate bannerekkel. Ha nem tartunk fenn nekik egy fix magasságú konténert (`min-height`), akkor a betöltődés pillanatában az egész tartalom eltolódik. Ez a hiba azonnali sárga vagy vörös besorolást jelent a Google Search Console-ban.

A tipográfia a dizájn alapja, de a külső szerverről (fonts.gstatic.com) betöltött betűtípusok komoly CLS-t okozhatnak. Amíg a webfont le nem töltődik, a böngésző vagy nem mutat semmit (FOIT – Flash of Invisible Text), vagy a rendszer betűtípust (pl. Arial) jeleníti meg, majd amikor megérkezik a Google Font, hirtelen áthelyezi a karaktereket (FOUT – Flash of Unstyled Text). Mivel a két betűtípus karakterszélessége eltér, ez szintén elrendezésbeli ugrást (CLS) eredményez.

---

Egy neves hazai divatcikk-kereskedő (éves árbevétele körülbelül 250 millió HUF, átlagos kosárértéke 18 500 HUF) azzal a problémával fordult a CTR.hu-hoz, hogy miközben a külsős fejlesztőjük büszkén prezentálta a mobil Pagespeed Insights teszten elért 96-os pontszámot, az organikus és fizetett hirdetésekből (Google Ads, Meta) érkező konverziós arányuk drasztikusan visszaesett.

A fejlesztő ügynökség bekapcsolta a WP Rocket (vagy ahhoz hasonló optimalizáló plugin) „Delay JavaScript Execution” funkcióját. Ez a beállítás azt csinálja, hogy addig nem tölt be és nem futtat semmilyen JavaScriptet az oldalon, amíg a felhasználó meg nem érinti a képernyőt vagy nem görget egyet.

Mivel a Google Lighthouse robotja nem végez valós felhasználói interakciót a mérés során, a teszt szerint az oldal villámgyors volt: nincs blokkoló JS, zöld az LCP, nulla az INP.

A valóságban azonban a következő történt:

• A GA4 (Google Analytics 4), a Google Ads konverziós kódok és a Facebook Pixel is késleltetve lettek.
• Azok a látogatók, akikből azonnal távozott az oldalról (pl. félrekattintottak vagy nem tetszett nekik a dizájn az első 2 másodpercben), egyáltalán nem jelentek meg a statisztikákban. A mérések 22%-a konkrétan elveszett.
• A hirdetési kampányok algoritmusai vakon repültek: a Meta Pixel nem kapta meg az adatokat a látogatókról, így a hirdetések optimalizálása félrement, a ROAS (hirdetési megtérülés) 4.2-ről 2.5-re esett vissza.
• Ha a látogató azonnal a menüre koppintott, a telefonnak abban a mikroszekundumban kellett letöltenie, elemeznie és végrehajtania az összes késleltetett JavaScriptet. A menü nem nyílt meg, az oldal lefagyott, a valós INP érték 850 ms felett volt.

A pénzügyi veszteségek és a helyreállítás folyamata

A hibás beállítás miatt a mérések torzultak, a szervezet rossz döntéseket hozott, a fizetett hirdetések konverziós aránya a valóságban 1.8%-ról 1.1%-ra esett vissza.

A helyzetet a következő lépésekkel javítottuk:

• Kikapcsoltuk a teljes mértékű JS-késleltetést.
• Az alapvető követőkódokat (GTM, Meta Pixel alap kód) kivettük a késleltetés alól, és közvetlenül a fejlécben, optimalizált módon (early connection és preconnect használatával) helyeztük el.
• A felesleges Elementor widget-fájlokat felülbíráltuk az Asset CleanUp plugin segítségével, így oldaltípusonként csak a szükséges CSS/JS töltődött be.
• A webáruházat átköltöztettük egy dedikált VPS környezetbe, Redis objektum-gyorsítótárazással (Object Cache).

Fejlesztési költség:

• Szakértői óradíj (16 munkaóra * 30 000 HUF): 480 000 HUF
• Egyéb licencdíjak (Perfmatters): 12 000 HUF

Az optimalizálás utáni eredmények:

| Mutató | Optimalizálás előtt (valós felhasználói adatok - CrUX) | Optimalizálás után | Változás |

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

| LCP (mobil) | 4.8 mp | 1.9 mp | -60% |

| INP (mobil) | 620 ms | 120 ms | -80% |

| Valós mobil konverziós ráta | 1.1% | 1.95% | +77% |

| Havi becsült bevétel növekmény| — | — | +1.850.000 HUF |

---

Ne higgy el mindent a YouTube-videóknak vagy az olcsó szabadúszóknak, akik egy ötösvértes Fiverr gig keretében ígérik meg a 100/100-as PageSpeed mutatót.

A NitroPack egy felhőalapú optimalizáló szolgáltatás, amely agresszíven átírja az oldal kódját. Gyakran olyan technikákat alkalmaz, amelyek elrejtik a lassulást a Google mérőeszközei elől (például a teljes HTML-struktúra manipulálásával és a DOM utólagos felépítésével), miközben a felhasználónak egy villogó, instabil felület jelenik meg. Különösen WooCommerce-nél okozhat súlyos gondokat a kosár és a pénztár folyamatok szétesésével.

Gyakori kép a magyar WordPress oldalak kezelőfelületén: egyszerre fut a WP Super Cache, az Autoptimize, az SG Optimizer és még a Cloudflare plugin is. Ezek a pluginek összeakadnak, többszörösen tömörítik ugyanazokat a fájlokat, ami felesleges szerveroldali processzorterhelést eredményez, növelve a TTFB-t és rontva a betöltési stabilitást.

Soha, semmilyen körülmények között ne gyorsítótárazd (cache) a kosár (`/kosar/`), a pénztár (`/penztar/`) és a fiókom (`/fiokom/`) oldalakat! Ha ezeket az oldalakat statikus HTML-ként menti el a rendszer, a látogatók idegen emberek kosártartalmát láthatják, vagy nem tudnak fizetni, ami azonnali GDPR-incidenst és hatalmas bevételkiesést okoz.

---

Ha szeretnéd, hogy WordPress oldalad valóban gyors legyen, és ne csak a teszteken mutasson jó számokat, hajtsd végre az alábbi technikai lépéseket.

Ha komolyan gondolod az e-commerce-t, felejtsd el a 2000 HUF/hó kategóriás osztott tárhelyet.

• Válts egy NVMe SSD alapú VPS-re (például Cloudways, Kinsta vagy egy egyedileg konfigurált hazai VPS szolgáltató).
• Kapcsold be a Redis vagy Memcached objektum-gyorsítótárat a tárhelyvezérlőn.
• A cikk írásakor győződj meg róla, hogy legalább PHP 8.2 vagy PHP 8.3 verzió fut a szerveren. A verziófrissítés önmagában 10-20%-os CPU-kapacitás felszabadulást jelent a korábbi 7.4-hez képest.

Vásárold meg a Perfmatters nevű prémium plugint (évi $25-től indul), amely a legjobb eszköz a WordPress felesleges fájljainak kezelésére.

• Kapcsold be az Asset Manager funkciót.
• Tiltsd le a globális fájlokat azokon az oldalakon, ahol nincs rájuk szükség. Például a Contact Form 7 vagy WPForms stíluslapjait és scriptjeit csak a `/kapcsolat/` oldalon engedd betölteni.
• Tiltsd le a felesleges WordPress funkciókat: emoji betöltés, Dashicons (ha nem vagy belépve admin módban), XML-RPC, RSS feedek (ha nem használsz blogot).

Az LCP elem (leggyakrabban a termékoldali főkép) azonnali megjelenítése a cél.

• Ne használj lazy load-ot (késleltetett betöltést) az LCP elemen! A hajtás feletti (above the fold) képeknél a lazy load kifejezetten rontja a mutatást.
• Alkalmazz preload (előre betöltés) direktívát az elsődleges képre. Ezt megteheted a következő kóddal a `functions.php`-ban vagy egy megfelelő plugin konfigurációjában:

```html

<link rel="preload" fetchpriority="high" as="image" href="https://weboldalad.hu/wp-content/uploads/fokep.webp" type="image/webp">

```

• Győződj meg róla, hogy a kép felbontása nem nagyobb, mint amekkora méretben ténylegesen megjelenik a mobilon (példalom felesleges egy 4000x3000 pixeles képet betölteni egy 400 pixel széles mobil képernyőre).

• Töltsd le a Google Fonts betűtípusokat woff2 formátumban, és töltsd fel őket közvetlenül a saját szerveredre (például a `/wp-content/themes/sablonod/assets/fonts/` mappába).
• A CSS kódba ágyazd be a `font-display: swap;` deklarációt, így a böngésző azonnal megjeleníti a szöveget a rendszerbetűtípussal, majd finoman vált a saját fontra, minimalizálva a FOIT-ot.
• Minden reszponzív képhez adj meg explicit méretarányt CSS-ben a CLS ellen:

```css

img {

width: 100%;

height: auto;

aspect-ratio: 16 / 9; / Vagy amilyen arányú a kép /

}

```

• A Google Tag Manager konténer tartalmát rendszeresen tisztítsd meg. A már nem használt kampányok pixeljeit azonnal töröld!
• A hotjar, Microsoft Clarity vagy egyéb session-recording scripteket állítsd be úgy, hogy csak a látogatók egy bizonyos százalékánál (mintavételezéssel, pl. 10%) fussanak, ne terheljék minden egyes vásárló tranzakcióját.
• Soha ne helyezz el egyedi, külső domainről behívott JS könyvtárakat közvetlenül a fejléchez társítva anélkül, hogy ne használnál `async` vagy `defer` attribútumokat.

Ha egyedi fejlesztésű sablont vagy egyedi funkciókat használsz, kerüld a nehéz JavaScript kalkulációkat a kattintási események (click event handlers) alatt. Ha komplex feladatot kell végrehajtani a kattintás után:

• Alkalmazz `requestAnimationFrame` vagy `setTimeout(..., 0)` hívásokat a nem kritikus vizuális változások késleltetésére.
• Azonnal adj visszajelzést a felhasználónak (például jeleníts meg egy betöltő csíkot vagy változtasd meg a gomb színét "bekapcsolt" állapotra), mielőtt a szervertől érkező válaszra várnál. Ez drasztikusan csökkenti az észlelt INP-t.

A PageSpeed Insights csupán egy labortesztszerű pillanatfelvétel. A valós helyzetet a Google Search Console *Core Web Vitals* menüpontjában láthatod, mert az a valódi felhasználók (Chrome User Experience Report - CrUX) elmúlt 28 napos mérési adatait dolgozza fel.

• Telepíts be egy saját RUM mérést (például ingyenes Cloudflare Web Analytics-et), amely valós időben mutatja az INP, LCP és CLS értékeket a látogatóid tényleges böngészései alapján.

---

Meta Title: Core Web Vitals WordPress optimalizálás: INP és LCP útmutató

Meta Description: Így optimalizáld WordPress webáruházad Core Web Vitals mutatóit (INP, LCP, CLS) trükkök nélkül. Valós magyar esettanulmány és mérhető akcióterv.