Zamislite da imate web stranicu koja izgleda savršeno, ima odličan sadržaj i jasnu ponudu — ali svaki put kad korisnik klikne na link, treba pričekati gotovo sekundu dok se išta dogodi. Ili zamislite da je stranica gotovo učitana, ali gumb za kontakt svaki put “skoči” par milimetara prema dolje upravo u trenutku klika. To su problemi koji se ne vide u dizajnu, ali ih korisnik odmah osjeti — a Google ih od 2021. godine sustavno mjeri i koristi kao dio svog algoritma rangiranja.
Core Web Vitals su tri metrike kojima Google mjeri stvarno korisničko iskustvo na web stranicama: brzinu učitavanja, responzivnost i vizualnu stabilnost. U 2026. godini, nakon što je INP zamijenio zastarjelu FID metriku i po objavi ažuriranja algoritma u ožujku, ove metrike više nisu samo tehnička sitnica koju prate programeri. One izravno utječu na to gdje će se vaša stranica pojaviti u rezultatima pretrage — i koliko posjetitelja ćete zadržati ili izgubiti u prvih nekoliko sekundi.
Ovaj vodič objašnjava svaku od tri metrike jasnim primjerima, prikazuje konkretne pragove koji razlikuju “dobro” od “loše”, i daje praktične korake za poboljšanje — bez pretjeranog tehničkog žargona.
Što su Core Web Vitals i zašto su postali SEO faktor
Google je Core Web Vitals uveo 2021. godine kao dio šireg koncepta “Page Experience” — skupa signala koji mjere koliko je ugodna posjeta nekoj web stranici sa stajališta stvarnog korisnika, a ne samo iz perspektive sadržaja i ključnih riječi.
Tri metrike nisu odabrane nasumično. Google je analizirao milijarde interakcija korisnika s web stranicama i identificirao tri aspekta iskustva koja najdirektnije koreliraju s tim hoće li korisnik ostati na stranici ili je napustiti: koliko brzo vidi da se nešto učitava, koliko brzo stranica reagira na njegovu akciju, i koliko je stranica vizualno stabilna dok se učitava.
Važno je razumjeti i kako Google mjeri ove metrike: ne koristi laboratorijske testove, nego stvarne podatke korisnika prikupljene putem Chrome preglednika (tzv. CrUX — Chrome User Experience Report). Stranica prolazi Core Web Vitals provjeru tek kada 75% stvarnih posjetitelja ima “dobro” iskustvo za sve tri metrike istovremeno. Jedan loš rezultat ruši ocjenu cijele stranice — čak i ako su preostale dvije metrike izvrsne.
Prema podacima iz 2026. godine, samo 47% web stranica prolazi sve tri metrike. Ostatak gubi između 8% i 35% prometa, konverzija i prihoda direktno zbog lošeg korisničkog iskustva.
Pregled triju metrika — u jednom pogledu
Prije nego zaronimo u svaku metriku zasebno, evo tablice koja prikazuje sve pragove odjednom:

| Metrika | Što mjeri | Dobro ✅ | Treba poboljšanje ⚠️ | Loše ❌ |
|---|---|---|---|---|
| LCP | Brzina učitavanja | < 2,5 s | 2,5 – 4,0 s | > 4,0 s |
| INP | Responzivnost | < 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Vizualna stabilnost | < 0,1 | 0,1 – 0,25 | > 0,25 |
Google evaluira svaku metriku na 75. percentilu stvarnih posjeta u zadnjih 28 dana. Dakle, nije dovoljno da vaša stranica bude brza za 50% posjetitelja — mora biti brza za veliku većinu njih, uključujući i one s lošijim uređajima i sporijim internetom.
LCP — Largest Contentful Paint: Koliko brzo korisnik vidi da se stranica učitava?
Što LCP mjeri
LCP (Largest Contentful Paint — slikovito prevedeno: “prikaz najvećeg sadržajnog elementa”) bilježi trenutak u kojem se u vidljivom dijelu ekrana pojavi najveći element stranice. To je obično hero fotografija, naslov u velikom fontu, video ili baner. Taj trenutak Google koristi kao proxy za percepciju brzine: ako se taj element pojavio, korisnik zna da stranica radi i da se učitava.
Konkretan primjer: Posjetitelj klikne na link vašeg apartmana s Booking.com. Preglednik počne učitavati stranicu. Nakon 1,2 sekunde pojavi se logotip — ali to nije LCP. Nakon 2,8 sekundi se napokon pojavi glavna fotografija interijera (koja je najveći element na stranici). LCP je dakle 2,8 sekunde — što ga stavlja u zonu “Treba poboljšanje”.
Zašto LCP često pada
Najčešći uzrok loših LCP rezultata su neoptimizirana hero slika (preveike dimenzije, krivi format), sporim serverom koji kasni s isporukom HTML-a, ili CSS/JavaScript datoteke koje blokiraju renderiranje stranice dok se ne učitaju.

