Mi az a Core Web Vitals?
A Core Web Vitals három speciális mutatószám, amely a Google megítélése szerint alapvetően befolyásolja a felhasználói élményt egy weboldalon.
A Core Web Vitals a weboldal sebességét és a felhasználói interakciót mérő mutatók:
- Legnagyobb Vizuális Tartalomválasz (Large Contentful Paint – LCP)
- Első reakciótól számított válaszkésés (First Input Delay – FID )
- Elrendezés összmozgása (Cumulative Layout Shift – CLS )
A Core Web Vitals tényezői a Google oldalélmény (Page Experience) algoritmusának részét képezik, éppen ezért a rangsorolási szempontnak minősülnek 2021 júniusától.
Nagyon egyszerűen fogalmazva, ezek alapján határozza meg a Google a weboldalak felhasználói élményének minőségét.
A weboldalad Core Web Vitals adatait eléred a Search Console „Felhasználói élmény” rész alatt:
Miért fontos a Core Web Vitals?
Hirdetés
A Google hivatalos formában is bejelentette, hogy az oldal élmény a rangsorolási algoritmus része lesz:
Az oldalélmény algoritmus hét tényező alapján értékeli az oldalakat, amelyek mind felhasználói szempontból fontosak:
- mobil-barát oldal
- biztonságos weboldal
- HTTPS
- zavaró közbe-ékelődő ablakok
Valamint a három korábban említett Core Web Vitals mutató.
A fenti négy tényező már korábban is része volt az algoritmusnak, így nem túlzás azt állítani, hogy a Core Web Vitals értékei alapvető fontosságúak lesznek.
Ugyanakkor fontos leszögezni, hogy az oldalélmény értékei nem fognak azonnal mágikus módon a találati lista élére repíteni. Sőt a Google maga hívta fel a figyelmet arra, hogy az oldalélmény algoritmus csak egyike a számos (több száz) rangsorolási tényezőnek és az „nem írja felül a nagyszerű és releváns tartalom” fontosságát.
Nem kell tehát pánikba esni, ha nem jók az értékeid! Az oldalélmény algoritmus 2021 június közepén indul útjára és 2021 augusztusának végére élesedik teljeskörűen.
Sosem késő elkezdeni a Core Web Vitals értékek javítását.
Ebben az útmutatóban mind a három Core Web Vitals mutatót részletesen bemutatom, ahogy azt is, hogy miként tudsz rajtuk javítani.
Legnagyobb Vizuális Tartalomválasz – Largest Contentful Paint (LCP)
Az LCP azt mutatja meg, hogy a felhasználó szemszögéből milyen gyorsan töltődik be az oldal.
Egészen pontosan fogalmazva, az LCP azt mutatja meg, hogy az oldal legnagyobb vizuális eleme mennyi idő alatt jelenik meg a képernyőn.
De mit jelent az, hogy „Legnagyobb Vizuális Tartalomválasz”?
Nos, az LCP azon eleme a weboldalnak, amely a képernyőn a legnagyobb területet foglalja el.
Ez lehet egy kép, egy hero image, de lehet egy CSS-ből beolvasott háttérkép, de akár egy szövegblokk is.
Fontos, hogy itt nem a file mérete számít, hanem a mérete az aktuális kijelzőn.
És még egy fontos dolog: nem az URL egészén lévő tartalom számít, hanem csak az, ami görgetés nélkül megjelenik a képernyőn. Ebből következőleg az LCP más lehet egy nagy monitoron és egy kis mobileszközön!
A Google korábbi sebesség mutatói (mint a TTFB, vagy a Speed Index) gyakran nem kötődtek a valós felhasználói élményhez, hanem eszközök által mért adatok voltak. A Legnagyobb Vizuális Tartalomválasz azonban valós felhasználók által tapasztalt adatokon alapulnak.
A LCP értékeidet ellenőrizheted a Google Page Speed Insight eszközén.
Itt fontos megkülönbözteni az un. „Mező adatai” és a „Tesztadatok” alatt látható értékeket.
A Mező adatai valós Chrome böngészőt használó felhasználók adatain alapulnak, míg a tesztadataok, az éppen aktuálisan ellenőrzőtt adatok. Éppen ezért ha javítunk az oldalunkon, akkor itt fogjuk látni a változásokat. Itt lehet tesztelni a módosításokat.
Ezen túl érdemes a Search Console LCP-jelentését is megvizsgálni.
Hogy miért?
Nos, a Page Insightban egyenként tudunk megnézni egy-egy URL-t. Ezzel szemben a Search Console-ban az oldal egészének adatait láthatjuk, a Chrome felhasználók valós adataira alapozva. Így nem csak egy-egy URL-t látunk véletlenszerűen, hanem a site egészének teljesítményére rálátunk egyszerre.
A Google Legnagyobb Vizuális Tartalomválaszra vonatkozó útmutatója szerint az LCP értékek három minősítést kaphatnak.
Ahhoz, hogy jó minősítést elérjünk 2,5 másodpercnél jobb értéket kell elérnünk. Ez komoly kihívás, különösen a nagy, vagy összetettebb weboldalak számára.
Különösen akkor, ha sok, nagy méretű képet használunk, vagy sok stílusfilet, vagy javascript file-t töltünk be.
Lehet, hogy a Legnagyobb Vizuális Tartalomválasz elemünk egy szövegblokk, de mivel a forráskódban előtte sok egyéb dolgot kell betölteni (betűtipusok, javascriptkódok, stb.) ezért a szövegblokk megjelenésére hosszú másodpercekig kell a felhasználónak várakoznia.
Könnyű javítani mindezeket? Sajnos nem. Megéri? Abszolút!
De hogyan lehet javítani az LCP értékeinken?
Az LCP értékeit alapvetően négy dolog befolyásolja:
- a kezdeti szerver válaszidő sebessége
- megjelenést gátló Javascript és CSS fileok
- az erőforrások (képek, videók, stb.) betöltődési ideje
- ügyfél oldali megjelenés
Nézzük, hogy ezek miként kezelhetőek!
Szerver válaszidő csökkentése
- megfelelő tárhelyszolgáltató kiválasztása
- CDN hálózat használata, ha a felhasználók nem csak egy országból érkeznek
- szerver oldali gyorsítótárazás használata: ennek lényege, hogy ha az oldalunk dinamikusan áll össze, a szerver előre elkészíti ennek statikus HTML változatát (erre már remek WordPress bővítmények vannak.)
- ha olyan harmadik féltől származó elemeket használsz, ami befolyásolja az LCP betöltődését érdemes a rel=”preconnect” használata, hogy minél hamarabb betöltődjön az oldal
Megjelenést gátló CSS és Javascript fileok
- CSS és JS tömörítése ( a üres karakterek, kommentek törlése, ezáltal a fileméret csökkentése)
- a nem kritikus CSS és JS kódok betöltésének elhalasztása
- a görgetés előtti kritikus CSS elemek beépítése a forráskódba
Erőforrások betöltődési ideje
- optimalizáljuk és tömörítsük a képeket
- használjunk preload-ot a kritikus görgetés feletti elemeknél
- tömörítsük a szöveges állományokat (GZIP tömörítés)
Ügyfél oldali megjelenés
Vannak olyan keretrendszerek, amelyek elsősorban kliens oldali megjelenítésen alapulnak (Vue, Angular, stb.) itt is vannak lehetőségeink , például a Javascript minimalizálása, vagy a szerver oldali renderelés.
First Input Delay (FID) – Első reakciótól számított válaszkésés
Nézzük, a második Core Web Vitals-t a First Input Delay-t!
Az FID azt nézi, hogy mennyi időbe telik, mire a felhasználó használatba tudja venni az oldaladat. Tehát megjelentek a fontosabb vizuális elemek, de vajon interakcióba tud-e lépni az oldallal?
Mit is jelent mindez?
- tud-e kattintani a menüpontokra?
- lenyílnak-e a menüpontok?
- ki tudja-e tölteni egy mezőt (pl. e-mail megadása)
A Google számára ez azért fontos mutató, mert ez jól mutatja, hogy milyen a felhasználói élmény az oldallal kapcsolatban. tudja-e elég gyorsan használatba venni az oldalt, vagy sem?
Mi számít jó értéknek?
A First Input Delay értékek teljesítése egyes weboldalak számára nem jelent kihívást. Egy sima blogoldalon, ahol nincsenek lebomló menüpontok, vagy például bejelentkezési mező ez nem lesz probléma.
Ugyanakkor egy webáruház számára már kihívást jelenthet a FID teljesítése.
Érdemes megnézni a Search Console-ban is a First Input Delay jelentést, hogy lássuk érinti-e ez a probléma weboldalunkat, és ha igen hány URL-t.
Az alábbi oldalamnál van például egy hangsúlyos keresőmező, ahová a felhasználó beírhat valamit. Ez érinti a FID értéket és, mint látható még javításra szorul.
Hogyan javíthatjuk a FID értékeit?
- A javascript fileok minimalizálása: mivel az oldal-interkaciót sok esetben a javascript befolyásolja ezért ennek optimalizálásával javítható a FID érték
- a harmadik féltől származó sriptek számának csökkentése vagy optimalizálása (pl Analytics, hőtérképek, stb.)
- böngésző gyorsítótárazás alkalmazása
Cumulative Layout Shifts (CLS) – Elrendezés összmozgása
A Cumulative Layout Shifts, avagy az oldal vizuális stabilitása azt mutatja meg, hogy mennyire stabil az oldal vizuális megjelenése miközben töltődik.
Magyarán, ha az oldal egyes elemei elmozdulnak miközben az oldal töltődik, az rossz CLS értéket fog eredményezni, ami rontja a Core Web Vitals értékét.
Miért rossz dolog ez a Google szerint?
Nos azért, mert a felhasználó már az oldal betöltődése közben is néz a weblapot, hogy hol mi van, hol vannak a linkek, menüpontok stb, és jó eséllyel kattint is.
És ha a kattintás alatt éppen elmozdul az oldal lehet, hogy egy cikk helyet egy reklámra kattint, mert menet közben betöltődött a reklám és lejjebb tolta a cikket.
Ez pedig igencsak frusztráló tud lenni.
A Google egy nullától egyig terjedő skálán pontozza a CLS-t. Ezek nem elvont számok, hanem azt mutatják meg, hogy a képernyő teljes nagyságához képest mekkora területen és mekkora mértékben „ugrik el” a tartalom.
A Page Speed Insight konkrétan megmutatja, hogy mely elemek okozzák a rossz CLS értékek, azaz mely elemek ugrálnak a betöltődés során:
Hogyan javíthatod a Cumulative Layout shits értékeidet?
- add meg a médiaelemek méretét a forráskódban (képek, videók, stb.) így a böngésző tudni fogja még a betöltés előtt hogy azok mekkora területet foglalnak el a képernyőn
- a hirdetések számára foglalj le fix területet, mert azok gyakran később töltődnek be és okozhatnak magas CLS értéket
- az új elemeket a görgetés alatti területre töltsd be, így nem okoznak vizuális elmozdulást
Tudj meg többet!
Core Web Vitals: a Google hivatalos oldala a Core Web Vitalsről rengeteg tudnivalóval
Oldalélmény algoritmus: tudj meg többet a Google Page Experience, azaz oldalélmény algoritmusáról
Page Speed Insights: A Google eszköze az oldalsebesség tesztelésére, köztük a felhasználói és tesztelt Core Web Vitals adatokról
Köszönöm, nagyon jó összefoglalás. Ahányszor olvasok erről a témáról, mindig újabb ötletek – teendők jutnak az eszembe. Egy gondom azonban megmaradt. Az az, hogy a Lighthouse értékek elég hektikusan ugrálnak. a Performance érték akár 50 pontos eltérést is tud mutatni. A CLS az változatlan, mert azt kihoztam nullára, de többi 5 mutató többszörös eltéréseket tud mutatni. Azt olvastam valahol, hogy az értékek azért ingadoznak, mert a tesztek során az útvonalak változnak, nade ennyire. A PageSpeed Insights-on szinte mindig jó értékeket kapok, a Chrome inkognitó módban elért Lighthouse értékekkel is többnyire elégedett lehetek, de ha megvizsgálom inkognitó mód nélkül, és az internetezők így használják a netet, akkor szörnyű. TBT lehet 200ms, de lehet 2000ms is. De ha a performance fülön végzem el a tesztet, akkor a TBT csak 20ms, sőt volt 0 is. És sajnos a search-console webvital mutatóiban a mobil eredményeknél ott a sárga csík, mert a FID kívánatos 100ms-os értéke elég esélytelennek tűnik elérni. Értem én, de egy kissé furcsa az egész, hogy abban az egy mutatóban vagyok rossz, amit konkrétan nem is mérhetek le, mert a tényleges látogatók értékeit méri úgy hogy nekem a tesztelés során a sajátomat nem is mutatja meg. Ugyanakkor az is tény, hogyha a többi mutatóhoz hasonlóan ilyen hatalmas szórásokkal tesztel, akkor nem is érhet sokat a teszt. Természetesen ugyanarról az oldalról, ugyanarról a struktúráról és ugyanazon fájlok letöltéséről van szó amikor azt mondom, hogy az értékek többszörös eltérést mutatnak. Egy performance értéket kihozhat 44-nek és 98-nak is. Csak én érzem ennyire megbízhatatlannak a Lighthouse-t?
Szia!
Alapvetően egyetértek és tényleg nagy a fluktuáció az értékek között. Én ezt különösen akkor tapasztalom, ha pl Adsense kód is megjelenik az oldalon, hiszen ott mindig változhat az aktuális reklám jellege. azt azonban ne felejtsd el, hogy a rangsorolásnak csak az FID, LCP és a CLS az alapja, a speed index, stb. nem számít bele a rangsorolásba. A Lighthouse 100 pontos rendszere viszont ez utóbbiakat is beleszámítja a pontozásba. Éppen ezért nem kell törekedni rangsorolási szempontból a 100 pontra, ha jók a CLS, FID és LCP értékeid. Legyen zöld és kész. A másik dolog, hogy a Lighthouse szándékosan beépít egy késleltetést a lassú webkapcsolatot szimulálva. Ugyanakkor a hazai web jellemzően sokkal jobb, mint amit a Google szimulál. Ezt is jó észben tartani.
Az FID javítása nem egyszerű, ha értesz hozzá, nézz bele a Google javaslataiba: https://web.dev/optimize-fid/
ÜdV:Attila
Hoppá. A böngészőben futó bővítmények – brutálisabban, mint gondoltam -, el tudják rontani a Lighthouse értékeket. Ezért is sokkal jobbak a Chrome inkognító módban mért értékek. Például az AdblockPlus rendkívül erős értékromboló. Mivel nincsenek reklámok a honlapomon, csak ugye alapból be van kapcsolva (mint sokaknak), és miután kikapcsoltam, rendkívül jól megközetítette az inkognító módban mért értékeket. Csak akkor az merült fel bennem, ha a bővítmények ennyire lerontják az értékeket, és a CWV esetében a gyakorlati értékek számítanak, vajon a Google hogyan veszi figyelembe, és fogja korrigálni, hogy igen azok az értékek nem a honlap struktúrája miatt rosszak, hanem azért, mert az a felhasználó felrakott mindeféle bővítményt és az rontja a felhasználói élményt? – Jó, ez a kérdés inkább költői volt – majd meglátjuk. Mert a felhasználó nem érzi, hogy 100-1000ms ide vagy oda, a blokkolót nem fogja emiatt kikapcsolni, ha amúgy meg rendesen jön a tartalom.
Igen, ez valóban így van, mindig inkognító módban kell a Lighthouse-t futtatni. Azt sajnos nem tudom, hogy a Chrome hogyan gyűjti be a felhasználói adatokat, de tartok tőle, hogy alapvetően a bővítményekkel együtt. Ugyanakkor azt sem szabad elfelejteni, hogy a magyar webes kapcsolat általában lényegesen jobb, mint amit a Chrome a Lighhouse esetén használ, ő ugyanis egy szándékosan gyengébb készüléket és internetkapcsolatot szimulál, ahol persze a Core Web Vitals adatai is rosszabbak. A valós felhasználók esetében viszont jobb.