Core Web Vitals a gyakorlatban: LCP, INP és CLS javítása WordPress oldalakon

A „gyors legyen az oldal” kívánság mindenkinél elhangzik, de amíg nem tudjuk mérni, mit jelent a gyorsaság, addig csak érzésekről beszélünk. A Google erre vezette be a Core Web Vitals mutatókat: három metrikát, amelyek a valódi felhasználói élmény három aspektusát mérik – a betöltést, a reakcióidőt és a vizuális stabilitást. Ezek a mutatók a Google rangsorolásában is szerepet kapnak, de ami még fontosabb: közvetlenül összefüggenek a visszafordulási aránnyal és a konverzióval.

A három mutató és a célértékek

• LCP (Largest Contentful Paint) – mennyi idő alatt jelenik meg a látható terület legnagyobb eleme (jellemzően a hero kép vagy a fő címsor). Jó: 2,5 másodperc alatt.
• INP (Interaction to Next Paint) – mennyi idő telik el egy felhasználói interakció (kattintás, érintés, billentyűleütés) és a következő képkocka megjelenítése között. 2024 márciusában váltotta a korábbi FID mutatót. Jó: 200 ms alatt.
• CLS (Cumulative Layout Shift) – mennyire „ugrál” az oldal tartalma betöltés közben. Jó: 0,1 alatt.

Fontos, hogy a Google a valós felhasználói adatok 75. percentilisét nézi, mobilon és asztalin külön. Vagyis nem elég, ha a te gyors gépeden, gyors neten jó az eredmény – a látogatók háromnegyedénél kell teljesülnie a célértéknek.

Labor- és terepadat: mit mérünk valójában?

A PageSpeed Insights két különböző adatot mutat. A felső rész (ha van elég forgalom) a terepadat, vagyis a Chrome felhasználói élményről szóló jelentéséből (CrUX) származó valós mérés az elmúlt 28 napból. Az alsó rész a laboradat: egy szimulált, lassított mobil környezetben futtatott Lighthouse-teszt. A Google rangsorolása a terepadatot veszi figyelembe; a laboradat a hibakereséshez hasznos. Ezért fordulhat elő, hogy a Lighthouse-pontszám 60, a Core Web Vitals mégis „megfelelt” – vagy fordítva.

LCP javítása

Az LCP-t négy részre bonthatjuk: a szerver válaszideje (TTFB), az LCP-erőforrás betöltésének késése, maga a letöltési idő, és a megjelenítés késése. WordPress oldalakon a leggyakoribb problémák és megoldások:

Lassú szerverválasz

Ha a TTFB önmagában 1 másodperc fölött van, az LCP-t nehéz 2,5 másodperc alá szorítani. Itt a teljes oldalas gyorsítótárazás (page cache) a leghatékonyabb lépés, ezt követi a PHP-verzió frissítése, egy objektum-gyorsítótár (Redis) beállítása, és szükség esetén egy jobb tárhely. A nehéz adatbázis-lekérdezéseket végző bővítményeket a Query Monitor segítségével lehet azonosítani.

Későn felfedezett hero kép

Klasszikus hiba, hogy a fő kép lazy loadingot kap, vagy CSS háttérképként van beállítva, így a böngésző csak későn fedezi fel. A megoldás: a hajtás feletti fő képről vedd le a loading="lazy" attribútumot, add hozzá a fetchpriority="high" attribútumot, és ha háttérképről van szó, töltsd elő egy <link rel="preload"> elemmel. Az oldalépítőkben (Elementor és társai) ez különösen gyakori, mert a hero szekciók háttérképe alapból CSS-ből töltődik.

Túl nagy képek

Egy 3000 pixel széles, 2 MB-os JPEG mobilon semmilyen gyorsítótárral nem lesz gyors. Használj modern formátumot (WebP vagy AVIF), helyes srcset és sizes attribútumokat, és ügyelj rá, hogy a szerver valóban a kijelzőhöz illő méretet szolgálja ki.

Renderelést blokkoló erőforrások

