Core Web Vitals u 2026: što se stvarno mjeri i što s tim

Core Web Vitals su tri mjere korisničkog iskustva koje Google koristi kao signal pri rangiranju: LCP (koliko brzo se prikaže glavni sadržaj), INP (koliko brzo stranica reagira na dodir ili klik) i CLS (koliko sadržaj skače dok se stranica učitava). Nisu najvažniji signal, jer sadržaj i relevantnost i dalje odlučuju, ali su jedini koji možete popraviti bez pisanja nove riječi sadržaja.

U ovom vodiču objašnjavamo što svaka mjera stvarno mjeri, gdje gledati prave brojke, zašto zelena ocjena u PageSpeed Insightsu često ne znači ništa i kojim redom popravljati da trud ne ode u krivom smjeru.

Kako Google zapravo ocjenjuje stranicu

Google ne gleda prosjek, nego 75. percentil stvarnih posjeta. Ako stranicu posjeti 100 ljudi, LCP mora biti ispod 2,5 sekunde za barem 75 njih da bi se mjera smatrala dobrom. Tako nekoliko brzih posjeta s optičkog interneta ne može sakriti činjenicu da je stranica spora svima ostalima. Google objašnjava logiku izbora pragova i percentila u članku How the Core Web Vitals metrics thresholds were defined.

Još tri stvari koje vrijedi znati:

• Sve tri mjere moraju proći. Odličan LCP ne nadoknađuje loš INP.
• Mobitel i računalo ocjenjuju se odvojeno. Pragovi su isti, ali mobitel je gotovo uvijek lošiji jer su uređaji slabiji, a veze sporije.
• Podaci su klizni prosjek zadnjih 28 dana. Dolaze iz Chrome UX izvještaja (CrUX), odnosno anonimiziranih mjerenja stvarnih korisnika Chromea.

Koliko je to teško postići?

Teže nego što se čini. Prema Web Almanacu 2025 organizacije HTTP Archive, sve tri mjere na mobitelu prolazi tek 48 % web-stranica, a na računalu 56 %. Brojke rastu svake godine, ali to znači i da konkurencija napreduje.

Najteže je proći LCP. Prema analizi podataka iz Web Almanaca, na mobitelu dobar LCP ima oko 62 % domena, dobar INP 77 %, a dobar CLS 81 %.

Pogrešna pretpostavka koju gotovo svi imaju

PageSpeed Insights pokazuje dvije potpuno različite stvari na istoj stranici: podatke iz stvarnog prometa (gornji dio, „Discover what your real users are experiencing”) i simulaciju koju izvodi Lighthouse (donji dio s ocjenom od 0 do 100). Google za rangiranje koristi samo stvarne podatke, one iz Chrome UX izvještaja.

Simulacija je koristan alat za dijagnozu, ali ocjena 95 u simulaciji uz loše stvarne podatke ne znači ništa. Simulacija se izvodi na jednom uređaju, s jednom simuliranom vezom i jednim učitavanjem, bez ikakve interakcije. Zato INP u njoj uopće ne postoji. Lighthouse umjesto njega pokazuje Total Blocking Time, koji je tek gruba zamjena.

Ako stranica nema dovoljno prometa, stvarnih podataka za nju nema. PageSpeed Insights tada prikazuje podatke cijele domene, a Search Console grupira slične stranice i ocjenjuje ih zajedno. Zato jedan spor predložak, primjerice svi članci bloga s istom teškom temom, može povući cijelu grupu stranica.

Je li se 2026. nešto promijenilo?

Na internetu kruže tekstovi prema kojima je Google 2026. spustio prag za LCP na 2 sekunde i počeo ocjenjivati Core Web Vitals isključivo za cijelu domenu. Službena dokumentacija to ne potvrđuje. Googleova stranica Understanding Core Web Vitals and Google search results i dalje navodi 2,5 s za LCP, 200 ms za INP i 0,1 za CLS, a dokumentacija o iskustvu stranice kaže da se ono uglavnom procjenjuje za svaku stranicu posebno.

Ista dokumentacija naglašava i nešto što se često zaboravlja: dobri rezultati ne jamče prvo mjesto u pretrazi. Core Web Vitals pomažu kad je sadržaj usporediv s konkurencijom, ali ne nadoknađuju slab sadržaj. Prije nego što povjerujete senzacionalnom naslovu, provjerite izvor.

LCP — koliko traje do glavnog sadržaja

Largest Contentful Paint mjeri trenutak kad se prikaže najveći element u vidljivom dijelu ekrana. To je obično naslovna slika, veliki naslov ili slika u pozadini sekcije. Cilj je ispod 2,5 sekunde.

Najčešći uzroci sporog LCP-a su prevelika naslovna slika, font koji blokira prikaz i poslužitelj kojem treba predugo za prvi odgovor. Kod WordPressa je gotovo uvijek kombinacija sva tri.

Gdje se vrijeme zapravo gubi

LCP se dijeli na četiri dijela, i to je najkorisnija stvar koju možete znati o njemu. Mnogi odmah kreću smanjivati sliku, a Googleova analiza pokazuje da stranice sa sporim LCP-om obično troše manje od 10 % vremena na samo preuzimanje slike. Većina vremena ode prije toga: na čekanje poslužitelja i na to da preglednik uopće otkrije da sliku treba učitati.

Što popraviti, redom

1. Naslovna slika mora biti u HTML-u. Ako je umetne JavaScript, slider ili lazy-load plugin preko atributa data-src, preglednik je otkriva tek kad se skripta izvrši.
2. Maknite loading="lazy" s naslovne slike i dodajte joj fetchpriority="high". Lazy loading je odličan za slike niže na stranici, ali na glavnoj slici samo odgađa učitavanje.
3. Poslužite sliku u pravoj veličini i formatu. AVIF ili WebP, uz srcset da mobitel ne preuzima sliku za ekran od 2500 piksela.
4. Ubrzajte prvi odgovor poslužitelja. Cache cijelih stranica i CDN najviše pomažu. Ako je TTFB stalno iznad 800 ms, problem je hosting ili pozadinska obrada, a ne slika.
5. Učitajte fontove s vlastitog poslužitelja i unaprijed učitajte (preload) samo onaj font koji se koristi u naslovu.

<!-- Naslovna slika: odmah vidljiva, visokog prioriteta, bez lazy-loada -->
<img
  src="/slike/naslovna-1200.avif"
  srcset="/slike/naslovna-600.avif 600w, /slike/naslovna-1200.avif 1200w"
  sizes="(max-width: 700px) 100vw, 1200px"
  width="1200" height="630"
  fetchpriority="high"
  alt="Opis slike">

<!-- Font koji se koristi u naslovu -->
<link rel="preload" href="/fontovi/naslov.woff2" as="font" type="font/woff2" crossorigin>

Za WordPress: novije verzije same pokušavaju prepoznati glavnu sliku i ne učitavati je lijeno, ali page builderi i slideri to često pokvare. Uvijek provjerite izvorni HTML stranice, a ne samo postavke plugina. Detaljan vodič je na web.dev: Optimize Largest Contentful Paint.

INP — koliko stranica kasni na dodir

Interaction to Next Paint je 12. ožujka 2024. zamijenio stari FID. Razlika je velika: FID je mjerio samo kašnjenje prvog klika, a INP prati sve klikove, dodire i pritiske tipki tijekom cijelog posjeta i bilježi otprilike najsporiji od njih. Cilj je ispod 200 milisekundi.

Ovdje pluginovi najviše štete. Preglednik ima jednu glavnu nit na kojoj izvršava JavaScript, računa raspored i iscrtava ekran. Svaka skripta koja se vrti na glavnoj niti odgađa reakciju na dodir. Zadaće dulje od 50 ms smatraju se dugim zadaćama. Stranica koja izgleda brzo, a „zapinje” kad je dodirnete, ima problem s INP-om.

Tipični krivci

• chat widgeti, alati za snimanje sesija i heatmape,
• Google Tag Manager s desecima zaboravljenih oznaka,
• page builderi koji generiraju ogroman DOM (tisuće elemenata),
• cookie banneri i skočni prozori koji se učitavaju odmah,
• pluginovi koji učitavaju svoje skripte na svakoj stranici, iako se koriste na jednoj.

Što popraviti

1. Uklonite ono što ne koristite. Najbrža skripta je ona koja se ne učitava. Chrome DevTools ima alat Coverage koji pokazuje koliko se učitanog koda stvarno izvršava.
2. Odgodite skripte trećih strana. Chat se može učitati tek kad korisnik klikne na ikonu, a analitika nakon što se stranica prikaže. Google ima smjernice za tag managere i oznake.
3. Razbijte duge zadaće. Ako vaš kod obrađuje puno podataka odjednom, povremeno vratite kontrolu pregledniku da stigne reagirati na korisnika.
4. Dajte vizualnu povratnu informaciju odmah. Promijenite izgled gumba prije teške obrade, a ne nakon nje.

// Obrada u dijelovima: preglednik između koraka stigne reagirati na dodir
async function obradiSve(stavke) {
  for (const stavka of stavke) {
    obradi(stavka);
    if (globalThis.scheduler?.yield) {
      await scheduler.yield();               // Chrome, Edge, Firefox
    } else {
      await new Promise(r => setTimeout(r, 0)); // rezerva za Safari
    }
  }
}

Više o tome u vodiču Optimize Interaction to Next Paint.

CLS — koliko sadržaj skače

Cumulative Layout Shift mjeri koliko se elementi pomaknu nakon što su već prikazani. Cilj je ispod 0,1. To je poznat osjećaj: krenete kliknuti na link, nešto se učita iznad njega i kliknete na oglas. Pomaci koji nastanu unutar pola sekunde nakon korisnikove radnje, primjerice kad otvori izbornik, ne računaju se.

Uzrok je gotovo uvijek isti: slika bez zadanih dimenzija, oglas koji se ubaci naknadno ili font koji zamijeni drugi font pa se tekst preslaže. Popravak je jednostavan: svaka slika mora imati width i height. Prema podacima koje navodi Google, 66 % stranica ima barem jednu sliku bez zadanih dimenzija.

Što popraviti

• Slike i videi: atributi width i height. Preglednik iz njih izračuna omjer i rezervira mjesto, a slika i dalje može biti responzivna uz height: auto u CSS-u.
• Oglasi, ugrađeni videi, karte: spremnik s aspect-ratio ili min-height, da prostor postoji prije nego sadržaj stigne.
• Cookie banneri i obavijesti: neka plutaju preko sadržaja (fiksna pozicija), a ne da ga guraju prema dolje.
• Fontovi: rezervni font podesite tako da zauzima isto mjesto kao pravi (size-adjust), pa zamjena fonta ne preslaže tekst. Više u smjernicama za fontove.
• Animacije: animirajte transform, a ne top, margin ili height.
• Gumb „natrag”: ako je stranica podobna za back/forward cache, vraća se iz memorije trenutačno i bez ijednog pomaka.

/* Responzivne slike koje i dalje rezerviraju mjesto */
img { max-width: 100%; height: auto; }

/* Spremnik za oglas ili ugrađeni video */
.ugradeno { aspect-ratio: 16 / 9; width: 100%; }
.oglas    { min-height: 250px; }

Kako izmjeriti svoje brojke

Svaki alat odgovara na drugo pitanje. Ovo je redoslijed kojim ih koristimo:

1. PageSpeed Insights za brzi pregled pojedine stranice. Gledajte gornji dio sa stvarnim podacima i prebacite između mobitela i računala.
2. Izvještaj Core Web Vitals u Google Search Consoleu za cijelu web-stranicu. Pokazuje koje grupe stranica padaju i na kojoj mjeri.
3. Panel Performance u Chrome DevToolsu za dijagnozu. Prikazuje LCP, CLS i INP uživo dok klikate po stranici i pokazuje koja je skripta kriva.
4. Biblioteka web-vitals ako želite vlastita mjerenja stvarnih korisnika, primjerice slanje u Google Analytics. Korisno za stranice koje nemaju dovoljno prometa za CrUX.

Pregled svih Googleovih alata i kad koji koristiti nalazi se u članku Core Web Vitals workflows with Google tools.

Popravci po isplativosti

Nije svaki popravak jednako vrijedan. Ovo je redoslijed koji se u praksi najviše isplati:

Googleov tim za Chrome objavio je vlastiti popis najisplativijih zahvata: The most effective ways to improve Core Web Vitals.

Koliko brzo se vide rezultati

Ovo iznenadi većinu ljudi. Budući da su stvarni podaci prosjek zadnjih 28 dana, popravak ne vidite sutra. Prve promjene obično se naziru nakon nekoliko dana, a puni učinak tek nakon otprilike mjesec dana, kad iz prosjeka ispadnu svi stari, spori posjeti. Isto vrijedi i za provjeru popravka u Search Consoleu.

Zato ne mijenjajte deset stvari odjednom pa čekajte. Popravite najveći problem, provjerite ga u simulaciji i DevToolsu, pa pustite stvarne podatke da ga potvrde.

Kad krpanje više nema smisla

Postoji granica na kojoj je jeftinije prestati krpati. Ako stranica ima dvadesetak pluginova i temu koja učitava sve odjednom, svaki popravak stvara novi problem. Tada je kodirana stranica jeftinija od godine dana optimizacije.

Znakovi da ste blizu te granice:

• INP ostaje loš i nakon što ste uklonili sve pluginove bez kojih možete,
• tema ili page builder generira tisuće elemenata za jednostavnu stranicu,
• svako ažuriranje pokvari nešto što ste prethodno optimizirali,
• plaćate više pluginova za ubrzavanje, a oni se međusobno sudaraju.

To ne znači da svaki WordPress treba baciti. Znači samo da vrijedi izračunati: koliko sati optimizacije godišnje plaćate, koliko vas košta održavanje i koliko bi koštala stranica koja je brza od prvog dana.

Česta pitanja

Hoće li me bolji Core Web Vitals dovesti na prvo mjesto?

Ne sami po sebi. Google izričito kaže da dobri rezultati ne jamče visoko rangiranje. Pomažu kad je vaš sadržaj usporediv s konkurencijom, a uz to smanjuju broj posjetitelja koji odustanu prije nego što se stranica učita.

Zašto mi PageSpeed Insights svaki put pokaže drukčiju ocjenu?

Ocjena od 0 do 100 dolazi iz simulacije, koja ovisi o opterećenju poslužitelja, mreži i trenutku testiranja. Razlike od nekoliko bodova su normalne. Stvarni podaci u gornjem dijelu izvještaja mijenjaju se sporo jer pokrivaju 28 dana.

Na što se usredotočiti, mobitel ili računalo?

Na mobitel. Većina posjeta dolazi s mobitela, Google indeksira mobilnu verziju stranice, a pragovi su postavljeni prema onome što je ostvarivo na mobilnim uređajima. Ako prolazite na mobitelu, računalo će gotovo sigurno proći.

Moja stranica nema stvarnih podataka. Što sad?

To znači da nema dovoljno prometa iz Chromea za CrUX. Koristite simulaciju za grubu dijagnozu i dodajte biblioteku web-vitals da prikupljate vlastita mjerenja. Kad promet naraste, podaci će se pojaviti.

Mogu li sve ovo riješiti jednim pluginom za ubrzavanje?

Djelomično. Plugin može komprimirati slike, spajati datoteke i uključiti cache, ali ne može ukloniti teške skripte koje drugi pluginovi učitavaju ni promijeniti kako tema gradi stranicu. Pluginovi za ubrzavanje najviše pomažu LCP-u, a najmanje INP-u.