Core Web Vitals: LCP, INP és CLS

Modul 4: Sebesség, mobil és https · Olvasási idő: 13 perc

Tanulási cél: A lecke után el tudja magyarázni a három Core Web Vitals mutatót és a határértékeiket, meg tudja nevezni a terepi és a laboradatok közötti különbséget, értelmezni tud egy PageSpeed Insights mérést, kezelni tudja a rossz eredmény legfontosabb okait, és reálisan fel tudja mérni, mennyit számít a sebesség a találati listában.

Kulcsfogalmak: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. percentilis, terepi adatok (CrUX), laboradatok (Lighthouse), PageSpeed Insights, a Search Console Core Web Vitals jelentése, TTFB, tömörítés, width és height a képeknél, loading="lazy", oldalélmény

A sebesség három számban

„Gyors a webhelyem?” Ez homályos kérdés. A Google és a Chrome fejlesztői három mérhető kérdést csináltak belőle, ezek a Core Web Vitals mutatók:

Néhány dolog, amelyet érdemes pontosan érteni:

• Az LCP azt a pillanatot méri, amikor a legnagyobb látható elem megjelenik. Ez többnyire egy nagy fotó az oldal tetején (a „hero”) vagy egy nagy szövegblokk. A Bloemenatelier Lotte (Lotte virágműhelye) esetében ez a kezdőlapon látható virágkompozíció fotója.
• Az INP a látogatás során történt összes kattintást, koppintást és billentyűleütést figyeli, és (majdnem) a leglassabb reakciót jelenti. Az INP 2024. március 12-én váltotta fel a régebbi FID (First Input Delay) mutatót, amely csak az első kattintást vizsgálta, és csak a feldolgozás előtti várakozást. Ha egy régi cikkben FID-del találkozik, az már elavult.
• A CLS nem idő, hanem mértékegység nélküli pontszám. Akkor nő, ha olvasás közben elemek elmozdulnak: Ön éppen rá akar koppintani egy gombra, de abban a pillanatban fölé csúszik egy banner, és valami mást koppint meg.

A 75. percentilis

Egy oldal akkor „teljesíti” a Core Web Vitals követelményeit, ha a látogatások 75 százaléka mindhárom mutatón jó eredményt ér el, mobilon és asztali gépen külön mérve. Ezt nevezzük 75. percentilisnek. Ez azt jelenti, hogy nem az Ön saját gyors, optikai hálózatra kötött számítógépe számít, hanem a legtöbb látogató élménye, azoké is, akik régebbi telefonon, 4G-n böngésznek.

Terepi adatok és laboradatok

Kétféle mérés létezik, és gyakran eltérő számokat adnak.

• A terepi adatok valódi látogatóktól származnak. A Chrome (azoknál a felhasználóknál, akik ezt engedélyezik) névtelenül gyűjti, milyen gyorsak voltak az oldalak, a Chrome User Experience Report (CrUX) keretében. A PageSpeed Insights az elmúlt 28 nap terepi adatait mutatja. A Search Console Core Web Vitals jelentése ugyanezt a forrást használja. Ha az oldalnak túl kevés a látogatója, a PageSpeed Insights a teljes webhely (az „origin”) számait mutatja, és ha ahhoz is kevés az adat, akkor nincs terepi adat.
• A laboradatok egy szimulált tesztből származnak, amelyet a Lighthouse végez: egyetlen betöltés egy utánzott, közepes teljesítményű telefonon és kapcsolaton. A Lighthouse nem tud INP-t mérni (senki sem kattint), ezért más számokat ad, például a Total Blocking Time értéket, amely viszont utal az INP-re.

Az értékeléshez a terepi adatok számítanak. A laboradatok az okok felderítéséhez hasznosak, és ahhoz, hogy egy javítás után azonnal lássa, segített-e, anélkül hogy 28 napot várnia kellene.

Mennyit számít?

Ezt sokan eltúlozzák. Íme, mit mond erről maga a Google az oldalélményről szóló dokumentációjában:

• „Core Web Vitals are used by our ranking systems”: vagyis beleszámítanak a rangsorolásba.
• Nincs külön „oldalélmény-jel”. A jó oldalélmény többi összetevője (https, tolakodó felugró ablakok hiánya, mobilon való használhatóság) a Google szerint nem segít közvetlenül előrébb kerülni, de kellemesebbé teszi a webhelyet.
• „Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Egy lassú oldal a legjobb válasszal tehát nyugodtan lehet az első helyen.
• A Google szerint tökéletes pontszámot elérni pusztán a SEO kedvéért „talán nem a legjobb módja az idő eltöltésének”.

Következtetés: törekedjen arra, hogy a zöld, de legalább a narancssárga tartományban legyen, főleg azért, mert a látogatók egy lassú vagy ugráló oldalról elmennek. A Lighthouse-ban 90-ről 100 pontra feljutni a találati listában keveset hoz.

Az okok, amelyeket Ön is kezelhet

Lassú első válasz (TTFB)

Minden azzal a pillanattal kezdődik, amikor a HTML első bájtja megérkezik: ez a Time to First Byte. A TTFB maga nem Core Web Vital, de lassú TTFB mellett szinte lehetetlen jó LCP-t elérni. A web.dev irányértéke: 0,8 másodperc vagy kevesebb a jó, 1,8 másodpercnél több a gyenge. Az okok a web.dev szerint: kevés számítási kapacitás a tárhelyen, gyorsítótár hiánya (minden oldal újra felépül, ez jellemző a gyorsítótárazó bővítmény nélküli WordPressre), átirányítások (4.1. lecke) és egy távoli szerver CDN nélkül.