A fejlécben betöltött, nagy CSS- és JS-fájlok késleltetik az első megjelenítést. A kritikus CSS inline-olása, a nem kritikus szkriptek defer attribútummal való betöltése és a nem használt bővítmény-erőforrások oldalankénti kikapcsolása (például a kapcsolati űrlap szkriptje csak a kapcsolat oldalon töltődjön be) sokat javíthat. A webfontoknál a font-display: swap és a betűtípusok saját szerverről való kiszolgálása ajánlott.

INP javítása

Az INP a legnehezebben javítható mutató, mert a JavaScript futásának minőségén múlik. Ha a fő szál (main thread) épp egy hosszú feladattal van elfoglalva, a böngésző nem tud reagálni a felhasználó kattintására. A tipikus bűnösök WordPress oldalakon:

• Harmadik féltől származó szkriptek: chat widgetek, marketingpixelek, hőtérkép-eszközök, sütibannerek. Mindegyik a fő szálon fut. Vizsgáld felül, melyikre van valóban szükség, és a nem kritikusakat töltsd be késleltetve (például az első interakció után).
• Nehéz oldalépítő-oldalak: a nagyon mély DOM-szerkezet (több ezer elem) minden interakciónál drágábbá teszi az újrarajzolást. Érdemes egyszerűsíteni a szekciók egymásba ágyazását.
• Saját JavaScript: a hosszú feladatokat bontsd fel kisebb részekre, a nem azonnal szükséges munkát pedig engedd el a fő szálról (például requestIdleCallback vagy scheduler.yield() segítségével). Az eseménykezelőben először a vizuális visszajelzést add meg, a nehéz számítás jöhet utána.
• jQuery-alapú régi szkriptek: sok régi bővítmény minden görgetésnél vagy átméretezésnél drága műveleteket futtat. Ezeknél a throttle/debounce vagy a bővítmény lecserélése segít.

Az INP hibakereséséhez a Chrome DevTools Performance panelje a legjobb eszköz: rögzíts egy interakciót, és nézd meg, mely hosszú feladatok blokkolják a választ.

CLS javítása

A CLS-t okozó hibák általában a legkönnyebben javíthatók:

• Méret nélküli képek és videók: minden img és iframe kapjon width és height attribútumot, vagy CSS-ben aspect-ratio értéket, hogy a böngésző előre lefoglalhassa a helyet.
• Később beszúrt tartalom: sütibannerek, értesítési sávok, hirdetések, amelyek a tartalmat lefelé tolják. Ezeknek foglalj előre helyet, vagy jelenítsd meg őket a tartalom fölött lebegve (fixed pozícióval).
• Webfontok cseréje: ha a tartalék betűtípus és a webfont mérete nagyon eltér, a szöveg „ugrik”. A size-adjust és a hasonló metrikájú tartalék betűtípus választása segít.
• Animációk: csak transform és opacity tulajdonságokat animálj; a top, height vagy margin animálása elrendezés-eltolódást okoz.

Mérési folyamat, amit javaslunk

1. Nézd meg a Search Console „Alapvető webes vitals-mutatók” jelentését: melyik oldalcsoport és melyik mutató problémás.
2. A problémás oldalt vizsgáld PageSpeed Insightsszal, majd Chrome DevToolsban, mobil emulációval és lassított hálózattal.
3. Javíts sablonszinten, majd ellenőrizd laboradatokkal.
4. A terepadatok frissülése 28 napos ablakkal történik, ezért a javulás csak néhány hét alatt látszik meg teljesen – a Search Console-ban ezután jelezheted, hogy a javítás megtörtént.

Összegzés

A Core Web Vitals nem egy pontszám, amit egyszer „kimaxolunk”, hanem a felhasználói élmény mérőszáma, amit minden új bővítmény, szkript és dizájnelem befolyásol. Az eredmények megtartásához a rendszeres karbantartás is elengedhetetlen. A legtöbb WordPress oldalon néhány célzott javítással – gyorsítótár, helyesen kezelt hero kép, a harmadik féltől származó szkriptek rendbetétele – jelentős javulás érhető el. Ha szeretnéd, hogy átvilágítsuk az oldalad teljesítményét, vedd fel velünk a kapcsolatot.

A cikk szerzőjeMolnár Dániel

A MagicWeb alapítója. 2019 óta készít weboldalakat és webáruházakat debreceni és országos vállalkozásoknak – a tervezéstől az élesítésig.

Ismerj meg minket →