Core Web Vitals: mit mérj, és milyen sorrendben javíts?

Melyik oldalakat vizsgáld meg?

Egy weboldal teljesítményét nem lehet a főoldal egyetlen futtatásából megítélni. Válassz ki egy fontos szolgáltatásoldalt, egy hosszabb cikket és egy olyan felületet, ahol a látogató ténylegesen cselekszik: keres, kosárba tesz vagy ajánlatot kér. Jegyezd fel, milyen eszközön, milyen hálózaton és bejelentkezett állapotban vizsgáltad őket.

Készíts egyszerű mérési naplót: URL, dátum, eszköz, tapasztalt probléma, feltételezett ok és következő próba. A lassú mobilmenü más vizsgálatot igényel, mint a későn megjelenő nyitókép. Az üzleti szempontból legfontosabb látogatói útvonal kapjon elsőbbséget, ne a legkönnyebben megszerezhető pontszám.

LCP: mikor jelenik meg a fő tartalom?

Az LCP a legnagyobb látható tartalmi elem megjelenését méri. Jó célértéke 2,5 másodperc vagy kevesebb. Vizsgáld meg, mi ez az elem az adott oldalon: gyakran kép, de lehet nagy szövegblokk is. Ha kép, ellenőrizd a méretét, a betöltés indítását és azt, hogy valóban a megfelelő felbontás kerül-e a telefonra.

Például egy 4000 pixel széles nyitókép 390 pixeles kijelzőn felesleges adatforgalom lehet. Ne csak új fájlformátumot válassz: nézd meg a ténylegesen kiszolgált fájlt és az oldal hálózati idővonalát. A fő tartalom képét ne kezeld ugyanúgy, mint egy képernyőn kívüli, később betöltendő illusztrációt.

INP és CLS: a betöltés után is használható marad?

Az INP a felhasználói műveletekre adott vizuális válasz késleltetését vizsgálja; jó értéke legfeljebb 200 milliszekundum. A CLS a váratlan elmozdulásokat jellemzi; jó értéke legfeljebb 0,1. Az aktuális értékelésnél a valós látogatások 75. percentilise számít, ezért egyetlen gyors saját próba nem helyettesíti a látogatói adatokat.

Próbáld ki a menüt, a keresést és az űrlap hibajelzéseit. Ha a kattintásra sokáig nem történik semmi, rögzíts böngészős teljesítményfelvételt. Elmozdulásnál keresd a helyet foglaló képek, későn megjelenő bannerek és betűtípusok szerepét. Egy előre lefoglalt képméret gyakran egyszerűbb és megbízhatóbb javítás, mint egy látványos animáció.

Laboradat és valódi felhasználói adat

A PageSpeed Insights és a böngésző fejlesztői eszközei eltérő nézőpontból segítenek. A kontrollált futtatás hibakeresésre hasznos, a valós látogatói adatok pedig megmutatják, hogyan működik az oldal különböző eszközökön. Ha az eszköz nem közöl elegendő terepadatot, ezt adathiányként kezeld, ne automatikus sikernek.

A saját ellenőrzéshez ugyanazt a három műveletet ismételd meg javítás előtt és után. Egy webshopnál például termék megnyitása, variáció választása, kosár megnyitása. Rögzítsd, melyik lépés lett jobb, és mi nem változott. A mérési napló legyen érthető annak is, aki nem vett részt a fejlesztésben.

Javítási sorrend és lezárás

Első körben azonosíts egyetlen szűk keresztmetszetet. A próba eredményét vesd össze az eredeti állapottal, és közben ellenőrizd, működik-e a kapcsolatfelvétel és a vásárlás. Ha egyszerre képet, gyorsítótárat és bővítményeket is cserélsz, nehéz lesz megmondani, mi segített vagy mi okozott hibát.

A lezáráskor rögzítsd a módosítást, az ellenőrzött útvonalakat és a visszaállítás lehetőségét. A sebesség egy működő szolgáltatás része: egy gyors, de hibás űrlap nem jó eredmény. A Core Web Vitals javítása önmagában nem garantál keresőbeli helyezést; a tartalom és a felhasználói feladat megoldása is számít.

Példa: egy lassú ajánlatkérő oldal

Tegyük fel, hogy az oldal nyitóképe hamar megjelenik, de az űrlap elküldésére két másodpercig nincs látható válasz. Első körben ne a képeket tömörítsd tovább: vizsgáld meg, mikor fut a validáció, elindul-e a kérés, és mennyit vár a böngésző a megjelenítésre. A gombot ismételten megnyomó látogató akár több kérelmet is küldhet. A folyamat közben látható, valós állapotjelzés is fontos.

Próbáld ki hibás és helyes adatokkal, lassabb eszközön és hálózaton is. A kliensoldali visszajelzés és a szerveroldali válasz külön időpont. A vizsgálatot dokumentáld úgy, hogy a fejlesztő reprodukálhassa: melyik mezőt töltötted ki, mit nyomtál meg, mit vártál, és mi jelent meg ténylegesen.

Milyen bizonyítékot kérj a javítás végén?

Az átadás tartalmazzon azonos körülmények között készült előtte–utána mérést és rövid funkciótesztet. Kérdezz rá, melyik elem okozta a késést, milyen változtatás történt, és mi maradt hátra. Ha csak egy jobb pontszámot kapsz, abból nem derül ki a hiba oka és az eredmény ismételhetősége.

Hosszabb távon külön figyeld a mobilos látogatói élményt és a fontos üzleti műveletek működését. Egy új marketinges szkript vagy nagyobb nyitókép később ismét ronthat az oldalon. Ezért érdemes minden jelentős tartalmi és technikai kiadásnál megismételni a néhány perces, reprezentatív ellenőrzési kört.

• Ellenőrizd az éles URL-t: státuszkód, indexelhetőség és canonical cím.
• Rögzíts kiinduló állapotot: dátum, érintett oldal és reprodukálható próba.
• Mérj újra a változtatás után: a fontos felhasználói műveleteket is próbáld ki.