A tömörítés is ide tartozik: a szervernek a HTML-t, a CSS-t és a JavaScriptet gzip vagy Brotli tömörítéssel kell elküldenie. Ezt a Content-Encoding: gzip vagy br fejlécsorból látja. Szinte minden tárhely alapból így működik, de egy rossz beállítás vagy egy régi szerver kikapcsolhatja.

Képek

A képek a gyenge LCP és CLS leggyakoribb okai:

1. Túl nagyok. Egy 4000 pixel széles, 5 MB-os fotó egy 800 pixeles keretbe. Feltöltés előtt kicsinyítse le, és használjon modern formátumot, például WebP-t vagy AVIF-et.

2. Nincs szélesség és magasság. width és height nélkül a böngésző nem tudja, mekkora helyre van szüksége a képnek, így az alatta lévő szöveg elugrik, amint a kép megérkezik. A web.dev azt ajánlja, hogy minden <img> elemen legyen width és height:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. A legfontosabb fotó késleltetett betöltése. A loading="lazy" csak akkor tölti be a képet, amikor az a képernyőre kerül. Ez kiváló a lejjebb lévő fotókhoz, de a web.dev egyértelműen fogalmaz: azokat a képeket, amelyek megnyitáskor már láthatók, és különösen az LCP-képet, NE töltse be késleltetve. Különben a böngésző éppen azzal a fotóval vár, amely az LCP-t meghatározza.

Ugráló tartalom és lassú reakciók

A CLS további okai a web.dev szerint: betöltéskor méretet váltó betűtípusok, magukat megnagyobbító hirdetések és beágyazott widgetek, valamint a meglévő tartalom fölé később beszúrt tartalom (például egy sütisáv, amely lefelé tolja az oldalt ahelyett, hogy fölötte jelenne meg). A gyenge INP szinte mindig a túl sok JavaScript következménye: nehéz témák, sliderek, csevegőwidgetek és harmadik féltől származó követőkódok. Vizsgáljon meg kritikusan minden bővítményt és beágyazott szolgáltatást; itt a kevesebb valóban több.

A gyakorlatban: mérés a PageSpeed Insights eszközzel

Nyissa meg a pagespeed.web.dev oldalt, írja be a kezdőlapja címét, és kattintson az Elemzés gombra. Két lapot kap (Mobil és Asztali). Felül a Core Web Vitals értékelése látható a terepi adatok alapján, ha vannak ilyenek. Alatta a Lighthouse-teszt egy pontszámmal és egy „Diagnosztika” listával, konkrét pontokkal, például a szükségesnél nagyobb képekről vagy egy késleltetve betöltött LCP-képről (a pontos elnevezések a Lighthouse új verzióival változnak). A Mobil lappal kezdjen: ott általában rosszabb az eredmény, és a Google elsősorban a mobilnézetet vizsgálja (4.2. lecke).

Ha a webhelye szerepel a Search Console-ban (2. modul), nézze meg az Experience menüben a Core Web Vitals jelentést is. Ott a hasonló oldalak csoportjait látja az állapotukkal együtt, azoknál az oldalaknál is, amelyeket Ön nem tesztelt.

Az AI Builder által készített webhely megadja a szélességet és a magasságot azoknál a képeknél, amelyek mérete ismert, az oldal első fotóját azonnal és elsőbbséggel tölti be (fetchpriority="high"), a többit késleltetve, és közzétételkor a nagy fotókból 800 pixel széles változatot készít. WordPressben egy gyorsítótárazó bővítmény és a képek kicsinyítése segít a legtöbbet; a WordPress-tanfolyam 6. modulja ezzel részletesebben foglalkozik. Más weboldalkészítőknél és tárhelyszolgáltatóknál hasonlóan működik: a gombok eltérnek, az okok ugyanazok.

Összefoglalás

• A Core Web Vitals mutatók: LCP (2,5 s-ig jó), INP (200 ms-ig jó, 2024 márciusa óta a FID helyett) és CLS (0,1-ig jó), eszköztípusonként a 75. percentilisen mérve.
• Az értékelést a terepi adatok (CrUX, 28 nap) határozzák meg; a laboradatok (Lighthouse) az okok megtalálásában segítenek.
• A Google a rangsorolásban használja a Core Web Vitals mutatókat, de a relevancia az első: a tökéletes pontszám nem öncél.
• A legnagyobb nyereség: gyors szerverválasz gyorsítótárral és tömörítéssel, kis képek width és height értékkel, a legfontosabb fotó késleltetés nélküli betöltése, kevesebb harmadik féltől származó JavaScript.

Kvíz

Feladat

Feladat A4.3: Gyors válasz és könnyű képek. Adja meg egy oldal címét. A program háromszor megméri az első bájtig eltelt időt (TTFB) a mi szerverünkről, és a középső értéket veszi, ellenőrzi, hogy a HTML tömörítve érkezik-e (gzip, Brotli vagy zstd), megszámolja a width és height nélküli képeket, és megnézi, hogy a fenti legfontosabb kép nem loading="lazy" beállítással töltődik-e be. Figyelem: ez egyetlen helyről végzett mérés, nem a látogatói mérése. Nincs saját webhelye? Használja a www.wikipedia.org címet.

Feladat D4.3: Az Ön Core Web Vitals értékei. Futtassa le a PageSpeed Insights mérést a kezdőlapján és egy másik fontos oldalán, először a Mobil lapon. Jegyezze fel oldalanként: van-e terepi adat (az oldalra vagy a teljes webhelyre), a terepi adatok LCP, INP és CLS értékét, a Lighthouse-pontszámot, valamint azt az elemet, amelyet a Lighthouse LCP-elemként jelöl meg. Válassza ki azt az egy javítást, amely Ön szerint a legtöbbet hozza, és indokolja meg, miért.

További olvasnivaló

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console Súgó, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520