Core Web Vitals javítás: gyakorlati útmutató vállalkozóknak

Ha az oldalad lassan tölt be, vagy a Google Search Console piros vagy sárga jelzéseket mutat a Core Web Vitals riportban, nem vagy egyedül. A Core Web Vitals három mérőszám együttese (LCP, INP és CLS), amelyek azt mérik, milyen gyorsan jelenik meg a tartalom, milyen gyorsan reagál az oldal a felhasználói interakciókra, és mennyire stabil a vizuális elrendezés betöltés közben. A Google ezeket a mutatókat is figyelembe veszi a rangsorolásnál, de a valódi tét nem a keresőmotor, hanem a látogató: egy lassú vagy ugráló oldalról a felhasználók egyszerűen elmennek.

Ez az útmutató lépésről lépésre végigvezet azon, hogyan ismerd fel a problémát, hogyan mérd fel pontosan, és milyen sorrendben érdemes javítani, függetlenül attól, hogy egyedi fejlesztésű oldalad van, vagy WordPress alapon fut a vállalkozásod weboldala.

Milyen jelek mutatják, hogy gond van a Core Web Vitals mutatóiddal?

Sok vállalkozó akkor szembesül a problémával, amikor már késő: csökken a konverzió, nő a visszafordulási arány, vagy egy ügynökségi audit rámutat a hibákra. Az alábbi jelek korai figyelmeztetést adhatnak:

• A főoldal vagy a termékoldalak betöltése láthatóan lassabb mobilon, mint asztali gépen.
• A Google Search Console "Core Web Vitals" jelentésében URL-ek szerepelnek "Gyenge" vagy "Javítandó" státusszal.
• A látogatók panaszkodnak, hogy a gombok, menük "ugrálnak" vagy nem reagálnak azonnal érintésre.
• A hirdetési kampányok landing oldalain magas a Google Ads minőségi mutatóban a "oldalélmény" figyelmeztetés.
• A Google Analytics adatokban magas a kilépési arány az első néhány másodpercben.
• Termékkatalógus vagy blog oldalaidon a képek betöltésekor a szöveg elmozdul, amíg a kép meg nem jelenik.

Ha ezek közül akár csak kettő ismerős, érdemes elvégezni egy alapos önellenőrzést, mielőtt bármilyen technikai módosításba kezdenél.

Gyors önellenőrzés: mérd meg pontosan, hol tartasz

Mielőtt bármit javítanál, tudnod kell, pontosan mi a baj. A három Core Web Vitals mutató a következő:

LCP (Largest Contentful Paint): azt méri, mennyi idő alatt jelenik meg a képernyőn a legnagyobb, legfontosabb tartalmi elem (jellemzően egy hero kép, banner vagy címsor). A célérték 2,5 másodperc alatt van.

INP (Interaction to Next Paint): azt méri, mennyi idő telik el egy felhasználói interakció (kattintás, érintés, gépelés) és a látható válasz között. A célérték 200 ezredmásodperc alatt van. (Ez váltotta fel 2024-ben a korábbi FID mutatót.)

CLS (Cumulative Layout Shift): azt méri, mennyire mozdul el váratlanul az oldal elrendezése betöltés közben. A célérték 0,1 alatt van.

Fontos feltételezés, amit érdemes tisztázni: ezek az értékek jellemzően valós felhasználói adatokból (úgynevezett mezei adatokból) származnak, egy 28 napos gördülő átlag alapján, nem egyetlen laboratóriumi teszt eredményéből. Ez azt jelenti, hogy egy friss javítás hatása csak néhány hét múlva látszik meg teljesen a hivatalos riportokban, még akkor is, ha a teszteszközök azonnal jobb eredményt mutatnak.

A méréshez három forrást érdemes kombinálni:

1. PageSpeed Insights: egyetlen URL beírásával megmutatja a labor és a mezei adatokat is, konkrét javítási javaslatokkal.
2. Search Console Core Web Vitals jelentés: az egész domain szintjén, URL-csoportosítva mutatja meg, mely oldaltípusok érintettek.
3. Valódi eszközön történő tesztelés: egy középkategóriás Android telefon és egy gyengébb mobilnet szimulálása gyakran drámaian más képet mutat, mint egy gyors irodai laptop.

Ha 10-nél több hasonló felépítésű oldalad van (például termékoldalak egy webáruházban), elég néhány reprezentatív mintát megvizsgálni, a legtöbb probléma sablonszinten jelentkezik, nem egyedi oldalanként.

A leggyakoribb problémák és javításuk, fontossági sorrendben

Nem minden hiba egyformán sürgős. Az alábbi sorrend azon alapul, hogy tapasztalataink szerint melyik javítás hozza a legnagyobb elmozdulást a legkevesebb munkával.

1. Képek optimalizálása. Ez szinte mindig a legnagyobb LCP-javulást hozza. A tömörítetlen, túl nagy felbontású képek a leggyakoribb oka a lassú betöltésnek. Váltás modern formátumra (WebP vagy AVIF), megfelelő méretezés a tényleges megjelenítési mérethez, és a fő kép (hero image) betöltésének priorizálása gyakran önmagában másodpercekkel csökkenti az LCP-t.

2. Szerverválasz idő és tárhely. Ha a szerver lassan válaszol az első kérésre (magas TTFB), semmilyen frontend optimalizálás nem old meg mindent. Egy alulméretezett osztott tárhely gyakran szűk keresztmetszet, különösen forgalmi csúcsokban. Ilyenkor a megoldás lehet gyorsítótárazó réteg bevezetése, jobb hosting csomagra váltás, vagy CDN (tartalomkiszolgáló hálózat) használata.

