Ha a zöld sebességi pontszám láttán a „sikertelen Core Web Vitals értékelés” kifejezésre keresett rá, először ellenőrizze, melyik eredmény milyen adatokat ír le. A PageSpeed Insights (PSI) a valós látogatásokból származó adatokat egy külön, ellenőrzött körülmények között futó teszttel együtt mutatja meg. Mielőtt eszközt vásárol vagy a webhely újjáépítését kéri, rögzítse a címet, az eszközt, az adatok hatókörét és a nem megfelelő mutatót.
Ezzel a feljegyzéssel kezdünk, mert a „legyen zöld a pontszám” kérés túl sok kérdést hagy nyitva. A fejlesztőnek tudnia kell, a felhasználói élmény melyik része igényel figyelmet, és milyen bizonyíték alapján tekinthető hasznosnak a javítás.
Sikertelen Core Web Vitals értékelés: mit mért a jelentés?
Az értékelés a látogatók rögzített tapasztalatait írja le, a Lighthouse szakasz pedig diagnosztikai tesztet futtat. A Google PageSpeed Insights dokumentációja szerint a valós használati adatok a Chrome User Experience Reportból, röviden a CrUX-ból származnak, és egy gördülő, az előző 28 napot lefedő adatgyűjtési időszakra vonatkoznak. Egy friss diagnosztikai futtatás és ez az előzmény ezért eltérő eredményt mutathat.
Eltérnek a teszt körülményei. Egy ellenőrzött futtatás nem fedhet le minden eszközt, kapcsolatot és műveletet, amely valós látogatáskor előfordul. Használja egy lehetséges ok vizsgálatára; a látogatói adatokat is vegye figyelembe, amikor arról dönt, mi maradt megoldatlan.
Az eredmény nagyobb területre is vonatkozhat. Ha az adott oldalhoz túl kevés adat áll rendelkezésre, a PSI az origin adatait használhatja helyette. Az origin nagyjából a protokollal és a gépnévvel meghatározott közös webcímet jelenti. Az origin eredménye több oldal látogatásait összesíti. Mielőtt egy adott termék- vagy szolgáltatásoldalra vonatkozó bizonyítékként kezeli, olvassa el a látható hatókört.
Az időszak korábbi látogatásokat is tartalmaz. A mai módosítás nem írja át a tegnapi megfigyeléseket. Mentse el az élesítés dátumát, hogy megkülönböztethesse a javítás azonnali ellenőrzését a látogatókra vonatkozó későbbi bizonyítékoktól.
E különbségek alapján a jelentéseknek külön feladatuk van: a látogatói adatok kijelölik a vizsgálandó felhasználói élményt, az ellenőrzött teszt pedig segít azt újra előidézni és megvizsgálni.
Melyik mutató igényel figyelmet?
A javítás kiválasztása előtt külön-külön nézze meg az LCP, az INP és a CLS értékét. A Google Web Vitals útmutatója megkülönbözteti a betöltést, a válaszkészséget és a vizuális stabilitást. Az alábbi táblázat az útmutatóban szereplő Jó minősítés határértékeit mutatja, amelyeket az adott eszközcsoport 75. percentilisén értékelnek. A Google határértékekről szóló útmutatója így magyarázza a 75. percentilist: a mért oldalmegtekintések legalább 75%-ának teljesítenie kell az adott mutató Jó minősítésének határértékét. Ez eltér az átlagtól és a Lighthouse összesített pontszámától.
| Mutató | Mit ír le? | A Jó minősítés határértéke | Mit kérdezzen a webhely karbantartójától? |
|---|---|---|---|
| LCP, Largest Contentful Paint | Mikor jelenik meg a legnagyobb látható tartalmi elem? | Legfeljebb 2,5 másodperc | Melyik elem késik, és a betöltési folyamat melyik szakaszában? |
| INP, Interaction to Next Paint | Milyen gyorsan reagál az oldal az interakciókra? | Legfeljebb 200 milliszekundum | Melyik érintés, kattintás vagy billentyűművelet lassú az érintett körülmények között? |
| CLS, Cumulative Layout Shift | Az elrendezés váratlan elmozdulásai | Legfeljebb 0,1 | Melyik elem mozdul el, és a látogatás melyik pillanatában? |
Ha mindegyik mutatóhoz elegendő adat áll rendelkezésre, a PSI a megfelelő értékeléshez megköveteli, hogy a 75. percentilisük a Jó kategóriába essen. Elégtelen INP-adatok mellett a jó LCP és CLS továbbra is eredményezhet megfelelő értékelést. Ha az LCP- vagy a CLS-adatok elégtelenek, a PSI nem tudja értékelni az oldalt vagy az origint.
A hiányzó adatot kezelje bizonytalanságként. A Google CrUX módszertana a mérési feltételeknek megfelelő látogatásokat és elegendő népszerűséget követel meg; nem tesz közzé általános minimális látogatószámot. A hiányzó eredmény nem jelenti azt, hogy senki nem látogatja az oldalt, hogy jó a felhasználói élmény, vagy hogy a javítás sikertelen volt.
Mit ellenőrizhet, mielőtt fizet a munkáért?
Mielőtt eszközt választ, mentse el a kiinduló jelentést, majd telefonon járja végig ugyanazt az utat, mint az ügyfél. A probléma világos leírására van szüksége: az oldalra, a figyelmeztetés mögötti adatokra és az újra előidézhető működésre. Ha nem tudja előidézni a hibát, találgatás helyett rögzítse ezt a korlátot.
- Nyissa meg a konkrét, üzletileg fontos oldalt a PSI-ben. Őrizze meg a címét és a jelentés dátumát. Vegye bele a vizsgált érdeklődéshez vagy vásárláshoz fontos céloldalt vagy sablont.
- Rögzítse, hogy mobilról vagy asztali gépről van szó, és adja meg az adatok hatókörét. Jegyezze fel, hogy a valós használati adatok szakasza az URL-re vagy az originre vonatkozik, esetleg elégtelen adatot jelez. A későbbi összehasonlításhoz ugyanazt a beállítást használja.
- Nevezze meg a figyelmet igénylő mutatót. Az egyes Core Web Vitals eredményekből induljon ki, majd keressen támpontokat a diagnosztikai szakaszban. A hiányzó mintákat továbbra is jelölje egyértelműen.
- Végezzen el egy valós feladatot telefonon. Nyissa meg a menüt, használja a megfelelő szűrőt, vagy töltse ki az adott űrlapot. Írja le, mi töltődik be későn, reagál lassan vagy mozdul el váratlanul.
- Kapcsolja össze a támpontot egy teszttel. Kérje meg a karbantartót, hogy idézze elő újra az érintett műveletet vagy a betöltési késést, és magyarázza el, mit lehet megállapítani a teszttel.
A képek, widgetek, gyorsítótár és tárhely tágabb vizsgálatához használja a lassú webhelyek gyakori okairól szóló útmutatónkat. A mostani feladatot összpontosítsa a sikertelen értékelésre és a javítás ellenőrzéséhez szükséges bizonyítékokra.
Mit tartalmazzon a javítás?
Válassza a diagnózissal alátámasztott legkisebb módosítást, majd egyeztesse az ellenőrzés módját. A már meglévő jelentésekből és funkciókból induljon ki. A műszaki munkát könnyebb értékelni, ha a karbantartó megnevezi az érintett oldalt vagy sablont, elmagyarázza a szűk keresztmetszetet, és összehasonlítható körülményeket tart fenn a változtatás előtt és után.
- Kösse a javaslatot a mutatóhoz. A web.dev LCP-útmutatója külön kezeli a válasz, az erőforrás felfedezése, a betöltés és a legnagyobb elem megjelenítése során fellépő késéseket. Az INP-útmutató a lassú interakciókra összpontosítja a vizsgálatot. A CLS-útmutató a kezdeti betöltés után fellépő elmozdulásokat is tárgyalja. Általános gyorsítási ígéret helyett az adott problémához tartozó bizonyítékot kérje.
- Módosítsa az azonosított okot, és tesztelje újra a működést. Egy erőforrás vagy sablon célzott javítása a webfejlesztés és karbantartás része lehet. Rögzítse, mi és mikor változott, és ahol megoldható, azt is, hogyan állítható vissza a korábbi állapot.
- Ellenőrizze, hogy az ügyfél feladata továbbra is elvégezhető. Tesztelje az oldalhoz tartozó navigációt, űrlapokat és vásárlási lépéseket. A hozzájárulást kezelő vezérlők maradjanak működőképesek; vizsgálja meg működésüket és elrendezésüket a jogszerű hozzájárulás követelményeit betartva.
- Döntse el, szükség van-e további bizonyítékra. Ha az elérhető jelentésekből nem azonosítható az érintett interakció vagy oldal, további mérés segíthet. Fizetős szolgáltatás hozzáadása előtt kérdezze meg, milyen kérdésre ad választ a javasolt megfigyelés.
Ha nem világos a műszaki prioritás, a technikai SEO-munka diagnózissal és ellenőrizhető feladatlistával kezdődhet. Egy újratervezés vagy optimalizálási csomag külön indoklást igényel.
Az alábbi feladatlapot átmásolhatja, az ismeretlen mezőket pedig üresen hagyhatja:
Oldal és üzleti feladat:
Eszköz és a valós használati adatok hatóköre:
Figyelmet igénylő mutató:
Megfigyelt működés és tesztkörülmények:
Feltételezett ok és javasolt módosítás:
Élesítés dátuma:
Összehasonlítható ellenőrzés a változtatás után:
Későbbi valós használati megfigyelés és fennmaradó bizonytalanság:Hogyan ellenőrizheti, hogy segített-e a munka?
Először a megváltozott működést értékelje, majd ugyanabban a hatókörben hasonlítsa össze a későbbi valós használati adatokat. Dokumentációja szerint a PSI naponta frissíti ezeket az adatokat, miközben megtartja a gördülő adatgyűjtési időablakot. Az élesítés dátuma maradjon a feljegyzés része. Ez az időablak nem egy megfelelő értékelésig tartó, megígért visszaszámlálás.
A célzott mutatót és az ügyfél feladatát hasonló tesztkörülmények között hasonlítsa össze. Ha a tünet megmarad, térjen vissza a diagnózishoz. Ha a teszt javulást mutat, de a későbbi valós használati adatok nem támasztják alá a változtatást, vizsgálja meg újra az érintett oldalakat és a látogatók körülményeit. A hiányzó valós használati adat maradjon kifejezetten jelzett korlát.
Miben segítünk mi?
A jelentésből, a fontos oldalakból és egy újra előidézhető feladatból indulunk ki. Külön kezeljük a javasolt javítást, annak ellenőrzését és a későbbi látogatói bizonyítékokat, így minden döntésnek ellenőrizhető alapja lesz. A webhely teljesítményére vonatkozó brief kiindulópontja lehet a fenti feladatlap; az ismeretlen mezők maradjanak láthatók.
