Core Web Vitals: utjecaj na SEO i iskustvo stranice

Što Core Web Vitals mjere

Core Web Vitals su mali skup metričkih podataka usmjerenih na korisnika koji opisuju tri aspekta doživljaja stranice u stvarnoj uporabi: učitavanje, interaktivnost i vizualna stabilnost. U praksi ih koristite da odgovorite: koliko brzo se pojavi primarni sadržaj, koliko je stranica responzivna na korisničke akcije i pojavljuju li se pomaci u rasporedu koji prekidaju doživljaj.

Largest Contentful Paint (LCP)

LCP mjeri kada se najveći vidljivi element u viewportu završi renderirati tijekom učitavanja stranice. Taj element često je hero slika, blok teksta iznad presavijanja ili veliki poster frame videa. LCP se odnosi na percipiranu brzinu učitavanja: ako se najveći smisleni dio sadržaja pojavi brzo, korisnici obično smatraju stranicu brzim.

Interaction to Next Paint (INP)

INP je field metrika koja hvata responzivnost mjerenjem latencije korisničkih interakcija. Za razliku od starije FID metrike koja je mjerila kašnjenje prve interakcije, INP sažima responzivnost kroz više interakcija kako bi odrazio ukupnu interaktivnost. INP ističe duge zadatke na glavnoj niti i spore event handlere koji čine stranicu tromom.

Cumulative Layout Shift (CLS)

CLS mjeri neočekivane pomake u rasporedu koji se događaju tijekom životnog ciklusa stranice. Agregira pojedinačne layout-shift događaje u rezultat koji pokazuje koliko se vidljivi sadržaj pomaknuo i koliko su pomaci bili disruptivni. Stabilni rasporedi koji rezerviraju prostor za slike, oglase i ugrađene sadržaje drže CLS nizak i smanjuju frustrirajuće reflow-e.

Kako se Core Web Vitals odnose na SEO

Core Web Vitals su dio Googleovih signala za page experience. Oni su jedan skup od mnogih signala kojetražilice koriste za rangiranje i isticanje sadržaja. Poboljšanja mogu smanjiti trenje za korisnike i povećati angažman, što podiže ukupnu vrijednost stranice, ali dobri Core Web Vitals sami po sebi ne garantiraju viši rang. Suprotno tome, vrlo loši Core Web Vitals mogu smanjiti konkurentnost stranice kada su drugi signali relevantnosti slični.

Razlikujte tri pojma: crawling (otkrivanje i dohvat od strane bota), indexing (što Google pohranjuje) i ranking (kako se rezultati poredaju). Core Web Vitals utječu na page experience i posredno na ranking; oni ne određuju hoće li se URL crawlat ili indexirati. Također imajte na umu operativne činjenice koje utječu na mjerenje i sanaciju: od srpnja 2024. Google za Search po defaultu crawla sa Googlebot Smartphone, a početkom 2024. Google je uklonio tradicionalne cached stranice — oba znače da je mobilni prikaz i trenutno živi sadržaj centralan za izračun i prikaz experience signala.

Field vs. lab mjerenje — što koristiti i kada

Trebat će vam i field (stvarni korisnici) i lab (sintetički) podaci za dijagnostiku i verifikaciju popravaka. Field podaci pokazuju kako stvarni korisnici na raznim uređajima i mrežama doživljavaju vaše stranice; lab podaci daju reproducibilan, debug-abilan snimak u kontroliranim uvjetima.

Alati za field

Koristite Core Web Vitals report uGoogle Search Console za trendove na razini sajta (zahtijeva vlasništvo), PageSpeed Insights za sažetke po URL-u i Chrome UX Report (CrUX) za agregirane podatke stvarnih korisnika. Za vlastito prikupljanje instrumentirajte stranice s web-vitals library i šaljite mjerenja u svoju analitiku ili APM za segmentaciju po uređaju, državi i vrsti veze.

Alati za lab

Koristite Lighthouse (u DevTools ili CLI) i Performance panel u Chrome DevTools za debug koji se oslanja na trace. Lab pokretanja omogućuju reproduciranje dugih zadataka, inspekciju glavne niti i hvatanje waterfall timinga kako biste identificirali resurse koji blokiraju renderiranje.

Uobičajeni uzroci i praktična rješenja

LCP: uzroci i popravci

Tipični uzroci: sporo vrijeme odgovora servera, render-blocking CSS/JavaScript, velike neoptimizirane slike, client-side rendering koji odgađa meaningful paint i prioritizacija resursa koja odgađa najveći vidljivi element.

Praktični popravci: poboljšajte TTFB servera kroz caching i CDN; servirajte kritični CSS inline za sadržaj iznad presavijanja i odgodite nekritični CSS; prioritizirajte LCP resurse s rel=preload i pravilnim resource priorities; komprimirajte i promijenite veličinu slika, koristite moderne formate i responsive srcset; razmislite o server-side rendering ili hybrid rendering pristupu za stranice gdje client rendering odgađa primarni sadržaj.

INP: uzroci i popravci

Tipični uzroci: dugiJavaScript zadaci koji blokiraju glavnu nit, teški sinkroni poslovi tijekom korisničkih interakcija, veliki bundleri koji pokreću inicijalizacijski kod i neoptimizirani event handleri.

Praktični popravci: podijelite kod na manje komade i odgodite nepotrebne skripte, premjestite posao iz glavne niti koristeći web workers, uklonite ili odgodite velike inicijalizacijske zadatke do nakon prve interakcije, učinite event handlere brzim (izvršite minimalno posla, odložite teži rad preko requestIdleCallback ili setTimeout) i izbjegavajte pattern-e koji uzrokuju layout-thrashing (čitanje–pisanje–čitanje).

CLS: uzroci i popravci

Tipični uzroci: slike ili iframes bez width/height atributa, oglasi ili embedovi ubacivani bez rezerviranog prostora, web fontovi koji izazivaju layout swap i umetanja DOM-a iznad postojećeg sadržaja.

Praktični popravci: uvijek uključite width i height atribute (ili CSS aspect-ratio) za slike i iframe-ove; rezervirajte prostor za oglase i dinamički sadržaj koristeći CSS kontejnere; koristite font-display: swap ili optional da izbjegnete faze nevidljivog teksta; izbjegavajte umetanje sadržaja iznad postojećeg osim ako nije rezerviran prostor; preferirajte transform-based animacije umjesto animiranja svojstava koja utječu na layout.

Prioritiziranje rada i implementacija popravaka

Počnite s trijanjem stranica gdje se loši Core Web Vitals i velik promet preklapaju. Koristite site-level Search Console podatke da nađete grupe URL-ova s lošim field metrikkama, zatim debugirajte reprezentativne URL-ove u lab alatima. Za svaku ciljanu stranicu napravite kratak plan sanacije koji navodi brze pobjede (kompresija slika, rel=preload za LCP, odgađanje nekritičnog JS), srednje zahvate (code-splitting, server-side rendering) i veća ulaganja (promjene arhitekture ili redesign UX-a).

Kad deployate popravke, prikupite real-user metrics (RUM) za definirano validacijsko razdoblje i usporedite percentile i segmente po uređajima. Budući da je page experience samo jedan od mnogih signala za ranking, tretirajte poboljšanja Core Web Vitals kao dio iterativnog programa: mjerite, popravljajte najviše utjecajne stavke prvo, pratite ponašanje korisnika i rangiranje, iterirajte.

Provjera i checklist za rješavanje problema

Slijedite ovaj checklist kad trebate verificirati Core Web Vitals probleme i potvrditi popravke:

1. Trendovi na razini sajta: provjerite Core Web Vitals report u Google Search Console za grupe URL-ova koje prikazuju status 'poor' ili 'needs improvement' (zahtijeva vlasništvo).

2. Snapshot po URL-u iz field-a: pokrenite PageSpeed Insights za pregled field i lab podataka za određeni URL; pregledajte CrUX field podatke i dijagnostičke sugestije.

3. Reproducirajte u labu: pokrenite Lighthouse u incognito DevTools sesiji i analizirajte Performance trace. Upotrijebite Performance panel da vidite duge zadatke i aktivnost glavne niti.

4. Prikupite ciljane RUM podatke: instrumentirajte stranice s web-vitals library i šaljite mjerenja u svoju analitiku. Primjer module snippet-a za brzo hvatanje:

<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. Provjerite paritet uređaja: budući da Google koristi mobile view kao primarnu osnovu za indexing i page experience, verificirajte da vaš mobilni HTML servira jednak ili ekvivalentan sadržaj i da su responsive slike, CSS i kritični resursi optimizirani za smartphone viewport veličine.

6. Izolirajte utjecaj third-party skripti: učitajte stranicu s i bez third-party skripti (oglasi, analytics, widgeti) u lab runu da izmjerite njihov utjecaj na LCP, INP i CLS. Zamijenite ili lazy-loadajte dobavljače koji uzrokuju prekomjerne duge zadatke ili neočekivane pomake u layoutu.

Uobičajene pogreške i zamke u dijagnostici

• Tretiranje lab rezultata kao field stvarnosti. Lab pokretanja su bitna za debug, ali simuliraju jedan device/network profil i možda ne predstavljaju vašu korisničku bazu. Uvijek validirajte s field RUM.

• Popravci samo za desktop. Budući da Google ocjenjuje page experience prvenstveno na mobilnom renderiranju, popravci moraju ciljano rješavati mobilno iskustvo prvo, osim ako analitika ne pokaže drugačiji uređajni miks za važne korisničke puteve.

• Pretjerano optimiziranje jedne metrike. Poboljšanja trebaju poštovati potrebe korisnika: agresivno odgađanje fontova da bi se smanjio CLS može naštetiti čitljivosti; uklanjanje važnih skripti za smanjenje INP-a može onemogućiti funkcionalnost. Koristite eksperimente i mjerite korisničke metrike izvan Core Web Vitals, poput angažmana i konverzija.

• Ignoriranje nasumične varijabilnosti. Field podaci sadrže šum: geografske, operatorne i uređajne varijacije mogu mijenjati percentile. Segmentirajte RUM po relevantnim kohortama kako biste identificirali stvarne regresije.

Kada prihvatiti kompromise

Neke stranice pružaju kompleksna interaktivna iskustva koja inherentno troše CPU ili mrežni budget. Ako je funkcionalnost ključna za vaš proizvod i donosi mjerljivu vrijednost korisnicima, dokumentirajte kompromis, optimizirajte sve ostalo što možete i pratite ponašanje korisnika. Prioritizirajte popravke koji smanjuju trošak te funkcije (npr. incremental hydration, partial hydration ili izoliranje teškog koda u odgođeni bundle) umjesto potpunog uklanjanja funkcionalnosti.

FAQ