Core Web Vitals: hatás az SEO-ra és az oldalélményre

Mit mérnek a Core Web Vitals

A Core Web Vitals egy kis, felhasználó-központú teljesítménymutatók halmaza, amely három szempontot ír le arról, hogyan érződik egy oldal valós használat közben: betöltés, interaktivitás és vizuális stabilitás. Gyakorlatban ezekkel válaszolhat arra, hogy milyen gyorsan jelenik meg a fő tartalom, mennyire válaszkész az oldal a felhasználói inputokra, és zavarja-e a felhasználói élményt a layout elmozdulás.

Largest Contentful Paint (LCP)

Az LCP azt méri, mikor fejeződik be a legnagyobb látható elem renderelése a viewporton a betöltés során. Ez gyakran egy hero kép, a fent látható szövegrész, vagy egy nagy videó poszterképe. Az LCP az észlelt betöltési sebességről szól: ha a legfontosabb tartalom gyorsan megjelenik, a felhasználók általában gyorsnak érzik az oldalt.

Interaction to Next Paint (INP)

Az INP a field metrika, amely a válaszkészséget rögzíti a felhasználói interakciók késleltetésének mérésével. Ellentétben a régebbi FID-metrikával, amely az első interakció késését mérte, az INP az interaktivitást sok interakció összegzéseként tükrözi. Az INP kiemeli a hosszú main-thread feladatokat és a lassú event kezelőket, amelyek lassúnak érzett oldalt okoznak.

Cumulative Layout Shift (CLS)

A CLS a váratlan elrendezés-változásokat méri, amelyek az oldal életciklusa alatt történnek. Egyes layout-shift eseményeket egy pontszámmá aggregál, amely megmutatja, mennyit mozdult el a látható tartalom és mennyire volt zavaró a váltás. A stabil elrendezések, amelyek helyet tartanak képeknek, hirdetéseknek és beágyazásoknak, alacsonyan tartják a CLS-t és csökkentik a bosszantó újrafestéseket.

Hogyan kapcsolódnak a Core Web Vitals az SEO-hoz

A Core Web Vitals a Google oldalélmény-jelek részei. Ezek egyike azoknak a sok jelnek, amelyeket keresőmotorok használnak a rangsoroláshoz és a tartalom megjelenítéséhez. Javításuk csökkentheti a felhasználói súrlódást és növelheti az elköteleződést, ami javítja egy oldal összértékét, de önmagában jó Core Web Vitals nem garantál magasabb rangsorolást. Fordítva, nagyon rossz Core Web Vitals csökkentheti az oldal versenyképességét, ha a relevancia többi jele hasonló.

Tartsa tisztán a három megkülönböztetést: crawling (bot felfedezés és lekérés), indexing (amit a Google tárol), és ranking (az eredmények sorrendje). A Core Web Vitals az oldalélményt és így a rangsorolást befolyásolják; nem határozzák meg, hogy egy URL fel legyen-e keresve vagy indexelve. Vegye figyelembe az üzemeltetési tényeket is, amelyek a mérésre és javításra hatnak: 2024 júliusa óta a Google alapértelmezés szerint Googlebot Smartphone-tal crawli az oldalakat a Search-hez, és 2024 elején a Google eltávolította a hagyományos cached oldalak — mindkettő azt jelenti, hogy a mobil nézet és az aktuális élő tartalom központi szerepet kap abban, hogyan számítódnak és jelennek meg az élményjelek.

Field vs. lab measurement — mikor mit használjon

Diagnosztikához és javítások ellenőrzéséhez mind field (valódi felhasználó) és lab (szintetikus) adatra szükség van. A field adat megmutatja, hogyan tapasztalják meg az oldalait a valós felhasználók különböző eszközökön és hálózatokon; a lab adat reprodukálható, hibakereshető pillanatképet ad kontrollált körülmények között.

Field eszközök

Használja a Core Web Vitals jelentést a Google Search Console -ben site-szintű trendekhez (sajátjog szükséges), PageSpeed Insightsot URL-szintű field összefoglalókhoz, és a Chrome UX Reportot (CrUX) aggregált valós-felhasználói adatokhoz. Egyedi gyűjtéshez instrumentálja az oldalakat a web-vitals könyvtárral, és küldje az adatokat az analytics vagy APM gyűjtésébe eszköz-, ország- és kapcsolat-típus szerinti szeparáláshoz.

Lab eszközök

Használja a Lighthouse-t (DevTools-ban vagy CLI-ben) és a Performance panelt a Chrome DevTools-ban trace alapú hibakereséshez. Lab futtatásokkal reprodukálhat hosszú feladatokat, megvizsgálhatja a main threadet és rögzítheti a waterfall időzítést a render-blokkoló erőforrások azonosításához.

Gyakori okok és gyakorlati javítások

LCP: okok és javítások