3. Renderelést blokkoló JavaScript és CSS. Minden olyan szkript vagy stíluslap, amely megakadályozza az oldal azonnali megjelenítését, rontja mind az LCP-t, mind az INP-t. A megoldás a kritikus CSS beágyazása, a nem sürgős szkriptek késleltetett vagy aszinkron betöltése, és a felesleges kód eltávolítása.

4. Betűtípusok betöltése. A külső betűtípus-szolgáltatásoktól (webfontoktól) érkező, rosszul kezelt betöltés szöveg-eltűnést vagy elrendezés-ugrást okozhat. A font-display: swap beállítás és a betűtípusok előzetes betöltése (preload) sokat segít.

5. Harmadik féltől származó szkriptek. Statisztikai kódok, chat widgetek, marketing pixel-ek gyakran feleslegesen sok erőforrást emésztenek fel. Érdemes rendszeresen átnézni, melyik szkriptre van valóban szükség, és a nem kritikusakat késleltetve betölteni.

6. Elrendezés stabilitása. A CLS javításának leggyakoribb módja, hogy minden képhez és beágyazott elemhez (hirdetés, videó) explicit szélességet és magasságot adunk meg, hogy a böngésző már betöltés előtt helyet tudjon foglalni számára.

WordPress esetén ehhez néhány platform-specifikus pont is társul:

• Plugin túlterhelés: minél több plugin fut, annál nagyobb az esély felesleges JavaScript és CSS betöltésére minden oldalon, még ott is, ahol nincs rájuk szükség.
• Sablon (téma) választás: egyes prémium témák rengeteg beépített funkciót töltenek be alapból, amelyek 90 százalékát a legtöbb oldal soha nem használja.
• Gyorsítótárazó plugin: egy jól beállított cache plugin (oldal szintű és böngésző szintű gyorsítótárazással) az egyik legköltséghatékonyabb javítás.
• Képoptimalizáló plugin: automatikusan tömöríti és modern formátumra konvertálja a feltöltött képeket, anélkül hogy manuálisan kellene minden fájlt kezelni.
• Adatbázis karbantartás: a felhalmozódott revíziók, spam hozzászólások és ideiglenes adatok idővel lassítják az adatbázis-lekérdezéseket, ami közvetlenül a szerverválasz idejét rontja.

Gyakorlati példa: hogyan gyorsítottunk fel egy tipikus WordPress webáruházat

Nézzünk egy konkrét, jellemző esetet. Egy kézműves szappanokat és testápolókat áruló, körülbelül 40 terméket kínáló WordPress alapú webáruház a következő kiindulási állapotból indult:

• LCP: 4,8 másodperc mobilon
• INP: 340 ezredmásodperc
• CLS: 0,28

A vizsgálat során három fő problémát azonosítottunk. Először, a termékképek eredeti, fényképezőgépből származó felbontásban kerültek feltöltésre, gyakran 3-4 megabájtos fájlméretben. Másodszor, öt aktív plugin közül kettő (egy közösségimédia-widget és egy régi SEO bővítmény) olyan szkripteket töltött be minden oldalon, amelyekre valójában csak egy-két aloldalon volt szükség. Harmadszor, a termékkártyák képeihez nem volt megadva fix méretarány, ezért minden betöltéskor elmozdult körülöttük a szöveg.

A beavatkozás lépései a következők voltak:

1. Az összes termékkép automatikus tömörítése és WebP formátumra konvertálása, a fájlméretek átlagosan 78 százalékkal csökkentek.
2. A felesleges plugin eltávolítása, a megmaradó funkciók egy könnyebb, célzottabb megoldással váltása.
3. Fix width és height attribútum hozzáadása minden termékképhez, valamint egy modern gyorsítótárazó plugin bevezetése.
4. A hero szekció háttérképének priorizált betöltése, a nem kritikus JavaScript késleltetése.

Négy héttel később, amikor a mezei adatok már stabilizálódtak, az eredmény a következő volt:

• LCP: 2,1 másodperc mobilon
• INP: 145 ezredmásodperc
• CLS: 0,04

A webáruház tulajdonosa emellett azt is jelezte, hogy a mobilos vásárlási folyamat befejezési aránya érzékelhetően javult, bár ezt érdemes fenntartással kezelni, mivel más tényezők (szezonalitás, kampányok) is hatással lehettek rá egyidejűleg. Ez a példa jól mutatja, hogy nem szükséges teljes újrafejlesztés: a legtöbb esetben három-négy célzott beavatkozás is látványos javulást hoz.

Mi legyen a következő lépésed?

A Core Web Vitals javítása ritkán egyetlen csodamegoldáson múlik, inkább néhány jól megválasztott, prioritás szerint elvégzett lépésen. Ha most kezded, a legjobb kiindulópont a mérés: nézd meg a Search Console riportodat, futtass egy PageSpeed Insights tesztet a legfontosabb oldaladon, és azonosítsd, melyik mutató (LCP, INP vagy CLS) a leggyengébb. Onnantól a fent bemutatott prioritási sorrend alapján haladva már az első két-három javítás is érdemi különbséget hozhat.

Ha nem szeretnél egyedül belevágni a technikai részletekbe, vagy bizonytalan vagy, mely javítás hozná a legnagyobb hatást a saját oldaladon, egy célzott teljesítmény átvilágítás megmutatja pontosan, hol vesztegeted a másodperceket, és milyen sorrendben érdemes lépned. Vedd fel velünk a kapcsolatot egy ilyen átvilágításért, mielőtt a lassú betöltés több látogatót és vásárlót veszítet el, mint gondolnád.