SEO Cím: Core Web Vitals optimalizálás WordPress-en: Így mentsd meg a mobil konverzióidat
Meta leírás: Lépésről lépésre útmutató magyar WordPress és WooCommerce oldalak Core Web Vitals (LCP, CLS, INP) optimalizálására. Konkrét kódok, magyar esettanulmány és mérhető ROI.
A legtöbb magyar WordPress-alapú webshop és szolgáltató oldal komoly technikai adósságot görget maga előtt: a tulajdonosok kifizetnek 800 000 - 2 500 000 forintot egy egyedi dizájnnak hazudott, de valójában Elementorral vagy Divivel összekattingatott oldalért, majd értetlenül állnak az előtt, hogy a Google Ads kampányok visszafordulási aránya (bounce rate) 65% felett mozog. Hiába fut a marketing, ha a mobil látogatók jelentős része még azelőtt bezárja a lapot, hogy az első termékkép egyáltalán kirajzolódna a kijelzőjükön. A probléma gyökere nem a tárhelyszolgáltató (bár sok hazai shared hosting valóban alulteljesít), hanem a frontend optimalizálatlansága, valamint a Core Web Vitals (CWV) mutatók teljes ignorálása. Az alábbiakban bemutatjuk, miként lehet a kritikus sebességmutatókat olyan szintre hozni, ami közvetlenül javítja a tranzakciós konverziós arányt és csökkenti a CPC-költségeket.
Miért fontos ez most: A magyar mobilpiac kíméletlen valósága
A hazai e-commerce forgalom több mint 74%-a ma már mobileszközökön realizálódik, ám a hálózati infrastruktúra korántsem olyan stabil, mint az irodai gigabites asztali kapcsolatok. Elég egy vidéki utazás a MÁV-on, vagy egy gyengébb 4G lefedettségű terület a Balaton-felvidéken, és az egyébként "asztali gépen gyors" WordPress oldal másodpercekre megbénul.
A Google keresőalgoritmusa a Core Web Vitals mutatókat nem csupán rangsorolási tényezőként kezeli, hanem a Google Ads Quality Score (Minőségi Mutató) közvetett elemeként is.
```
Magas betöltési idő -> Rosszabb landing page élmény -> Alacsonyabb Minőségi Mutató -> Magasabb CPC (akár +30-50%-os felár)
```
Ha egy divat webshop esetében a Google Ads CPC a megszokott 90-130 HUF helyett a rossz oldalélmény miatt felkúszik 180 HUF-ra, az havonta több százezer forint felesleges kiadást jelent az e-kereskedőnek. Az Interaction to Next Paint (INP) bevezetése óta pedig már nem elég, hogy az oldal gyorsan megjelenjen (LCP): az is kritikus, hogy a felhasználó kattintására (például az "Kosárba teszem" gombra vagy a szűrő menüre) a rendszer azonnal, legfeljebb 200 ezredmásodpercen belül reagáljon.
---
1. LCP (Largest Contentful Paint) faragás WordPress-en
Az LCP azt méri, hogy az oldal fő tartalmának (általában a legnagyobb képnek vagy szövegblokknak) a betöltése mennyi időt vesz igénybe. WordPress környezetben a leggyakoribb hiba, hogy az LCP elemként azonosított termékképet, vagy a címlapi "hero" bannert lusta betöltésre (lazy loading) kényszeríti a rendszer.
A hajtás feletti képek kizárása a lazy load alól
A WordPress alapértelmezetten minden képre ráaggatja a `loading="lazy"` attribútumot. Ez katasztrofális az LCP szempontjából, ha a kép az első képernyőn (hajtás felett - above the fold) található. A megoldás az első 1-2 kép manuális vagy dinamikus kivétele az optimalizáció alól.
Ha nem akarunk újabb bővítményt telepíteni, helyezzük el az alábbi kódot a sablonunk (lehetőleg child theme) `functions.php` fájljába:
```php
function ctr_skip_lazy_load_first_image($attributes, $attachment, $size) {
static $counter = 0;
$counter++;
if ($counter <= 1) { // Az első képet mentesíti a lazy load alól
$attributes['loading'] = 'eager';
$attributes['fetchpriority'] = 'high';
}
return $attributes;
}
add_filter('wp_get_attachment_image_attributes', 'ctr_skip_lazy_load_first_image', 10, 3);
```
A `fetchpriority="high"` attribútum jelzi a böngészőnek, hogy ezt az erőforrást a legmagasabb prioritással kell letöltenie, még azelőtt, hogy a kevésbé fontos JS és CSS fájlok elemzésébe kezdene.
Modern képformátumok (WebP/AVIF) és a CDN
A magyar webtárhelyek (pl. Tarhely.eu, Dotroll, Sybell) esetében a szerver oldali képátméretezés és konvertálás gyakran túlterheli a CPU-t, különösen egy nagyobb, 10 000+ termékes WooCommerce shopnál.
- Ne használjunk olyan WordPress pluginokat a képek tömörítésére, amelyek a saját szerverünk erőforrásait fogyasztják a háttérben futó cron jobok segítségével.
- Helyette használjunk felhőalapú megoldásokat (pl. Cloudflare Polish, BunnyCDN vagy optimalizált backend mögötti ImageEngine szolgáltatást).
- A képek mérete mobileszközön soha ne haladja meg a 80-120 KB-ot, asztali gépen pedig a 200 KB-ot.
---
2. CLS (Cumulative Layout Shift) felszámolása
A CLS (elrendezésbeli eltolódás) az egyik legirritálóbb hiba a felhasználók számára: amikor az oldal betöltődik, de egy későn megjelenő elem (banner, hirdetés, betűtípus) miatt a tartalom lejjebb ugrik, és a látogató emiatt rossz linkre kattint. Magyarországon ezt leggyakrabban a hibásan beállított cookie-kezelő sávok, az OTP SimplePay vagy Barion fizetési logók dinamikus betöltődése, és a méretezés nélküli képek okozzák.
Képdimenziók kötelező megadása
Sok Elementor és Divi téma hajlamos elhagyni a `width` és `height` attribútumokat a HTML-ből, és csak CSS-ből határozza meg a méretet. Emiatt a böngésző a kép letöltődéséig 0 pixel magasságot foglal le neki, majd a letöltés után hirtelen "letolja" a szöveges tartalmat.
Mindenképpen gondoskodni kell arról, hogy a sablonunk által generált HTML kód tartalmazza a fizikai méreteket:
```html
<img src="https://pelda.hu/wp-content/uploads/termek.webp" width="600" height="400" alt="Prémium termék">
```
Betűtípusok betöltése eltolódás nélkül (FOUT/FOIT)
Ha Google Fontokat használunk (pl. Roboto, Montserrat), a böngésző alapértelmezetten elrejti a szöveget, amíg a fontfájl le nem töltődik (FOIT - Flash of Invisible Text), vagy egy rendszerbetűtípussal jeleníti meg, majd hirtelen átvált az egyedi betűtípusra (FOUT - Flash of Unstyled Text). Ez utóbbi komoly eltolódást okozhat, mert a két betűtípus karaktertávolsága és magassága eltér.
Alkalmazzuk a `font-display: swap;` deklarációt a CSS-ben, és töltsük be helyileg (self-host) a Google Fonts állományait ahelyett, hogy külső szerverről hívnánk be őket. Ezzel kiküszöböljük az extra DNS feloldási és TLS kézfogási időt.
A cookie banner és a dinamikus hirdetések helyfoglalása
Ha az eMag Marketplace-hez hasonlóan dinamikus bannereket futtatunk az oldalon, vagy a hazai adatvédelmi szabályok miatt kötelező GDPR cookie-sávot (pl. Cookiebot, Complianz) használunk, ezeknek az elemeknek előre le kell foglalni a helyet a CSS-ben.
```css
/ Placeholder a cookie bannernek a CLS elkerülésére /
.cookie-law-info-bar {
min-height: 120px;
contain-intrinsic-size: 0 120px;
content-visibility: auto;
}
```
---
3. Az INP (Interaction to Next Paint) megszelídítése
2024 márciusától az INP hivatalosan is átvette a FID (First Input Delay) helyét. Míg a FID csak az első interakciót mérte, az INP az egész látogatás alatt méri az oldal válaszkészségét. Ha a felhasználó rákattint egy legördülő menüre, de az oldal harmadik fél által behívott scriptek miatt éppen "fagyott" állapotban van, az INP érték drasztikusan megemelkedik.
| INP Érték (ms) | Felhasználói élmény minősítése | Konverziós hatás (becsült) |
| :--- | :--- | :--- |
| 200 alatt | Jó (Zöld) | Optimális konverzió, alacsony elhagyás |
| 201 - 500 | Javítandó (Sárga) | ~5-8% közötti lemorzsolódás az interakcióknál |
| 500 felett | Gyenge (Piros) | Akár 15-20%-os lemorzsolódás a fizetési tölcsérben |
A monstrum pluginek és a "Main Thread" blokkolása
A WordPress adminok hajlamosak minden apró funkcióra új plugint telepíteni. Egy átlagos magyar WooCommerce oldalon nem ritka a 35-50 aktív plugin sem. Ezek mindegyike saját JavaScript kódokat injektál a frontendbe, amelyek versengenek a böngésző egyszálú végrehajtási folyamatáért (Main Thread).
A legnagyobb bűnösök:
- A chat widgetek (Tawk.to, ManyChat, Facebook Messenger plugin).
- A mérőkódok rossz implementációja (közvetlenül a fejlécbe illesztett Facebook Pixel és Google Tag Manager kódok, amelyek szinkron módon futnak).
- A felesleges admin ajax hívások (pl. WooCommerce `wc-ajax=get_refreshed_fragments` hívása, ami minden oldalletöltésnél lefut, megkerülve a cache-t).
A `wc-ajax=get_refreshed_fragments` letiltása
Ez a funkció felelős azért, hogy ha a felhasználó egy termékkártyán a kosárba helyezésre kattint, a fejlécben lévő kosár ikon számlálója dinamikusan frissüljön. Ha azonban a webáruház látogatóinak többsége nem tárol el termékeket napokig a kosarában, ezt a hívást teljesen felesleges minden egyes sima blogbejegyzésen vagy kategóriaoldalon lefutatni.
Letiltása kóddal:
```php
add_action( 'wp_enqueue_scripts', 'ctr_disable_woocommerce_cart_fragments', 99 );
function ctr_disable_woocommerce_cart_fragments() {
if ( function_exists( 'is_woocommerce' ) && ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
wp_dequeue_script( 'wc-cart-fragments' );
}
}
```
---
Technikai mélyfúrás: Így törjük meg a kód-szemetet
Ha nem akarunk vagy nem tudunk egyből egy headless (szerveroldali renderelésű JS-alapú) frontend irányába mozdulni, meg kell tanulnunk szelektíven betölteni a WordPress beépített erőforrásait.
Szelektív script és stíluslap leiratkozás (Dequeuing)
A legtöbb plugin (pl. Contact Form 7, Mailchimp felugró ablakok, WP-Plugins) minden egyes aloldalra betölti a saját CSS és JS állományait, akkor is, ha az adott oldalon nincs is kapcsolatfelvételi űrlap kint.
Íme egy példa arra, hogyan tiltsuk le a Contact Form 7 scriptjeit mindenhol, kivéve a `/kapcsolat` oldalon:
```php
add_action( 'wp_enqueue_scripts', 'ctr_selective_cf7_loading', 99 );
function ctr_selective_cf7_loading() {
if ( ! is_page( 'kapcsolat' ) ) {
wp_dequeue_script( 'contact-form-7' );
wp_dequeue_style( 'contact-form-7' );
}
}
```
Ezzel a módszerrel egy átlagos WordPress oldal esetében a betöltendő hálózati kérések száma (Requests) könnyedén csökkenthető 120-ról 45-re, ami drámai módon csökkenti a CPU parse-olási idejét mobilon.
---
Esettanulmány: Hogyan hozott +14,2%-os konverziós növekedést az INP optimalizálás egy 250 millió HUF árbevételű lakberendezési webshopnál
A vizsgált alany egy hazai gyártású, egyedi bútorokat és kiegészítőket forgalmazó WooCommerce webáruház.
- Kiinduló állapot: WordPress 6.x + Elementor Pro, 44 aktív plugin, megosztott SSD-s magyar tárhely (havi 4 500 HUF értékben).
- Fő probléma: A Google Ads kampányok (havi 1,8 millió HUF hirdetési keret) magas visszafordulási arányt produkáltak mobilon (68,4%). A mobil konverziós arány megrekedt 1,12%-on.
- Mérések a diagnosztika során: LCP: 4,8 másodperc, CLS: 0,32, INP: 540 ms (kritikusan lassú).
A látogatók a mobiljukon rákattintottak a "Kosárba" gombra, de a telefon nem reagált azonnal. A felhasználók azt hitték, nem működik a gomb, ezért még 3-4 alkalommal rákattintottak, ami teljesen lefagyasztotta a böngészőt, így végül elhagyták az oldalt.
A végrehajtott beavatkozás lépései
- Hosting migráció: A webáruházat átköltöztettük egy dedikált erőforrású VPS-re (2 Core AMD EPYC, 4GB RAM - havi 12 000 HUF díjért), Redis cache-eléssel kiegészítve.
- Képoptimalizálás: Bevezettük a felhőalapú képkonverziót. Az összes termékkép automatikusan AVIF formátumot kapott mobileszközökön.
- JS és CSS leiratkozások: Megírtuk a szükséges `wp_dequeue` szabályokat. Az Elementor globális widgetjeinek és ikonjainak (FontAwesome) betöltését korlátoztuk, csak ott töltődnek be, ahol ténylegesen használatban vannak.
- Script késleltetés (Delay JS): A Google Analytics (Gtag), a Meta Pixel és a Hotjar scripteket áttettük késleltetett betöltésre. Ezek a scriptek csak akkor inicializálódnak, ha a felhasználó megmozdítja az egeret vagy megérinti a képernyőt (user interaction).
Az eredmények 3 hónap távlatában
| Mutató | Optimalizálás előtt | Optimalizálás után | Változás (%) |
| :--- | :--- | :--- | :--- |
| LCP | 4,8 s | 1,8 s | -62,5% |
| CLS | 0,32 | 0,04 | -87,5% |
| INP | 540 ms | 110 ms | -79,6% |
| Mobil konverziós arány | 1,12% | 1,45% | +29,4% (relatív növekedés) |
| Összesített konverziós növekedés | - | - | +14,2% (teljes bevételre vetítve) |
A webshop éves szinten 250 000 000 HUF árbevételt produkált a beavatkozás előtt. A konverziós arány javulása önmagában több mint 35 000 000 HUF extra árbevételt realizált azonos hirdetési büdzsé mellett. Az optimalizálási projekt egyszeri költsége (egy hazai szabadúszó szakértő/ügynökség átlagos 450 000 - 650 000 HUF közötti fejlesztési díja) kevesebb mint egy hét alatt teljesen megtérült.
---
Amit SOHA ne tegyél: A leggyakoribb WP-gyilkos "optimalizációs" hibák
A magyar KKV-szektorban uralkodó "barkács-szemlélet" miatt a marketingesek vagy maguk a cégvezetők gyakran saját kezűleg próbálják megoldani a sebességproblémákat. Ez szinte minden esetben katasztrófához vezet.
1. Több gyorsítótárazó (caching) plugin együttes használata
Gyakori kép, hogy egy WordPress oldalon egyszerre aktív a WP Rocket, az Autoptimize, a Litespeed Cache és még a webtárhely saját beépített bővítménye is. Ezek a pluginek ugyanazokat a HTML/CSS/JS manipulációkat próbálják elvégezni. Az eredmény: összeomló fizetési oldalak, meg nem jelenő képek, hibásan renderelődő mobilos menük és drasztikusan lelassuló admin felület az egymást felülíró adatbázis-lekérdezések és fájlgenerálások miatt.
- Szabály: Egy oldalon KIZÁRÓLAG egy darab komplex optimalizációs modul futhat. Ha LiteSpeed szerveren vagyunk, használjuk a LiteSpeed Cache-t. Ha Apache vagy Nginx fut alattunk, a WP Rocket vagy a FlyingPress a helyes választás.
2. A teljes JavaScript vakon történő késleltetése (Delay JS)
Sok "szakértő" bekapcsolja a "Delay JavaScript execution" funkciót a gyorsítótárazó pluginban, majd elégedetten nézi, hogy a PageSpeed Insights teszten 95+ pontot kap az oldal.
De mi történik a valóságban?
- A cookie-kezelő (Consent Mode v2) nem fut le azonnal, így a látogatók jelentős része úgy böngészik, hogy a Google Analytics nem mér semmit (drágul a CPA, mert vakon kampányolunk).
- A kosárba tétel gomb nem reagál az első koppintásra, mert a WooCommerce JS fájljai még nem töltődtek be. A felhasználó dühösen bezárja az oldalt, mielőtt az első interakció regisztrálásra kerülne.
- Szabály: Soha ne késleltessünk olyan scripteket, amelyek a közvetlen felhasználói interakcióhoz vagy a jogszabályi mérésekhez (consent) szükségesek.
---
Akcióterv: 7 lépés a zökkenőmentes Core Web Vitals eléréséhez
Ha szeretnéd, hogy a WordPress oldalad ne csak a szintetikus teszteken, hanem a valós felhasználói méréseken (CrUX) is átmenjen, kövesd ezt a szigorú implementációs listát:
- Válts prémium tárhelyre: Ha a TTFB (Time to First Byte) értéke meghaladja a 400 ms-ot, felejtsd el az 1500 forintos osztott tárhelyeket. Költöztesd át az oldalt hazai felhő alapú VPS-re (pl. Servergarden, Clouvis) vagy külföldi prémium WP-specifikus szolgáltatóhoz (pl. Kinsta, Rocket.net).
- Auditáld a betűtípusokat: Csökkentsd a használt fontcsaládok számát maximum 2-re, és csak a szükséges súlyokat (pl. Regular 400 és Bold 700) töltsd be. Tárold őket lokálisan WOFF2 formátumban.
- Implementáld a CSS kritikát (Critical CSS): Generálj kritikus CSS-t, amely beágyazottan (inline) töltődik be a fejlécben, míg a stíluslap többi része aszinkron módon kerül letöltésre. Ez drasztikusan javítja az LCP és FCP mutatókat.
- Tisztítsd meg az Asseteket: Telepítsd a Perfmatters vagy az Asset CleanUp plugint, és tiltsd le a nem használt CSS/JS fájlokat aloldalanként.
- Fixáld a képméreteket: Kényszerítsd ki a `srcset` és `sizes` attribútumok helyes használatát. Biztosíts megfelelő méretű képet a mobil (320px - 480px széles kijelzők), tablet és asztali változatoknak.
- Optimalizáld a méréseket: A tracking kódokat (GTM, Meta Pixel, Hotjar, TikTok Pixel) zárd ki a szinkron betöltésből. Használj szerveroldali mérést (Server-Side GTM), ha a büdzsé megengedi, mert ezzel tehermentesíted a kliens böngészőjét a leginkább.
- Monitorozz folyamatosan: Ne hagyatkozz az egyszeri mérésekre. Konfiguráld be a Google Search Console Core Web Vitals jelentését, és ellenőrizd heti rendszerességgel a valós felhasználói adatok (field data) trendjeit.
A Core Web Vitals optimalizálása nem egyszeri feladat, hanem folyamatos karbantartási munka. Minden új plugin telepítése, minden új marketing kampány mérőkódja potenciálisan ronthatja a mutatókat. Ha azonban a fenti struktúra szerint építed fel a folyamatokat, az oldalad hosszú távon is megtartja technikai előnyét a versenytársaiddal szemben – ami a nap végén közvetlenül a bankszámládon, az alacsonyabb ügyfélszerzési költségekben és a magasabb profitban fog realizálódni.
