Core Web Vitals: hogyan olvasd együtt az LCP, INP és CLS adatokat?

A három külön kérdés

Az LCP, INP és CLS eltérő hibát jelezhet, ezért egy javítás nem old meg automatikusan mindent. Válaszd külön a fő tartalom megjelenését, interakció utáni választ és elrendezési ugrást.

A három mutató külön látogatói problémát ragad meg. Az LCP a fő tartalom megjelenéséhez, az INP az interakció utáni látható válaszhoz, a CLS a váratlan elrendezési változáshoz kapcsolódik. Lehet gyorsan megjelenő, de kattintásra rosszul reagáló oldal, és lehet stabil, de lassan betöltődő felület. A javítás ezért a konkrét hibajelenség azonosításával induljon. A web.dev jelenlegi útmutatója jó tartományként 2,5 másodpercen belüli LCP-t, legfeljebb 200 milliszekundumos INP-t és legfeljebb 0,1-es CLS-t jelöl, a megfelelő terepi értékelésnél a látogatások 75. percentilisét vizsgálva. Ezeket ne keverd össze egy általános összpontszámmal. A számszerű cél mellett az érintett látogatói feladatot is nevezd meg. A hibajelenséghez a megfelelő mutatót kapcsolod.

Labor és valós adat

A kontrollált mérés egy futást mutat, a terepi adat sok látogató élményét összesíti. A hibakereséshez használd a labort, az üzemi állapot megértéséhez a terepi adatot.

A laboratóriumi mérés megismételhető körülmények között segít megtalálni a lassulás okát, de csak a vizsgált futásról ad képet. A terepi adat tényleges felhasználók különböző eszközeit és körülményeit foglalja össze, általában meghatározott időablakban. A kettő eltérhet anélkül, hogy valamelyik szükségszerűen hibás lenne. A laborban nem feltétlenül végzett interakció, eltérő hálózat vagy más látogatói összetétel magyarázhat különbséget. A javítás hatását ezért a megfelelő idősíkban értékeld. Azonnali kódváltozás után a régebbi terepi összesítés még korábbi állapotot is tartalmazhat. Kevés forgalomnál az adathiány nem bizonyít automatikusan jó teljesítményt. A mérés típusát és korlátját mindig írd a következtetés mellé, hogy a szám értelmezhető maradjon. A következtetésben szerepel a mérés típusa és vizsgált időszaka.

Oldaltípusok

Egy cikk, termékoldal és összetett pénztár eltérő erőforrásokat használ. Válassz reprezentatív oldalakat minden fontos sablonból.

A reprezentatív minta tartalmazza azokat az oldaltípusokat, ahol a látogató fontos döntést hoz. Kezdőlap, szolgáltatás, cikk, kategória, termék és pénztár eltérő képet, kódot és működést használhat. Egy könnyű szöveges oldal jó eredménye nem igazolja a teljes katalógus állapotát. A sablonon belül is lehet szélső eset: hosszú lista, sok variáció vagy videós cikk. A mérési lista ezért a tényleges forgalom és üzleti jelentőség alapján készüljön. A mobil és asztali állapotot külön nézd meg, mert eltérő erőforrás és LCP-elem jelenhet meg. A cél nem minden URL azonos mélységű vizsgálata, hanem a fontos mintákból és hibás kivételekből felépített, szakmailag indokolható kép. A jelentés nem általánosít egyetlen könnyű oldal alapján.

Mérési feltételek

Hálózat, eszköz és gyorsítótár jelentősen változtathatja a futást. Rögzíts azonosítható tesztkörnyezetet és több ésszerű próbahelyzetet.

Az összehasonlításhoz rögzítsd az oldalt, eszközjellemzőt, hálózati feltételt és tesztelt feladatot. A hideg és korábban meglátogatott állapot más eredményt adhat, mert a gyorsítótárak eltérően működnek. A szerveroldali cache és böngészőcache is külön tényező. Több futás segíthet felismerni az ingadozást, de nem indokolt tetszőlegesen a legjobb értéket kiválasztani. A mérési jelentésben szerepeljen, mi változott a két állapot között. Ha közben más kép, kampányszkript vagy tárhelybeállítás is módosult, a hatást ne tulajdonítsd biztosan egyetlen javításnak. A kontrollált próba és terepi követés egymást egészíti ki. A pontos feltételleírás megelőzi, hogy össze nem hasonlítható számokból látszólagos javulás vagy romlás szülessen. Az előtte és utána állapot összehasonlítható.

Javítás sorrendje

A legnagyobb fájl nem feltétlenül a látott lassulás fő oka. Azonosítsd a késés láncát és a látogatói feladatra gyakorolt hatását.

A prioritást a késés oka, érintett forgalom és feladatra gyakorolt hatás együtt adja. Egy hatalmas, de csak később letöltött kép más jelentőségű lehet, mint a fő tartalmat blokkoló kisebb erőforrás. A hálózati idővonal és teljesítményprofil megmutathatja, hol vár a böngésző. A szerverválasz, erőforrás felfedezése, letöltése és megjelenítése külön vizsgálható. Interakciónál a főszál terhelése és felületi frissítés lehet döntő. Az elrendezési ugrásnál a későn helyet kérő elemre kell rátalálni. A javítás után ugyanazt a hibajelenséget mérd újra. Ne az összes ajánlást mechanikusan hajtsd végre, mert egyes változtatások saját kockázatot vagy más mutató romlását hozhatják. A változtatás egy tényleges szűk keresztmetszetet céloz.

Utókövetés

Az új kép, kampányszkript vagy bővítmény később megváltoztathatja a működést. Építs rendszeres ellenőrzést a tartalom- és kiadási folyamatba.

A teljesítmény fenntartása szerkesztői és fejlesztői feladat. Egy új nyitóvideó, külső chat vagy nagy kép a kód érintése nélkül is megváltoztathatja a használatot. A kiadás előtti ellenőrzésnek ezért legyen néhány fontos oldaltípusa és művelete. A tartalomfeltöltéshez képméretezési és beágyazási szabály segíthet. A terepi adatból érkező romlást össze kell kapcsolni a változásokkal, de az okot tényleges vizsgálattal kell megállapítani. A százpontos laboreredmény hasznos cél lehet egy adott mérésben, de nem garantál minden felhasználónál hibátlan élményt vagy keresőbeli helyezést. A jó teljesítményprogram a valódi működésről ad őszinte képet, és észreveszi a későbbi romlást is, nem csak egyszer készít kedvező képernyőmentést. A romlást észreveszed, mielőtt tartós állapottá válna.

Szemléltető helyzet és gyakorlati munkalap

Szemléltető példa: a nyitóoldal laborban gyorsnak látszik, de az ügyfelek a hosszú terméklistán lassú szűrésről számolnak be. A vizsgálat ezért nem egyetlen kezdőoldali pontszámra épül, hanem oldaltípusonként, eszközönként és valódi interakciókkal is megvizsgálja a működést.

Gyakori kérdések