Tipikus okok: lassú szerverválaszidők, render-blokkoló CSS/JavaScript, nagy, nem optimalizált képek, kliens-oldali rendering, amely késlelteti a jelentős festést, és az erőforrások prioritizálása, amely hátráltatja a legnagyobb látható elemet.

Gyakorlati javítások: javítsa a szerver TTFB-jét cache-eléssel és CDN elhelyezéssel; szolgáljon ki kritikus CSS-t inline az above-the-fold tartalomhoz és halassza el a nem kritikus CSS-t; priorizálja az LCP erőforrásokat rel=preload használatával és megfelelő resource priority beállítással; tömörítse és méretezze át a képeket, használjon modern formátumokat és responsive srcset-et; fontolja meg a server-side renderinget vagy hibrid renderelést olyan oldalakon, ahol a kliens-oldali renderelés késlelteti a fő tartalmat.

INP: okok és javítások

Tipikus okok: hosszú JavaScript feladatok, amelyek blokkolják a main threadet, erőforrásigényes szinkron munka felhasználói interakciók közben, nagy bundlerek, amelyek inicializációs kódot futtatnak, és nem optimalizált event kezelők.

Gyakorlati javítások: bontsa a kódot kisebb csomagokra és halassza el a nem alapvető script-eket, mozgassa a munkát a main threaddől web workerek használatával, távolítsa el vagy késleltesse a nagy inicializációs feladatokat az első input utánra, tegye gyorssá az event kezelőket (végezzen minimális munkát, ütemezze a nehéz feladatokat requestIdleCallback vagy setTimeout segítségével), és kerülje a layout-thrashing mintákat (read–write–read).

CLS: okok és javítások

Tipikus okok: képek vagy iframe-ek width/height attribútum nélkül, hirdetések vagy beágyazások helyfenntartó tér nélkül injektálva, webfontok okozta layout-csere, és DOM beszúrások a meglévő tartalom fölé.

Gyakorlati javítások: mindig adjon meg width és height attribútumot (vagy CSS aspect-ratio-t) képekhez és iframe-ekhez; foglaljon helyet hirdetéseknek és dinamikus tartalomnak CSS container-ekkel; használja a font-display swap vagy optional beállítást, hogy elkerülje a láthatatlan szöveg fázisát; kerülje a tartalom beszúrását a meglévő tartalom fölé kivéve, ha hely van lefoglalva; részesítse előnyben a transform-alapú animációkat a layout-ot érintő tulajdonságok animálása helyett.

A feladatok priorizálása és a javítások végrehajtása

Kezdje azzal, hogy előszűrje azokat az oldalakat, ahol rossz Core Web Vitals és magas forgalom találkozik. Használja a site-szintű Search Console adatokat, hogy megtalálja az URL-csoportokat rossz field metrikákkal, majd hibakeresse a reprezentatív URL-eket lab eszközökkel. Minden céloldalhoz készítsen rövid javítási tervet, amely felsorolja a gyors nyeréseket (kép tömörítés, rel=preload LCP, nem kritikus JS elhalasztása), közepes munkát (code-splitting, server-side rendering) és nagyobb beruházásokat (architektúraváltás vagy UX áttervezés).

Amikor élesíti a javításokat, gyűjtsön real-user metrikákat (RUM) egy meghatározott ellenőrzési időablakra és hasonlítsa össze percentiliseket és eszközszegmenseket. Mivel az oldalélmény csak az egyik a sok rangsorolási jel közül, kezelje a Core Web Vitals javításokat iteratív program részeként: mérjen, javítsa a legnagyobb hatású elemeket először, figyelje a felhasználói viselkedést és a rangsorolást, majd ismételje.

Ellenőrző és hibakeresési tennivalók listája

Kövesse ezt az ellenőrzőlistát, amikor meg kell erősíteni Core Web Vitals problémákat és ellenőrizni kell a javításokat:

1. Site-szintű trendek: ellenőrizze a Core Web Vitals jelentést a Google Search Console-ban az olyan URL-csoportoknál, amelyek 'poor' vagy 'needs improvement' státuszt mutatnak (sajátjog szükséges).

2. URL-szintű field pillanatkép: futtassa a PageSpeed Insights-ot egy adott URL-en a field és lab adatok megtekintéséhez; tekintse át a CrUX field adatokat és a diagnosztikai javaslatokat.

3. Reprodukálás labban: futtassa a Lighthouse-ot egy inkognitó DevTools munkamenetben és vizsgálja meg a Performance trace-t. Használja a Performance panelt a hosszú feladatok és a main-thread aktivitás megtekintéséhez.

4. Célzott RUM gyűjtése: instrumentálja az oldalakat a web-vitals könyvtárral és küldje a méréseket az analyticsába. Példa modul snippet a gyors rögzítéshez:

<script type="module">import {getCLS, getLCP, getINP} from 'https://unpkg.com/web-vitals?module';getCLS(r => console.log('CLS', r));getLCP(r => console.log('LCP', r));getINP(r => console.log('INP', r));</script>

5. Eszközparitás ellenőrzése: mivel a Google a mobil nézetet használja elsődleges alapként az indexeléshez és az oldalélményhez, ellenőrizze, hogy a mobilra szolgáltatott HTML egyenértékű vagy ekvivalens tartalmat ad-e, és hogy a responsive képek, CSS és kritikus erőforrások optimalizáltak-e okostelefon viewport méretekre.

6. Harmadik fél hatásának izolálása: töltse be az oldalt lab futtatásban harmadik fél script-ekkel és nélkülük (hirdetések, analytics, widgetek), hogy mérje azok LCP, INP és CLS hatását. Cserélje vagy lazy-loadolja azokat a szolgáltatókat, akik túl sok hosszú feladatot vagy váratlan layout elmozdulást okoznak.

Gyakori hibák és diagnosztikai csapdák

• A lab pontszámok valós field valóságnak tételezése. A lab futtatások elengedhetetlenek a hibakereséshez, de egyetlen eszköz/hálózat profilt szimulálnak és nem feltétlenül reprezentálják a felhasználóit. Mindig validáljon field RUM-mal.

• Csak asztali javítások. Mivel a Google elsősorban a mobil renderelésen értékeli az oldalélményt, a javításoknak először a mobil élményre kell célozniuk, kivéve ha az analytics más eszközmegoszlást mutat fontos felhasználói útvonalaknál.

• Egyetlen metrika túl-optimalizálása. A javításoknak figyelembe kell venniük a felhasználói igényeket: a betűkészletek agresszív elhalasztása a CLS csökkentése érdekében ronthatja az olvashatóságot; fontos scriptek eltávolítása az INP csökkentése miatt megsértheti a funkcionalitást. Használjon kísérleteket és mérje a Core Web Vitals-on túli felhasználói mutatókat, mint az elköteleződés és konverzió.

• A random variabilitás figyelmen kívül hagyása. A field adatok zajosak: földrajzi, szolgáltatói és eszközváltozások megváltoztathatják a percentiliseket. Szeparálja a RUM-ot jelentős kohorszokra, hogy azonosítsa a valódi regressziókat.

Mikor fogadjon el kompromisszumokat

Néhány oldal összetett interaktív élményt nyújt, amely természeténél fogva CPU- vagy hálózati költségekkel jár. Ha egy funkció a termékének lényege és mérhető felhasználói értéket ad, dokumentálja a kompromisszumot, optimalizáljon mindent, amit lehet, és figyelje a felhasználói viselkedést. Prioritizálja azokat a javításokat, amelyek csökkentik a funkció költségét (pl. incremental hydration, partial hydration, vagy a nehéz kód izolálása egy deferred bundle-ben) ahelyett, hogy a funkcionalitást teljesen eltávolítaná.

GYIK

A Core Web Vitals rangsorolási tényezőnek számítanak?

Igen — a Core Web Vitals a Google oldalélmény-jeleinek része, amelyek befolyásolhatják a rangsorolást. Egy a sok bemenet közül, és javításuk javítja a felhasználói élményt és a versenyképességet, de önmagukban jó pontszámok nem garantálják a magasabb helyezést.

Lab eszközökre vagy field adatokra optimalizáljak?

Mindkettőt. Használja a lab eszközöket (Lighthouse, DevTools) az reprodukáláshoz és hibakereséshez, és a field adatokat (Search Console Core Web Vitals, CrUX, RUM) az ellenőrzéshez, hogy a javítások javítják-e a valódi felhasználók élményét különböző eszközökön és hálózatokon.

Károsíthatják-e a Core Web Vitals-t a harmadik fél scriptjei?

Igen. Hirdetések, tag managerek, chat widgetek és analytics szolgáltatók hosszú feladatokat adhatnak hozzá vagy olyan tartalmat injektálhatnak, ami layout-eltolást okoz. Izolálja és mérje a hatást úgy, hogy lab futtatásban letiltja vagy elhalasztja ezeket a script-eket, és részesítse előnyben az olyan szolgáltatókat, amelyek támogatják az async betöltést, lefoglalt helyet a beágyazásoknak és könnyű runtime-ot.

Mennyi idő múlva látszanak a javítások a Search Console-ban?

A Search Console Core Web Vitals jelentése többhetes ablakban aggregálja a field adatokat, így számítson némi késésre, mielőtt a változások teljesen megjelennek. Az azonnali ellenőrzéshez támaszkodjon a RUM csővezetékre és a lab tesztekre a gyors validáláshoz, majd figyelje a Search Console-t a szélesebb körű elterjedés megjelenéséhez eszközökön és felhasználókon.