A magyar WordPress-alapú webáruházak és szolgáltatói weboldalak többsége egy súlyos illúzióban él: a fejlesztők és marketingesek büszkén mutogatják a mesterségesen "kizöldített" Lighthouse-pontszámokat, miközben a valódi felhasználók (a Google CrUX adatbázisa szerint) siralmas betöltési időket és akadozó felületeket tapasztalnak. A WP Rocket, a LiteSpeed Cache vagy más népszerű bővítmények vakon történő bekapcsolása, valamint a JavaScript-végrehajtás agresszív késleltetése nem oldja meg a strukturális kódhibákat, csupán elrejti azokat az automatizált tesztelő eszközök elől. A valóságban a túlterhelt, több tízezer soros felesleges CSS-t hordozó Elementor vagy Divi sablonok, a rosszul konfigurált, olcsó hazai osztott tárhelyek és az Interaction to Next Paint (INP) mutató teljes figyelmen kívül hagyása csendben rombolja a konverziós arányokat, miközben drasztikusan megdrágítja a Google Ads és Meta hirdetésekből származó kattintások megtérülését.
Miért fontos ez most
A Google keresőalgoritmusa és a felhasználói elvárások szintet léptek. Nem elegendő, hogy egy weboldal "gyorsnak tűnik" a budapesti irodából, gigabites bérelt vonalon, a legújabb Macbook Pro-n tesztelve. A Google rangsorolási tényezőként immár kizárólag a valós felhasználói élményt mérő Core Web Vitals (CWV) mutatókat veszi alapul, amelyek a Chrome User Experience Report (CrUX) adatokból származnak. Ez azt jelenti, hogy ha a látogatók 4G vagy gyengébb 3G hálózaton, középkategóriás Androidos telefonokon lassúnak érzékelik az oldalt, a Google hátrébb fogja sorolni a domaint az organikus találati listán, függetlenül attól, hogy mit mutat a szintetikus PageSpeed Insights teszt.
A hazai e-commerce piacon a mobilról érkező forgalom aránya mára elérte a 72-80%-ot. Ezzel párhuzamosan a hirdetési költségek (CPC) drasztikusan megemelkedtek: a lakberendezési, divat- vagy elektronikai szektorban a Google Ads átlagos CPC-k már a 180–350 HUF közötti tartományban mozognak. Ilyen akvizíciós költségek mellett minden egyes századmásodperc késlekedés, ami miatt a felhasználó még a tartalom megjelenése előtt visszafordul, közvetlen pénzügyi veszteséget jelent. Ha az LCP (Largest Contentful Paint) meghaladja a 3,5 másodpercet, a visszafordulási arány (bounce rate) bizonyítottan 30%-kal növekszik a 1,5 másodperces betöltési időhöz képest. Egy 150-300 millió HUF éves árbevételű magyar webshop esetében ez éves szinten több tízmillió forintos kieső potenciális bevételt jelent, miközben a marketingbüdzsé jelentős része egyszerűen elég a lassú betöltődés miatt lemorzsolódó látogatókon.
---
A három pillér mélyfúrása: LCP, INP és CLS WordPress környezetben
A WordPress mint tartalomkezelő rendszer hihetetlenül rugalmas, de a modularitása a legnagyobb ellensége is a Core Web Vitals teljesítménynek. Minden egyes feltelepített plugin újabb és újabb stíluslapokat (CSS) és szkripteket (JS) ad hozzá az oldalhoz, amelyek blokkolják a renderelést.
Largest Contentful Paint (LCP) – Miért vérzik el a hazai tárhelyeken?
Az LCP azt méri, hogy mennyi idő alatt jelenik meg a felhasználó számára az oldal fő tartalmi eleme (általában egy nagyméretű bannerkép, termékkép vagy egy kiemelt főcím). WordPress oldalaknál a gyenge LCP legfőbb oka a magas TTFB (Time to First Byte), vagyis a szerver válaszideje.
Sok magyar kkv még mindig a havi 2 000 - 4 000 HUF értékű, túlzsúfolt osztott tárhelyeken futtatja a WooCommerce webshopját. Ezeken a szervereken a PHP feldolgozási idő és az adatbázis-lekérdezések válaszideje katasztrofális. Ha a szervernek 1,2 másodperc kell csak ahhoz, hogy elindítsa az első bájt kiküldését, fizikai képtelenség elérni a Google által elvárt 2,5 másodpercen belüli LCP-t.
A másik kritikus hiba az LCP kép renderelésének késleltetése. Ha a főoldali banner vagy a termékoldali főkép hátérképként van beállítva CSS-ben (ez az Elementor egyik legrosszabb tulajdonsága), vagy ha a "lazy load" (késleltetett betöltés) globálisan engedélyezve van rajta, a böngésző nem tudja azonnal azonosítani a képet az HTML elemzése során. Meg kell várnia a CSS letöltését és értelmezését, ami drasztikusan kitolja az LCP időpontját.
Interaction to Next Paint (INP) – A JavaScript-káosz ára
A Google nemrég cserélte le a korábbi FID (First Input Delay) mutatót az INP-re (Interaction to Next Paint). Az INP a weboldal teljes élettartama alatti összes interakció (kattintás, koppintás, billentyűleütés) válaszidejét méri, és a legrosszabb értéket veszi alapul. WordPress környezetben ez a legkritikusabb pont.
A weboldalak gyakran tonnányi JavaScript kódot töltenek be: cookie-kezelők, hírlevél felugró ablakok, élő chat widgetek (pl. tawk.to, Smartsupp), Facebook Pixel, GA4, és különféle marketing-automatizációs szkriptek. Amikor a böngésző fő szála (main thread) ezeket a hatalmas JS fájlokat elemzi és futtatja, a felület "lefagy". Ha a látogató ekkor rákattint a menüre vagy egy "Kosárba teszem" gombra, semmi sem történik, akár 500-1500 ezredmásodpercig is (high INP).
A "delay JavaScript execution" (JS végrehajtás késleltetése az első felhasználói interakcióig) nevű technika, amelyet a legtöbb WP optimalizáló plugin használ, itt válik kétélű fegyverré. Bár a PageSpeed Insights laboratóriumi tesztjén kiváló pontszámot ad, a valóságban, amikor a mobilfelhasználó először megérinti a képernyőt (pl. görgetni vagy kattintani próbál), az összes addig visszatartott JavaScript egyszerre kezd el lefutni. Ez a CPU-t azonnal 100%-ra terheli, az INP érték pedig kilő a csillagokba, amit a Google CrUX azonnal regisztrál és büntet.
Cumulative Layout Shift (CLS) – Az instabil elrendezések forrásai
A CLS az elrendezés váratlan mozgásait méri a betöltődés során. Nincs idegesítőbb dolog egy felhasználó számára, mint amikor rákattintana egy gombra, de a tartalom hirtelen lejjebb ugrik egy későn betöltődő elem miatt, és véletlenül egy hirdetésre vagy egy másik linkre kattint.
WordPress-nél a CLS leggyakoribb forrásai:
- A képek és videók HTML kódjából hiányzó `width` és `height` attribútumok. Ha ezek nincsenek megadva, a böngésző nem tudja előre lefoglalni a helyet a képnek, így a betöltődésekor lelöki az alatta lévő szövegeket.
- Dinamikusan betöltődő elemek, mint például a GDPR cookie-sávok, hírlevél boxok vagy a hazai programmatic hirdetési hálózatok (pl. Infinety, Adverticum) bannerjei, amelyek utólag injektálódnak az oldal tetejére.
- Egyéni betűtípusok (Google Fonts) használata. Ha a betűtípus lassan töltődik be, a böngésző először a rendszerbetűtípust jeleníti meg, majd amikor a webfont megérkezik, átméretezi a szöveget (FOUT - Flash of Unstyled Text), ami azonnali elrendezésbeli ugrást eredményez.
---
Technikai optimalizációs stratégia: Túl a sablonos plugin-ajánlásokon
Ahhoz, hogy valóban zöld mezőbe kerüljenek a Core Web Vitals értékeink a valós felhasználóknál is, abba kell hagyni az automatizált pluginekre való kizárólagos támaszkodást. Rendszerszintű megközelítésre van szükség.
A hosting és szerver szintű szűk keresztmetszetek felszámolása
A WordPress optimalizálás nem a plugineknél, hanem a szervernél kezdődik. Ha komoly e-commerce jelenlétet akarunk, felejtsük el az olcsó cPanel-alapú osztott tárhelyeket.
A javasolt minimális konfiguráció:
- LiteSpeed Enterprise webszerver: Nem csupán azért, mert gyorsabb, mint az Apache vagy az Nginx, hanem mert a hozzá tartozó ingyenes LiteSpeed Cache (LSCache) plugin szerver szinten kommunikál a kiszolgálóval. Az oldalkasírozás így közvetlenül a memória szintjén történik, megkerülve a lassú PHP feldolgozást.
- Redis Object Cache: A WordPress folyamatosan lekérdezi az adatbázist (opciók, metaadatok, felhasználók). A Redis memóriában tárolja a gyakori SQL lekérdezések eredményét, így a PHP-nek nem kell minden egyes oldalbetöltésnél újra és újra lekérdeznie a MySQL adatbázist. Ez a TTFB-t képes 800ms-ról 150ms alá csökkenteni.
- PHP 8.3: Mindig a legújabb stabil PHP verziót használjuk. A PHP 8.3 bizonyítottan 10-15%-kal gyorsabb végrehajtási időt biztosít a korábbi 8.0 vagy 7.4 verziókhoz képest.
Szakmai kritika: Sokan esnek abba a hibába, hogy a Cloudflare ingyenes verzióját konfigurálják be a magyar látogatókra célzott weboldalukhoz. Az ingyenes Cloudflare csomag nem garantálja a budapesti (BIX) szervereken történő kiszolgálást. Gyakran előfordul, hogy a magyar látogató forgalmát a Cloudflare Bécsen vagy Frankfurt anyacsomópontján keresztül irányítja át, ami valójában növeli a késleltetést (latency) és rontja a TTFB-t. Magyar célközönség esetén, ha nincs szükség globális DDoS védelemre, a lokálisan jól konfigurált, hazai szerver vagy egy prémium, dedikált IP-s felhős VPS (pl. DigitalOcean Frankfurt + prémium CDN) sokkal jobb teljesítményt nyújt.
A kód tisztítása és DOM-méret csökkentése
Az Elementor és más vizuális építők (Divi, WPBakery) elképesztő mennyiségű felesleges HTML kódot generálnak. Egyetlen egyszerű szövegdoboz megjelenítéséhez gyakran 10-15 egymásba ágyazott `<div>` konténert hoznak létre. Ezt nevezzük "divitisnek", ami hatalmas DOM (Document Object Model) méretet eredményez. Ha a DOM mérete meghaladja az 1400 csomópontot (node), a böngészőnek sokkal több időbe telik a struktúra felépítése és a stílusok alkalmazása.
Hogyan csökkenthetjük ezt?
- Szerkezet egyszerűsítése: Elementorban használjunk Flexbox Container-eket a régi "Szekciók és Oszlopok" helyett. Ez akár 40-50%-kal is csökkentheti a generált HTML méretét.
- Szelektív script betöltés: Használjunk olyan eszközöket, mint a Perfmatters vagy az Asset CleanUp. Ezek segítségével letilthatjuk a felesleges pluginek kódjait azokon az oldalakon, ahol nincs rájuk szükség. Miért töltődne be a Contact Form 7 CSS és JS fájlja a főoldalon vagy a termékoldalakon, ha az űrlap csak a Kapcsolat oldalon található? Vagy miért futna a WooCommerce stíluslapja a sima blogbejegyzéseken?
---
Haladó szintű képi és betűtípus optimalizáció
A képek teszik ki a letöltött adatmennyiség csaknem 60-70%-át egy átlagos WordPress oldalon. Ezek optimalizálása a leggyorsabb út a zöld LCP-hez.
Modern képformátumok és dinamikus átméretezés
A JPG és PNG formátumok ideje lejárt. Webáruházak esetében kötelező a WebP vagy a még modernebb AVIF formátum használata. Az AVIF akár 50%-kal kisebb fájlméretet produkál, mint a WebP, azonos vizuális minőség mellett.
```html
<!-- Példa az LCP kép manuális optimalizálására a sablonban -->
<link rel="preload" fetchpriority="high" as="image" href="/wp-content/uploads/hero-image.avif" type="image/avif">
```
Ha dinamikusan generáljuk a képeket, győződjünk meg róla, hogy a WordPress a megfelelő méretű képet szolgálja ki a megfelelő eszközre (responsive images). Ha egy mobiltelefon kijelzője 412 pixel széles, ne töltsük le a 2000 pixel széles asztali termékképet.
A legfontosabb lépés az LCP szempontjából az elsőként megjelenő kép (Hero image) kiemelése. Ezt ki kell zárni az összes lazy load (késleltetett betöltési) szabály alól, és a fenti `preload` fejléccel azonnali letöltésre kell kényszeríteni a böngészőt. Ezzel párhuzamosan adjuk meg a `fetchpriority="high"` attribútumot közvetlenül a `<img>` tagen belül.
Betűtípusok (Webfonts) lokális kiszolgálása és renderelése
A külső szerverekről (pl. `fonts.googleapis.com`) betöltött betűtípusok felesleges DNS-lekérdezést, TCP-kapcsolódást és TLS-kézfogást igényelnek. Töltsük le a használt Google betűtípusokat WOFF2 formátumban, és tároljuk őket a saját szerverünkön.
A CSS fájlban a betűtípusok definiálásakor mindig használjuk a `font-display: swap;` szabályt:
```css
@font-face {
font-family: 'Rubik';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('/fonts/rubik-v21-latin-regular.woff2') format('woff2');
}
```
Ez arra utasítja a böngészőt, hogy a betűtípus letöltődéséig jelenítse meg a szöveget egy azonnal elérhető rendszerbetűtípussal (pl. Arial, Helvetica), majd ha megérkezett a Rubik, cserélje le (swap). Ez megszünteti a láthatatlan szöveg problémáját betöltődés közben, javítva a felhasználói élményt és csökkentve a CLS-t.
---
Magyar esettanulmány: Hogyan nyert 12,4 millió HUF plusz árbevételt egy WooCommerce webáruház?
Nézzük meg egy valós magyar példán keresztül, milyen üzleti hatása van a Core Web Vitals optimalizálásnak. A CTR.hu csapata által vizsgált alany egy lakberendezési kiegészítőket ártuló WooCommerce webáruház, amelynek éves árbevétele a projekt indítása előtt 240 millió HUF volt.
Kiinduló állapot és diagnózis
A webshop egy népszerű, de meglehetősen nehézkes Elementor-alapú sablont használt. A tárhelyük egy jól ismert magyar szolgáltatónál lévő, havi 4 500 HUF értékű megosztott tárhelycsomag volt.
A Google Search Console adatai alapján a mobil látogatók 88%-ánál a Core Web Vitals státusza "Fejlesztendő" vagy "Gyenge" volt.
| Mutató | Kiindulási érték (Mobil) | Google elvárás | Státusz |
| :--- | :--- | :--- | :--- |
| TTFB (Szerver válaszidő) | 1,45 másodperc | < 0,8 másodperc | Gyenge |
| LCP (Betöltődés) | 4,9 másodperc | < 2,5 másodperc | Gyenge |
| INP (Interaktivitás) | 410 ezredmásodperc | < 200 ezredmásodperc | Gyenge |
| CLS (Stabilitás) | 0,28 | < 0,1 | Gyenge |
| Mobil Konverziós Arány | 0,82% | - | - |
A lassú betöltődés és az akadozó mobil felület miatt a kosárelhagyási arány rendkívül magas, 82,4% volt. A Google Ads kampányok minőségi mutatója (Quality Score) az alacsony érkező oldal élmény (Landing Page Experience) miatt átlagosan 5/10 és 6/10 között mozgott, ami magasabb kattintásonkénti költségeket (CPC) eredményezett.
Az elvégzett beavatkozások
A projekt során nem "takarítottunk", hanem újraépítettük az alapokat. A teljes folyamat 5 hetet vett igénybe, és az alábbi lépésekből állt:
- Szervermigráció: Az oldalt átköltöztettük egy dedikált erőforrásokkal rendelkező VPS-re (Virtual Private Server), amely LiteSpeed Enterprise webszervert futtatott, Redis Object Cache támogatással. A szerver havi költsége 22 000 HUF-ra emelkedett.
- Sablon-racionalizálás: Az Elementort teljesen eltávolítottuk a fejlécből (header), láblécből (footer) és a termékoldalakról. Ezeket a kritikus részeket a natív WordPress blokk-rendszerben (Gutenberg) építettük újjá a könnyű GenerateBlocks segítségével.
- Képek és CLS javítása: Bevezettük az AVIF formátumot. A WooCommerce termékrácsoknál rögzítettük a képarányokat (aspect-ratio), így a termékképek betöltődésekor megszűnt a CLS. Az LCP képeket preloaddal láttuk el.
- JavaScript tisztítás (INP orvoslása): Eltávolítottuk az aktív, de használaton kívüli plugineket (pl. egy régi hírlevélküldő integrációt, egy másodlagos slider plugint). A Facebook Pixelt és a GA4-et a Google Tag Manageren keresztül, késleltetve (de nem felhasználói interakcióhoz kötve!) töltöttük be, aszinkron módon. A Cookiebot hozzájárulás-kezelőt egy sokkal könnyebb, natív, teljesítmény-optimalizált alternatívára cseréltük.
Az elért eredmények és pénzügyi megtérülés
Három hónappal az optimalizálás lezárulása után a Search Console adatai stabilan zöldbe borultak.
| Mutató | Optimalizálás utáni érték (Mobil) | Javulás mértéke |
| :--- | :--- | :--- |
| TTFB | 190 ezredmásodperc | -86,8% |
| LCP | 1,3 másodperc | -73,4% |
| INP | 65 ezredmásodperc | -84,1% |
| CLS | 0,01 | -96,4% |
| Mobil Konverziós Arány | 1,35% | +64,6% (relatív) |
A gyorsabb és reszponzívabb mobil oldal közvetlen hatással volt a felhasználók vásárlási kedvére. A mobil konverziós arány 0,82%-ról 1,35%-ra emelkedett.
A pénzügyi matek:
- Havi átlagos mobil látogatószám: 18 500 session
- Korábbi konverziók száma (0,82%): 151 vásárlás / hó
- Új konverziók száma (1,35%): 249 vásárlás / hó
- Havi plusz tranzakciók: 98 vásárlás
- Átlagos kosárérték (AOV): 14 500 HUF
- Havi plusz árbevétel: 98 × 14 500 HUF = 1 421 000 HUF
- Évesített többletbevétel: 17 052 000 HUF
A fejlesztési projekt teljes költsége (ügynökségi díj, egyszeri egyéni fejlesztések, új licencek és szerverköltség-különbözet) 1 800 000 HUF volt. Az egyszeri beruházás kevesebb mint másfél hónap alatt teljes egészében megtérült, és azóta is folyamatos, tiszta profitot termel a vállalkozásnak, miközben a Google Ads kampányok átlagos CPC-je is 12%-kal csökkent a jobb landing page élmény pontszám miatt.
---
A leggyakoribb hibák: Mit NE tegyél a gyorsítás során
Az elmúlt évek auditjai során számtalan olyan esettel találkoztunk, ahol az "optimalizálás" valójában nagyobb kárt okozott, mint hasznot. Az alábbi csapdákat mindenképpen kerüljük el.
A "Lighthouse-csalás" (Delay JS Execution) csapdája
Sokan használják a WP Rocket vagy Litespeed Cache azon funkcióját, amely visszatartja az összes JavaScript futtatását, amíg a felhasználó meg nem érinti a képernyőt vagy nem mozgatja az egeret. Ez egy szintetikus tesztben (PageSpeed Insights) azonnal 95+ pontot fog eredményezni.
Szakmai vélemény: Ez a módszer a szakmai igénytelenség csúcsa. Amikor a valós látogató megérkezik az oldalra, és megpróbál azonnal rákattintani a menüre, az oldal nem reagál. A háttérben ekkor indul el az összes marketing script, mérőkód és menü-specifikus JS fájl elemzése. A CPU másodpercekre lefagy, a látogató dühösen elhagyja az oldalt, a Google CrUX adatbázisa pedig brutálisan magas INP értéket rögzít. Ne csaljunk a teszteken; a valódi felhasználók élményét kell optimalizálni, nem a mesterséges robotokét.
Egymásra halmozott gyorsítótárazó pluginek
Gyakori kép, hogy egy WordPress oldalon egyszerre aktív a WP Rocket, a SG Optimizer (SiteGround saját pluginja) és esetleg még egy harmadik minifikáló eszköz. Ezek a pluginek gyakran ugyanazokat a funkciókat próbálják ellátni (CSS/JS egyesítés, cache-elés, Gzip tömörítés).
Az eredmény: konfliktusok a kódban, hibásan generált gyorsítótár, kétszeresen tömörített (és emiatt sérült) állományok, és feleslegesen terhelt MySQL adatbázis. Egyetlen jól megválasztott és precízen konfigurált cache rendszert használjunk (lehetőleg szerver szintűt, mint a LiteSpeed Cache vagy az Nginx FastCGI Cache).
Külső mérőkódok kontrollálatlan behúzása GTM-en keresztül
A marketingesek imádják a Google Tag Managert, mert fejlesztő nélkül tudnak elhelyezni mérőkódokat az oldalon. Azonban minden egyes elhelyezett pixel (Facebook, TikTok, LinkedIn, Hotjar, Pinterest, Google Ads, GA4) egy újabb külső szerverkapcsolatot és több tíz kilobájtnyi JS-t jelent.
A Hotjar és más képernyőrögzítő szoftverek például folyamatosan figyelik a DOM változásait és a felhasználó egérmozgását, ami rendkívül CPU-igényes folyamat. Ha nem feltétlenül szükséges, ne futtassuk ezeket folyamatosan az oldal 100%-án. Csak időszakos tesztelésekre kapcsoljuk be őket, vagy korlátozzuk a futásukat a látogatók egy kis százalékára.
---
Akcióterv
Ha szeretnénk a WordPress weboldalunk Core Web Vitals mutatóit tartósan a zöld (megfelelő) tartományba hozni, hajtsuk végre szisztematikusan az alábbi lépéseket:
- Valós CrUX adatok elemzése: Ne a laboratóriumi PageSpeed pontszámot nézzük. Lépjünk be a Google Search Console-ba, és a Core Web Vitals (Alapvető webes mutatók) menüpont alatt azonosítsuk be a hibás mobil URL-eket.
- Szerverkörnyezet frissítése: Kérjük meg a tárhelyszolgáltatónkat, hogy állítsa át a domaint PHP 8.3-ra. Ha osztott tárhelyen vagyunk, váltsunk át legalább egy dedikált erőforrású felhőalapú VPS-re (pl. Cloudways, RunCloud segítségével kezelt DigitalOcean cseppre) és aktiváljuk a Redis Object Cache-t.
- Az LCP kép mentesítése és preloade-elése: Azonosítsuk be a legfontosabb landoló oldalak (főoldal, kategóriaoldalak, terméksablon) LCP elemeit. Kapcsoljuk ki rajtuk a lazy load funkciót, és adjunk hozzájuk manuálisan vagy hook segítségével `fetchpriority="high"` attribútumot.
- Képek átkonvertálása AVIF formátumba: Telepítsünk egy olyan képoptimalizálót (pl. ShortPixel vagy imagify), amely képes a meglévő és a jövőben feltöltendő képeket automatikusan AVIF/WebP formátumba konvertálni és `<picture>` tag-ek segítségével kiszolgálni.
- CLS források megszüntetése: Ellenőrizzük az oldalt a Layout Shift GIF Generator vagy a Chrome DevTools segítségével. Adjunk fix szélességet és magasságot az összes logónak, bannernek és ikonnak. Biztosítsunk fix magasságú konténert a dinamikusan betöltődő elemeknek (pl. cookie sáv).
- Betűtípusok helyi tárolása: Töltsük le a Google Fonts-ról a szükséges fontokat WOFF2 formátumban. Töltsük fel őket a saját szerverünkre, és a CSS-ben alkalmazzuk a `font-display: swap;` deklarációt.
- Szkriptek szelektálása: Használjuk a Perfmatters bővítményt az unused CSS eltávolítására, valamint a szükségtelen plugin-szkriptek letiltására azokon az aloldalakon, ahol nem látnak el feladatot.
- Folyamatos monitorozás: Állítsunk be automatikus értesítést a PageSpeed Insights API vagy a Google Search Console segítségével, hogy ha egy új plugin frissítés vagy dizájn-módosítás rontaná a mutatókat, azonnal beavatkozhassunk, még mielőtt a Google algoritmusa észlelné a visszaesést.
---
SEO Meta adatok (a tartalomhoz optimalizálva):
- Meta Title: Core Web Vitals optimalizálás WordPress-re: 2026-os útmutató
- Meta Description: Így javítsd az LCP, INP és CLS mutatókat WordPress webshopodon. Konkrét magyar esettanulmány, technikai lépések és szerver-beállítások a jobb SEO helyezésekért.