Kako poboljšati LCP
Slijedite ovaj redoslijed prioriteta:
1. Optimizirajte hero sliku. Pretvorite je u WebP ili AVIF format (25–35% manji od JPEG-a bez vidljive razlike u kvaliteti), smanjite dimenzije na stvarno prikazanu veličinu i dodajte loading="eager" te fetchpriority="high" atribute isključivo na taj element.
2. Koristite <link rel="preload"> za LCP sliku. Stavite u <head> stranicu sljedeći tag, da preglednik počne preuzimati sliku što je ranije moguće, paralelno s ostatkom stranice:
<link rel="preload" as="image" href="/slike/hero.webp" fetchpriority="high" />
3. Poboljšajte TTFB (Time to First Byte). Ako server kasni s odgovorom (provjerite u PageSpeed Insights), razmotrite CDN, caching ili prelazak na brži hosting.
4. Eliminirajte render-blocking resurse. CSS i JavaScript koji se učitavaju u <head> bez defer ili async atributa blokiraju prikaz stranice. Svaki nebitni skript (chat widget, treće strane analitike) odgađa LCP.
INP — Interaction to Next Paint: Koliko brzo stranica reagira na vaš klik?
Što INP mjeri i zašto je zamijenio FID
INP (Interaction to Next Paint) je metrika koja mjeri koliko brzo stranica vizualno reagira na svaku interakciju korisnika — svaki klik, dodir ili pritisak tipke — i to kroz cijelu posjetu, ne samo pri prvoj interakciji.
Ovo je ključna razlika u odnosu na metriku koju je INP zamijenio u ožujku 2024.: FID (First Input Delay) mjerio je samo prvu interakciju korisnika sa stranicom, što je bio nedovoljno precizan pokazatelj. Stranica je mogla imati odličan FID, a biti brutalno spora pri kliku na filtar u košarici ili pri otvaranju padajućeg izbornika — jer FID te kasnije interakcije jednostavno nije ni mjerio. INP taj nedostatak ispravlja: gleda na najsporiju interakciju zabilježenu tijekom cijele sesije.
Konkretan primjer: Posjetitelj web shopa klikne na filter “Sortiraj po cijeni”. Stranica kao da zamrzne na 420 milisekundi — gumb vizualno ne reagira, lista se ne ažurira, ništa se ne pomiče. INP za tu interakciju iznosi 420 ms, što je u zoni “Loše” (prag je 200 ms). Korisnik ne zna je li klik registriran, pa klikne opet, što daljnje pogoršava situaciju.

Zašto je INP najteže ispraviti
Prema podacima iz 2026. godine, čak 43% web stranica ne prolazi INP prag od 200 milisekundi — što ga čini najčešće neuspješnom Core Web Vitals metrikom. Razlog je jednostavan: dok su LCP i CLS problemi koji se relativno lako identificiraju i rješavaju (optimizacija slika, rezerviranje prostora), INP zahtijeva dublje zahvate u JavaScript arhitekturu stranice.
Svaki JavaScript koji dulje od 50 milisekundi zauzima “main thread” preglednika potencijalno blokira vizualnu reakciju na korisnički klik. To su najčešće: teški JS frameworki koji pokušavaju previše raditi odjednom, treće strane skripte (chat, analytics, remarketing pikseli) koje se izvršavaju u lošem trenutku, i dugački “tasks” koji ne ustupaju kontrolu pregledniku između operacija.
Kako poboljšati INP
Odgodite treće strane skripte. Chat widgeti, Meta Pixel, Google Tag Manager — sve to dodajte s defer atributom ili ih učitajte tek nakon što se stranica potpuno prikaže. Oni su jedan od najčešćih INP ubojica.
Razlomite dulje JavaScript zadatke. Svaki zadatak koji traje više od 50 ms treba biti podijeljen u manje cjeline, s pauzama u kojima preglednik može reagirati na korisničke akcije.
Koristite content-visibility: auto na dijelove stranice koji nisu vidljivi u viewportu — to pregledniku govori da ih privremeno ne renderira, čime se smanjuje pritisak na main thread.
CLS — Cumulative Layout Shift: Zašto elementi “skaču” po stranici?
Što CLS mjeri
CLS (Cumulative Layout Shift) mjeri vizualnu stabilnost stranice — konkretno, koliko sadržaj neočekivano mijenja položaj dok se stranica učitava. Za razliku od LCP i INP, CLS nije vremenski mjerena metrika, nego matematički izračun koji uzima u obzir veličinu pomaknutog elementa i udaljenost za koliko se pomaknuo.
Svaki nepredviđeni pomak elementa koji korisnik nije inicirao (klik, scroll) negativno utječe na CLS rezultat. “Dobar” CLS iznosi ispod 0,1 — što znači male, gotovo neprimjetne pomake.
Konkretan primjer: Korisnik čita uvod na stranici i pomicanjem miša kreće prema gumbu “Pošaljite upit”. U tom trenutku se učita slika iznad teksta (bez unaprijed rezerviranog prostora) i gurne tekst prema dolje za 200 pixela. Gumb koji je korisnik ciljao sada je na drugom mjestu — klik pogodi krivu stvar. Taj scenarij je klasičan CLS problem.

