
A Google 2024-ben és 2025-ben is egyértelművé tette: a felhasználói élmény (UX) nem csupán egy kényelmi funkció, hanem kritikus rangsorolási tényező. A Core Web Vitals mutatók – az LCP, a CLS és az immár hivatalos INP – mérik azt, hogy egy weboldal mennyire gyors, stabil és válaszkész.
Sok fejlesztő számára ezek a számok ijesztőnek tűnhetnek a Search Console felületén, de a javításuk nem igényel mindig teljes kódújraírást. Ebben a cikkben azokra a gyors beavatkozásokra fókuszálunk, amelyekkel látványos javulást érhetsz el anélkül, hogy hetekre elmerülnél a technikai adósságok tengerében. Ha eleged van a piros jelzésekből, ez az útmutató neked szól.
Az LCP azt méri, mennyi idő alatt jelenik meg az oldal legnagyobb látható tartalmi eleme (általában egy hős-kép vagy egy nagy címsor).
fetchpriority="high" attribútummal. Ez jelzi a böngészőnek, hogy ezt az erőforrást minden mást megelőzve kell letöltenie. kódot a head szekcióban.Szakértői tipp: Gyakori hiba a „Lazy Load” alkalmazása az LCP elemre. Soha ne használj
loading="lazy"attribútumot az „above-the-fold” (hajtás feletti) képeken, mert ez mesterségesen késlelteti a megjelenítést!
A CLS a bosszantó „ugrálásokat” méri az oldalon töltődés közben. Senki nem szereti, ha egy hirtelen betöltődő hirdetés miatt rossz gombra kattint.
width és height attribútumot a képeknek a HTML-ben. A modern böngészők ebből számolják ki az aspect ratiót (oldalarányt).font-display: swap; szabályt. Ez megakadályozza, hogy a szöveg láthatatlan maradjon (FOIT), amíg a webfont megérkezik. konténerrel foglald le a helyüket előre.
3. INP (Interaction to Next Paint): Az új király
2024 márciusától az INP váltotta fel az FID-t. Ez a mutató azt méri, hogy az oldal milyen gyorsan reagál a felhasználói interakciókra (kattintás, gépelés) a teljes látogatás alatt.
Fejlesztői beavatkozások az INP javítására:
- Long Taskok darabolása: Ha egy JavaScript függvény futása meghaladja az 50 ms-ot, az már blokkolja a főszálat. Használd a
setTimeout() vagy a modern scheduler.yield() megoldást a feladatok darabolására.
- Input Delay csökkentése: Vizsgáld meg, hogy a harmadik féltől származó scriptek (analitika, chat botok) nem foglalják-e le a CPU-t pont akkor, amikor a felhasználó cselekedne.
- Debouncing és Throttling: Gördítésnél vagy keresőmezőbe gépelésnél alkalmazz korlátozást a függvényhívásokra, hogy ne terheld túl az eseménykezelőt.
4. Képoptimalizálás mesterfokon: Több, mint méretcsökkentés
A modern webes környezetben a képek felelősek az átvitt adatmennyiség több mint 60%-áért. Az LCP javításához nem elég a tömörítés; intelligens kiszolgálásra van szükség.
A Responsive Images és a srcset ereje
Ne kényszerítsd a mobilfelhasználókat asztali méretű képek letöltésére. Használd a srcset attribútumot, amellyel a böngésző a kijelző felbontásához leginkább passzoló forrást választja ki:
HTML
Modern formátumok: AVIF vs. WebP
Bár a WebP már iparági sztenderd, az AVIF még jobb tömörítési rátát kínál (átlagosan 20%-kal hatékonyabb a WebP-nél). A legjobb gyakorlat a elem használata, amely fallback megoldást nyújt a régebbi böngészőknek.
5. JavaScript végrehajtási idő: A csendes INP gyilkos
Hiába tölt be gyorsan az oldal, ha a főszál (main thread) hosszú másodpercekig foglalt. Amikor a felhasználó kattint, de nem történik semmi, az INP értéked az egekbe szökik.
Harmadik féltől származó scriptek (Third-party JS)
A Facebook Pixel, a Hotjar vagy a különféle chat-alkalmazások gyakran a legrosszabbkor „rabolják el” a processzort.
- Auditálás: Használd a Chrome DevTools Bottom-Up fülét a CPU-t leginkább terhelő scriptek azonosítására.
- Partytown könyvtár: Egy innovatív megoldás, amely a harmadik féltől származó scripteket egy Web Workerbe helyezi át, így felszabadítja a főszálat az interakciók számára.
Kód-szétválasztás (Code Splitting)
Ne töltsd be a teljes JavaScript csomagot a kezdőlapon. A modern frameworkök (React, Vue, Next.js) lehetővé teszik a dinamikus importálást, így csak az a kód fut le, amire az adott aloldalon valóban szükség van.
6. CSS kritikus út (Critical CSS) optimalizálása
A böngésző nem kezdi el az oldal renderelését, amíg az összes be nem töltődött. Ez a blokkoló tényező drasztikusan növelheti az LCP-t.
Inline Critical CSS technika
A megoldás az, hogy a hajtás feletti (above-the-fold) rész megjelenítéséhez szükséges minimális CSS-t közvetlenül a HTML részébe ágyazzuk ( tagok közé). A maradék, „nehéz” CSS fájlt pedig aszinkron módon töltjük be:
HTML
Ez a módszer azonnali vizuális visszajelzést ad a felhasználónak, miközben a háttérben töltődik a teljes stíluslap.
7. Szerveroldali válaszidő (TTFB) és a tartalomelosztás
Bár a Core Web Vitals kliensoldali mutató, az alapja a TTFB (Time to First Byte). Ha a szervered lassú, az összes többi mutatód is szenvedni fog.
Edge Computing és HTTP/3
2026-ban már alapelvárás a HTTP/3 (QUIC) protokoll használata, amely csökkenti a kapcsolódási időt a szerver és a kliens között. Emellett a CDN-ek (mint a Cloudflare vagy Vercel Edge) használatával a tartalom a felhasználóhoz fizikailag legközelebbi szerverről szolgálható ki.
Adatbázis-lekérdezések és gyorsítótárazás
Egy lassú SQL lekérdezés másodperceket adhat az LCP-hez. Alkalmazz:
- Object Caching-et (pl. Redis), hogy a gyakori lekérdezések ne terheljék az adatbázist.
- Stale-while-revalidate stratégiát, amely a régi tartalmat mutatja meg a felhasználónak, miközben a háttérben frissíti azt a szerveren.
Összehasonlító táblázat: Core Web Vitals határértékek 2026-ban
Mutató Jó (Zöld) Javítandó (Sárga) Gyenge (Piros) LCP (Betöltés) < 2.5s 2.5s – 4.0s > 4.0s CLS (Stabilitás) < 0.1 0.1 – 0.25 > 0.25 INP (Interakció) < 200ms 200ms – 500ms > 500ms
Egyedi perspektíva: A „Perceived Performance” pszichológiája
Sokan elkövetik azt a hibát, hogy csak a számokat nézik a Lighthouse-ban. Azonban létezik egy „észlelt sebesség” is. Egy trükk, amit kevesen alkalmaznak: használj Skeleton Screen-eket (vázlatos betöltőképernyőket) a nehéz adatok betöltésekor. Bár ez nem javítja közvetlenül a technikai LCP-t, drasztikusan csökkenti a felhasználók lemorzsolódását és javítja az oldal hitelességét, ami közvetett módon hat a SEO-ra.
Gyakori kérdések (FAQ)
Milyen eszközt használjak a méréshez?
A legpontosabb adatokat a PageSpeed Insights és a Chrome DevTools „Performance” füle adja. A Search Console „Core Web Vitals” jelentése pedig a valós felhasználói adatokat (CrUX) mutatja.
Mennyi idő alatt látszódik a javítás a Google-ben?
A Google 28 napos gördülő átlagot használ. Ha ma kijavítod a hibákat, körülbelül egy hónap múlva fogod látni a teljes zöldülést a Search Console-ban.
A WordPress oldalaknál is működnek ezek?
Igen, sőt! A legtöbb gyorsítótárazó bővítmény (mint a WP Rocket) már kínál specifikus beállításokat az LCP és CLS optimalizálására.
Kezdd a legkönnyebb győzelmekkel
A Core Web Vitals javítása nem egyszeri feladat, hanem egy folyamatos karbantartási folyamat. Kezdd a legkönnyebb győzelmekkel: optimalizáld a hős-képet, adj magasságot a konténereknek, és vizsgáld felül a JavaScript futási idejét.
Készen állsz a zöld jelzésre? Futtass le egy mérést a PageSpeed Insights-on, válaszd ki a legrosszabbul teljesítő mutatót, és alkalmazd a fenti gyors beavatkozások egyikét még ma!