Core Web Vitals érthetően: LCP, INP és CLS egyszerűen

A Core Web Vitals nem személyiségteszt a webhelyed számára

A Core Web Vitals mutatókat gyakran úgy kezelik, mint valamilyen rejtélyes értékelőlapot. Egy oldal kap egy piros számot, valaki betesz egy képernyőképet Slackbe, a csapat pedig vitatkozni kezd a JavaScript frameworkökről.

Ez nem különösebben hasznos.

A Core Web Vitals jobb megközelítése egyszerűbb: három mérés arról, hogy egy oldal használhatónak érződik-e egy valódi ember számára, valódi eszközön. Nem fedik le a teljesítmény, az akadálymentesség vagy a minőség minden aspektusát. De három gyakori frusztrációforrást jól elkapnak:

• A fő tartalom túl sokára jelenik meg.
• Az oldal lassan reagál, amikor a felhasználó tenni próbál valamit.
• Az elrendezés ugrál, miközben a felhasználó olvas vagy koppint.

Ez a három Core Web Vitals: LCP, INP és CLS.

A Google ezeket az oldalélmény-jelzései részeként használja, de nem az SEO-szempont a legjobb ok arra, hogy foglalkozzunk velük. A jobb ok az, hogy a lassú, ugráló, nem reagáló oldalak pazarolják a felhasználók idejét. Emellett általában rosszabbul konvertálnak, nehezebben támogathatók, és rosszabbul öregszenek.

A három mutató egy-egy mondatban

Mielőtt belemennénk a részletekbe, itt a közérthető változat:

• LCP, vagyis Largest Contentful Paint, azt méri, mennyi idő alatt töltődik be a fő látható tartalom.
• INP, vagyis Interaction to Next Paint, azt méri, milyen gyorsan reagál az oldal a felhasználói interakciókra a látogatás során.
• CLS, vagyis Cumulative Layout Shift, azt méri, mennyit mozdul el váratlanul az oldal elrendezése.

A szokásos küszöbértékek:

| Mutató | Jó | Fejlesztendő | Gyenge | |---|---:|---:|---:| | LCP | 2,5s vagy gyorsabb | 2,5s–4,0s | 4,0s felett | | INP | 200ms vagy gyorsabb | 200ms–500ms | 500ms felett | | CLS | 0,1 vagy alacsonyabb | 0,1–0,25 | 0,25 felett |

Ezeket a számokat általában a valós felhasználói látogatások 75. percentilisénél értékelik. Ez fontos. Nem az a cél, hogy egyetlen tökéletes labormérést hozz létre. Az a cél, hogy a legtöbb felhasználó számára jó legyen az élmény, beleértve a lassabb telefonokat és zavarosabb hálózatokat használó embereket is.

Ha egy automatizált jelentést nézel, és nem tudod, hol kezdd, érdemes elválasztani a diagnózist a pániktól. Külön útmutatónk van arról, hogyan olvass Lighthouse jelentést pánik nélkül; ez részletesebben bemutatja ezt a munkafolyamatot.

LCP: mikor érződik betöltöttnek az oldal?

A Largest Contentful Paint a viewportban látható legnagyobb tartalmi elem renderelési idejét méri. A gyakorlatban ez gyakran:

• egy hero kép,
• egy nagy címsor,
• egy kiemelt cikk képe,
• egy termékkép,
• egy nagy szövegblokk.

Az LCP nem azt kérdezi, mikor töltődött be minden script, tracking pixel és hajtás alatti kép. Azt kérdezi: mikor vált láthatóvá az a fő dolog, amiért a felhasználó az oldalra érkezett?

Ez az LCP-t emberibb mutatóvá teszi, mint a régi típusú „oldalbetöltési idő”. Egy oldal technikailag későn is befejezheti a betöltést, mégis gyorsnak érződhet, ha a fő tartalom hamar megjelenik. Ennek az ellenkezője is igaz: egy oldal elsütheti a load eventet úgy, hogy közben a hero terület még üres, elmosódott vagy renderelési késleltetés blokkolja.

A gyenge LCP gyakori okai

A rossz LCP-problémák többsége néhány kiszámítható helyről ered:

1. Lassú szerverválasz

Ha a HTML dokumentum későn érkezik meg, minden más is későn indul.

1. Renderelést blokkoló CSS vagy JavaScript

A böngészőnél már ott van a tartalom, de még nem tudja kirajzolni.

1. Nem optimalizált hero képek

A legnagyobb elem túl nagy, rossz formátumú, nincs priorizálva, vagy véletlenül lazy-loadolva töltődik.

1. A szöveg renderelését késleltető webfontok

Egy nagy címsor lehet az LCP elem, és a fontbetöltés késleltetheti vagy vizuálisan megváltoztathatja.

1. Kliensoldali renderelési késések

Ha az oldalnak egy nagy JavaScript bundle-re van szüksége, mielőtt értelmes tartalmat tud mutatni, az LCP romlik.

Hogyan javítsd az LCP-t

Kezdd a tényleges LCP elemmel. Ne optimalizálj véletlenszerű asseteket, amíg nem tudod, mit mér a böngésző.

Gyakorlati javítások:

• Szolgáld ki gyorsan a HTML-t: cache-elj, ahol indokolt, csökkentsd a backend munkát, kerüld a lassú redirecteket.
• Optimalizáld az LCP képet: használj megfelelő méreteket, tömörítést és formátumot.
• Ne lazy-loadold a hajtás feletti hero képet.
• Használd körültekintően a fetchpriority="high" értéket a fő képnél, ha valóban az az elsődleges prioritás.
• Csak akkor inline-old a kritikus CSS-t, ha az érdemben csökkenti a renderelési késleltetést.
• Csökkentsd az első értelmes renderelés előtt szükséges JavaScript mennyiségét.
• Használj font-display: swap beállítást vagy más tudatos fontstratégiát.

A képek és a fontok gyakori bűnösök. Képeknél a kompromisszum nem pusztán annyi, hogy „a kis fájl jó”. A formátumválasztás, a kódolási ráfordítás és a böngészőtámogatás mind számítanak, ezért tartunk fenn egy gyakorlati döntési fát arról, mikor jobb az AVIF a WebP-nél, és mikor nem. A sok szöveget tartalmazó oldalaknál a webfontok még mindig a legegyszerűbb teljesítményjavítások közé tartoznak, mert sok webhely több fontfájlt szállít, mint amennyit ténylegesen használ.

INP: reagál az oldal, amikor hozzáérnek?

Az Interaction to Next Paint a reszponzivitást méri. Pontosabban azt vizsgálja, mennyi idő telik el egy felhasználói interakció és a következő vizuális frissítés között, miután a böngésző feldolgozta az adott interakciót.

Interakciók például:

• egy gombra kattintás,
• egy menüre koppintás,
• egy jelölőnégyzet kiválasztása,
• gépelés egy űrlapmezőbe,
• egy accordion megnyitása.

Az INP 2024-ben váltotta a First Input Delay mutatót Core Web Vitalként. Ez jó változás volt. A First Input Delay csak az első interakciót nézte. Az INP szélesebb: a teljes oldallátogatás során figyelembe veszi az interakciókat, és egy nagy késleltetésű interakciót jelent az oldal reszponzivitási pontszámaként.

Egyszerűen: az INP elkapja azokat az oldalakat, amelyek betöltöttnek tűnnek, de beragadtnak érződnek.

Valószínűleg használtál már ilyen oldalt. Úgy tűnik, készen áll. Rákoppintasz a menüre. Fél másodpercig semmi sem történik. Újra rákoppintasz. Aztán két dolog történik egyszerre. Ez INP-probléma.

A gyenge INP gyakori okai

Az INP általában main-thread probléma. A böngésző reagálni szeretne, de JavaScript, renderelési munka vagy elrendezésszámítás áll az útjában.

Tipikus okok:

• nagy JavaScript bundle-ök,
• költséges event handlerek,
• hydration munka kliensoldalon renderelt appoknál,
• a main threadért versengő third-party scriptek,
• hosszan futó taskok oldalbetöltés után,
• kis interakciók által kiváltott összetett DOM-frissítések,
• layout thrashing, amikor a kód ismételten olvas és ír elrendezési értékeket.

Marketing tagek, analytics, chat widgetek és consent bannerek mind hozzájárulhatnak. Ez nem azt jelenti, hogy „mindent el kell távolítani”. Azt jelenti, hogy minden scriptnek költsége van az oldalon, és ez a költség gyakran az interakciós késleltetésben válik láthatóvá.

Hogyan javítsd az INP-t

Az INP javítása kevésbé egyetlen mágikus attribútumról szól, inkább a main-thread versengés csökkentéséről.

Hasznos megközelítések:

• Bontsd a hosszú JavaScript taskokat kisebb részekre.
• Halaszd a nem létfontosságú munkát addig, amíg az oldal használhatóvá nem válik.
• Távolítsd el a nem használt JavaScriptet ahelyett, hogy csak minify-olnád.
• Tartsd az event handlereket kicsinek és kiszámíthatónak.
• Kerüld a felület nagy részeinek újrarenderelését apró állapotváltozások miatt.
• Egyszerű vizuális állapotokhoz használj CSS-t, ahol lehet.
• Auditáld a third-party scripteket, és csak ott töltsd be őket, ahol szükség van rájuk.

Nézd meg az interakciótervezést is. Egy gomb, amely azonnali vizuális visszajelzést ad, reszponzívabbnak érződhet akkor is, ha a további munka tovább tart. Ez nem helyettesíti a teljesítményt, de része a jó interface engineeringnek. Az akadálymentes webes gombokról szóló checklistünk átfed ezzel: a világos állapotok, a megfelelő szemantika és a kiszámítható viselkedés a felhasználóknak és a böngészőknek is segít.

CLS: ott marad az oldal, ahol a felhasználó várja?

A Cumulative Layout Shift a látható elemek váratlan elmozdulását méri. Ha a felhasználó elkezd olvasni egy bekezdést, majd felette betöltődik egy hirdetés, kép vagy banner, és lejjebb tolja a szöveget, az hozzájárul a CLS-hez.

A CLS-t nem másodpercben mérik. Ez egy pontszám, amely azon alapul, mennyi tartalom mozdult el, és milyen messzire. Az alacsonyabb érték jobb.

A kulcsszó a váratlan. A felhasználói művelet által okozott elrendezésváltozások általában nem ugyanúgy számítanak bele. Ha valaki rákoppint a „több megjelenítése” elemre, és a tartalom kinyílik, az várható. Ha egy newsletter banner három másodperc után megjelenik felül, és mindent lejjebb tol, az nem az.

A gyenge CLS gyakori okai

A CLS-hibák gyakran hétköznapiak:

• képek width és height attribútumok nélkül,
• hirdetések vagy embedek fenntartott hely nélkül,
• tartalom fölé beszúrt cookie bannerek,
• eltérő metrikájú webfontok becserélődése,
• későn betöltődő promóciós sávok,
• dinamikusan beszúrt tartalom az oldal tetejének közelében.

A javítás általában az, hogy helyet tartasz fenn, mielőtt a tartalom megérkezik. A böngészőnek a lehető legkorábban tudnia kell az oldal alakját.

Hogyan javítsd a CLS-t

Kezdd a látható elmozdulásokkal. Nézz meg egy felvételt, vagy használj böngészőeszközöket annak azonosítására, mely elemek mozognak.

Ezután alkalmazd az unalmas javításokat:

• Adj explicit width és height attribútumokat a képekhez.
• Használj CSS aspect-ratio beállítást reszponzív médiakonténerekhez.
• Tarts fenn fix vagy minimális helyet hirdetéseknek, embedeknek és iframe-eknek.
• Kerüld a bannerek beszúrását meglévő tartalom fölé betöltés után.
• Válassz a végleges fonthoz hasonló metrikájú fallback fontokat.
• Kerüld az olyan animációkat, amelyek elrendezési tulajdonságokat módosítanak, például top, left, width vagy height; részesítsd előnyben a transformokat.

A CLS azon kevés teljesítménymutatók egyike, ahol a fegyelem többet ér az okoskodásnál. Ha az oldal dobozai stabilak, általában jó pontszámot kap.

A field data és a lab data egyaránt hasznos, de más kérdésekre válaszolnak

Gyakori zavarforrás, hogy különböző eszközök különböző számokat mutatnak. Ez normális.

Field data valódi felhasználóktól származik. Tükrözi a tényleges eszközöket, hálózatokat, helyszíneket és böngészőkörülményeket. A Google Chrome User Experience Report példa field datára.

Lab data kontrollált tesztkörnyezetből származik. A Lighthouse az ismerős példa. Ismételhető és hasznos a hibakereséshez, de nem azonos a felhasználóid megélt élményével.

Field datát használj annak eldöntésére, hogy a felhasználóknak van-e valódi problémájuk. Lab datát használj a probléma reprodukálására és hibakeresésére.

Azt is tartsd észben, hogy a Core Web Vitals mutatókat általában URL-enként vagy URL-csoportonként értékelik, nem pedig a branded egyetlen absztrakt tulajdonságaként. A kezdőlapod, blogcikked, árazási oldalad és checkoutod nagyon különböző szűk keresztmetszetekkel rendelkezhet.

Ésszerű munkasorrend

Ha mindhárom mutató gyenge, csábító mindenhol egyszerre kezdeni. Állj ellen ennek.

Gyakorlati sorrend:

1. Először javítsd a nyilvánvaló CLS-t

A hiányzó képméretek és instabil bannerek gyakran gyors győzelmek.

1. Javítsd az LCP-t a fontos template-eken

Koncentrálj a fontos oldalakra: termékoldalak, landing oldalak, cikkek, regisztrációs folyamatok.

1. Vizsgáld az INP-t valódi interakciókkal

Kattints arra, amire a felhasználók ténylegesen kattintanak. A menük, szűrők, űrlapok és checkout vezérlők gyakran többet elárulnak, mint a kezdeti betöltési trace.

1. Auditáld a third-party scripteket

Tartsd meg azokat, amelyek igazolják a költségüket. Távolítsd el vagy késleltesd azokat, amelyek nem.

1. Állíts fel teljesítménybudgetet

Budget nélkül a teljesítményjavítások leépülnek. Új scriptek, képek és designkomponensek csendben visszafordítják a munkát.

A lényeg: ne jelvényért optimalizálj. A felhasználói útvonalért optimalizálj. Egy marginális pontszámjavulás egy alacsony forgalmú oldalon kevesebbet érhet, mint egy kissé tökéletlen, de sokkal gyorsabb checkout-interakció.

<!-- tool-cta:start -->

💡 Próbáld ki ezt: Mivel az LCP általában képprobléma, első, könnyű nyereségként csökkentsd a kiemelt vizuális elemed méretét az Image Compressor segítségével.

<!-- tool-cta:end -->

Amit a Core Web Vitals nem mond el

A Core Web Vitals hasznos, de nem teljes.

Nem mondja meg, jó-e a tartalmad. Nem mondja meg, értelmes-e a navigációd. Nem garantálja az akadálymentességet. Nem méri az adatvédelmet, a biztonságot, a bizalmat, az olvashatóságot, vagy azt, hogy az oldal megválaszolja-e a felhasználó kérdését.

Az ítélőképességet sem helyettesíti. Egy oldal átmehet a Core Web Vitals küszöbökön, és mégis kellemetlen lehet. Egy összetett alkalmazás elmaradhat egy küszöbértéktől, miközben a korlátaihoz képest felelősen van megtervezve.

Kezeld az LCP-t, az INP-t és a CLS-t füstjelzőként. Amikor megszólalnak, vizsgálódj. Amikor csendben vannak, tartsd karban tovább az épületet.