Najčešći uzroci CLS-a
| Uzrok | Opis | Rješenje |
|---|---|---|
| Slike bez dimenzija | Preglednik ne zna koliko prostora rezervirati | Uvijek dodati width i height atribute na <img> tagove |
| Web fontovi (FOUT) | Font se učita i zamijeni fallback font | Koristiti font-display: swap i preloadati fontove |
| Reklame i embeddani sadržaj | Ad slotovi koji se učitaju asinkrono | Rezervirati prostor za ad slotove unaprijed |
| Cookie banneri iznad foldа | Pojavljuju se nakon učitavanja i guraju sadržaj | Koristiti fixed/sticky pozicioniranje bez utjecaja na layout |
| Dinamički ubačen sadržaj | JavaScript koji dodaje elemente iznad postojećeg sadržaja | Dodavati dinamički sadržaj ispod foldа ili rezervirati prostor |
Kako popraviti CLS
Pravilo je jednostavno: svaki element koji se učitava asinkrono mora imati unaprijed rezerviran prostor. To se postiže definiranjem width i height atributa na svim slikama i videima, aspect-ratio CSS pravilom za embeddane elemente, i izbjegavanjem ubacivanja sadržaja iznad postojećeg teksta nakon učitavanja stranice.
<!-- Loše: preglednik ne zna dimenzije, pomak pri učitavanju -->
<img src="hero.jpg" alt="Hero slika">
<!-- Dobro: preglednik rezervira prostor odmah -->
<img src="hero.jpg" alt="Hero slika" width="1200" height="600">
Alati za mjerenje Core Web Vitals
Razlika između “lab podataka” i “field podataka” jedna je od stvari koje najviše zbunjuju vlasnike web stranica. Lab podaci su simulirani (PageSpeed Insights, Lighthouse), a field podaci su stvarni — prikupljeni od pravih posjetitelja vaše stranice putem Chrome preglednika. Google za rangiranje koristi isključivo field podatke.
Praktična implikacija: vaša stranica može imati odlične rezultate u PageSpeed Insights testu, a istovremeno loše field podatke u Search Consoleu — jer lab test simulira idealne uvjete, dok field podaci uključuju posjetitelje sa starijim uređajima i sporijim internet vezama.
| Alat | Vrsta podataka | Što pruža | Besplatan? |
|---|---|---|---|
| PageSpeed Insights | Lab + Field | Detaljna analiza, prijedlozi poboljšanja | ✅ Da |
| Google Search Console | Field (CrUX) | Pregled po URL grupama, trendovi kroz vrijeme | ✅ Da |
| Chrome DevTools | Lab | Detaljno debugiranje, waterfall dijagram | ✅ Da |
| web.dev/measure | Lab | Lighthouse izvještaj za jednu stranicu | ✅ Da |
| CrUX Dashboard (Looker) | Field | Vizualni dashboard za cijelu domenu | ✅ Da |
| WebPageTest | Lab | Napredno testiranje, video usporedbe | ✅ Da |
Preporuka za redovito praćenje: Google Search Console za field podatke + PageSpeed Insights za dijagnostiku i prijedloge. Ova kombinacija pokriva 90% onoga što trebate za svakodnevno praćenje performansi.
Što je novo u 2026: ažuriranje algoritma i nove metrike na vidiku
Ožujak 2026. donio je najznačajniji update Core Web Vitals sustava od originalnog uvođenja 2021. Dvije promjene su posebno važne:
INP je dobio jednaku težinu kao LCP i CLS. Google je potvrdio da INP više nije “mlađi brat” LCP metrici, nego ravnopravan rangirački signal. Stranice s INP rezultatom u “Treba poboljšanje” zoni počele su bilježiti mjerljive padove pozicija u konkurentnim pretragama.
Visual Stability Index (VSI) je najavljen. Dok CLS mjeri pomake samo pri učitavanju stranice, VSI promatra vizualnu stabilnost kroz cijelu posjetu — uključujući pomake pri scrollanju i interakcijama korisnika. Google ga za sada ne koristi kao primarni rangirački signal, ali najavljuje da će ga uvesti u budućnosti. Pametno je početi voditi računa o VSI već sada, jer se ispravlja na isti način kao CLS — rezerviranjem prostora i izbjegavanjem neočekivanih promjena layouta.
Zašto je mobilna verzija stranice presudna
Više od 60% Google pretraga u 2026. dolazi s mobilnih uređaja. Google koristi mobile-first indexing — što znači da su Core Web Vitals rezultati vaše mobilne verzije ti koji određuju rangiranje, čak i u desktop rezultatima pretrage. Možete imati blistavo brzu desktop stranicu s LCP-om od 0,9 sekundi, ali ako mobilna verzija te iste stranice ima LCP od 3,8 sekundi, to je rezultat koji Google uzima u obzir pri rangiranju.
Mobilno testiranje otežavaju dva faktora: mobilni uređaji imaju slabije procesore koji sporije izvršavaju JavaScript, i korisnici su često na 4G ili čak 3G mreži s varijabilnim brzinama. Preporuka je testirati stranicu u PageSpeed Insightsu uvijek na mobilnoj kartici, i koristiti Chrome DevTools “Throttling” opciju za simulaciju sporijeg uređaja pri lokalnom razvoju.
Brza dijagnoza: gdje ste sada?
Ako nikad niste provjerili Core Web Vitals rezultate svoje stranice, evo najbrži put:
- Otvorite PageSpeed Insights
- Unesite URL vaše početne stranice i pričekajte analizu
- Pogledajte karticu “Field Data” (ako postoji) — to su pravi podaci korisnika
- Identificirajte koja metrika je u “narančastoj” ili “crvenoj” zoni
- Za detaljniju sliku svih URL-ova na vašoj stranici, otvorite Google Search Console → Core Web Vitals izvještaj
Stranica ne mora biti tehnički kompleksna da bi imala dobre rezultate. Čak i jednostavna WordPress ili Astro stranica može imati izvrsne Core Web Vitals ako su slike optimizirane, fontovi pravilno učitani i JavaScript minimiziran. Obrnuto, čak i moderno dizajnirana stranica može imati loše rezultate ako su dodani “teški” dodaci, loše optimizirani slideri ili treće strane skripte koje se učitavaju nekontrolirano.
Ako ste pri provjeri otkrili da vaša stranica pada na nekim od ovih metrika — posebno ako je LCP iznad 3 sekunde na mobitelu ili INP iznad 300 ms — to su signali koji zahtijevaju konkretnu tehničku intervenciju, a ne samo vizualne izmjene. N&S Web Architects redovito provodi tehničke audite za klijente čije stranice zaostaju u pretrazi upravo zbog ovih faktora, i pronalazi rješenja prilagođena konkretnoj tehnologiji na kojoj je stranica izgrađena — bilo da je riječ o WordPressu, Astru ili custom razvoju.
Zaključak
Core Web Vitals u 2026. nisu tehnička suptilnost rezervirana za velike korporativne timove — to su mjerljivi standardi koje Google koristi da razlikuje stranice koje korisnicima pružaju dobro iskustvo od onih koje ne pružaju. LCP mjeri koliko brzo posjetitelj vidi da se stranica učitava, INP mjeri koliko brzo stranica reagira na svaki njegov klik, a CLS mjeri je li stranica vizualno stabilna ili “skače” dok se učitava.
Svaka od tih metrika ima jasne pragove, jasne uzroke pada i jasna rješenja. Polazišna točka je uvijek ista: izmjeriti, identificirati slabost i adresirati je prema prioritetu. U konkurentnim nišama — a turizam i lokalne usluge Dubrovačke regije svakako spadaju u tu kategoriju — prolazak Core Web Vitals provjere može biti razlika između prve i treće stranice Google rezultata.
Preporučeni alati
- PageSpeed Insights — besplatna analiza za jednu stranicu
- Google Search Console — field podaci za cijelu domenu
- web.dev/measure — Lighthouse izvještaj
- WebPageTest — napredno testiranje s video usporedbom
Izvori
- Google Search Central, Core Web Vitals — Understanding LCP, INP and CLS: developers.google.com
- Google Search Console Help, Core Web Vitals report: support.google.com
- corewebvitals.io, What Are the Core Web Vitals? LCP, INP & CLS Explained (2026): corewebvitals.io
- IdeaFueled, Core Web Vitals 2026: Fix Speed or Keep Losing Traffic: ideafueled.com
- Mewa Studio, SEO & Core Web Vitals 2026: Complete Guide LCP, INP, CLS: mewastudio.com
- Digital Applied, Core Web Vitals 2026: INP, LCP & CLS Optimization: digitalapplied.com
- Senorit, Core Web Vitals 2026: INP, LCP, CLS Optimization Guide: senorit.de
- W3Era, Core Web Vitals Guide 2026: LCP, CLS & INP Explained + How to Fix: w3era.com
Podijeli članak:


