Core Web Vitals su tri mjerene koje Google koristi kao SEO signal od 2021. Mijenjale su se. Originalna trojka bila je LCP, FID i CLS. U ožujku 2024. Google je FID zamijenio s INP — i to je donijelo prilično velike promjene u tome što se mjeri i kako optimizirati. U 2026. INP je sazreo, mobile-first indexing je default, i pravila igre su ponovno bistre. Ovaj vodič pokriva što se sve promijenilo i konkretno što treba mjeriti i popravljati.
Što su Core Web Vitals — kratki podsjetnik
Google ih definira kao tri ključne metrike user experience-a koje utječu na ranking. Mjeri se iz pravih korisničkih sesija (preko Chrome User Experience Report — CrUX), ne samo iz lab testova.
- LCP — Largest Contentful Paint. Koliko traje da se prikaže najveći vidljivi element (slika, video, blok teksta) iznad fold-a
- INP — Interaction to Next Paint. Koliko od korisnikove interakcije (klik, tap, tipkanje) do vidljivog odgovora stranice
- CLS — Cumulative Layout Shift. Koliko se elementi pomiču dok se učitava (annoying jumps)
Pragovi za "dobro" u 2026:
- LCP < 2.5 sekunde
- INP < 200 milisekundi
- CLS < 0.1
Što je novo u 2026
INP zamijenio FID
FID (First Input Delay) mjerio je samo PRVU interakciju s stranicom. INP mjeri SVE interakcije — i koristi 98. percentil najgorih. To je puno strože.
Praktične posljedice: stranice s teškim JavaScriptom koje su prošle FID test sad padaju na INP-u. Posebno SPA-ovi (Vue, React) gdje navigacija pokreće veliku količinu renderiranja.
Field data ima veći utjecaj
Google više cijeni field data (pravi korisnici) nego lab testove (PageSpeed Insights u laboratorijskim uvjetima). Ako tvoji lab testovi pokazuju 95/100, ali field data pokazuje LCP 4.5s — ranking pati.
Sub-resource optimizacije
Lighthouse 12 dodao je nove provjere za HTTP/3, early hints (103 Early Hints), fetchpriority attribute i speculation rules za prefetch. Sve su to alati za izvlačenje zadnjih 200-300ms iz LCP-a.
Kako mjeriti — alati po prioritetu
1. Google Search Console — Core Web Vitals report
Pravi korisnici, pravi telefoni. Pokazuje koje URL-ove imaju problema, agregirano po LCP/INP/CLS. Ovo je istina — sve ostalo je samo simulacija.
2. PageSpeed Insights
Kombinira CrUX field data (ako URL ima dovoljno prometa) + Lighthouse lab test. Korisno za inicijalni diagnose i konkretne preporuke.
3. Chrome DevTools — Performance panel
Za duboko kopanje. Snimanje sesije, traženje long tasks, INP issue, render blocking. Hard core ali nezamjenjiv.
4. WebPageTest
Test iz različitih lokacija, mreža, uređaja. Najbolji waterfall view svih requestova.
5. Web Vitals JavaScript library
web-vitals.js ti omogućuje da pratiš Core Web Vitals u svom analytics setupu (GA4, Matomo, Plausible). Real user monitoring (RUM) na razini koju treba.
Optimizacija LCP — najčešći problemi
1. Hero slika nije optimizirana
U 80% slučajeva LCP je hero image iznad fold-a. Tri stvari:
- WebP/AVIF format umjesto JPEG-a
- Pravilna veličina (ne 4K slika servirana na 1200px viewportu)
- fetchpriority="high" atribut na
<img>tag — kaže browseru da prioritetno učita
2. Render-blocking resursi
Vanjski CSS i sinkroni JS u <head> blokiraju rendering. Critical CSS inline + ostalo async. LiteSpeed Cache i WP Rocket to rade automatski.
3. Web fontovi
FOIT (Flash Of Invisible Text) — tekst se ne prikazuje dok se font ne učita. font-display: swap u @font-face ili Tailwind config rješava.
4. Spori server / TTFB
Ako server treba 1.5s da pošalje prvi byte, LCP ne može biti pod 2.5s ma što napravio. Page caching (LiteSpeed Cache za WP, Yii cache za Craft, Laravel route cache) je obavezan.
Optimizacija INP — gdje boli
1. Long JavaScript tasks
Glavni krivac INP problema. Klik triggera 800ms blokirajućeg JavaScript-a, korisnik čeka, INP penalizira.
Rješenja:
- Code splitting — manji bundle, lazy load po potrebi
- Web Workers za teške kalkulacije izvan main thread-a
- requestIdleCallback za nesutilne posloove
- scheduler.postTask (novo u modernim browserima) — kontrolirano "prepuštanje" main thread-u
2. Third-party skripte
Google Tag Manager, Facebook Pixel, hotjar, intercom widget — svaki dodaje 100-500ms blokirajućeg JS-a. Async ili defer na svim, učitavaj kasnije ako moguće, koristi Google Tag Manager server-side gdje god ide.
3. Heavy event handleri
Scroll, resize, click handleri koji rade kompleksne kalkulacije. Debounce i throttle, prebaci u Workers ako je moguće.
4. Plugin bloat (WordPress / WooCommerce)
WP Rocket i sl. mogu "defer" stari jQuery kod, ali pravo rješenje je plugin audit i izbacivanje onih koji loadaju težak JS u pozadini.
Optimizacija CLS — najjednostavnije
CLS je najlakši za riješiti. Pravila:
- Sve slike imaju width i height atribute (ili aspect-ratio u CSS-u)
- Embed videa imaju aspect-ratio container
- Web fontovi koriste font-display: optional ili swap s metric overridesima
- Nemoj umetati banner iznad sadržaja nakon učitavanja (cookie banner, GDPR consent — pojavi se prije, ne nakon)
- Dynamic content rezerviraj prostor (skeleton loader, placeholder)
Workflow za optimizaciju
- Provjeri Search Console — koji URL-ovi imaju problema
- PageSpeed Insights na top 3 problematične URL-a — dobi konkretne preporuke
- Identifikuj koja metrika (LCP/INP/CLS) je najveći problem
- Apliciraj jednu promjenu, deploy, čekaj 28 dana (CrUX prozor)
- Provjeri ponovno Search Console — je li metric prešla u green
Brzina nije sprint nego maraton. Realno ti treba 2-3 mjeseca da iteriraš kroz sve probleme i vidiš stable rezultat u rankingu.
Što hosting može (i ne može) napraviti
Što hosting RJEŠAVA:
- TTFB (preko izolacije, NVMe storage, LiteSpeed)
- Page caching out-of-the-box
- HTTP/2 i HTTP/3 podršku
- Brotli compression
- OPcache za PHP
- Auto-SSL koji ne usporava
Što hosting NE RJEŠAVA:
- Tvoju temu koja loada 47 plugins JS-a
- Tvoju 8 MB hero sliku
- Tvoje third-party tracking widgete
- Tvoj kod koji ima O(n²) loop u every click handleru
Hosting ti može dati 200-400ms manje TTFB-a. Ostalo je tvoj posao (ili tvog developera).
FAQ
Pada li mi ranking ako sam u 'needs improvement' zoni?
Ne odmah. Google koristi Core Web Vitals kao tiebreaker — ako si u 'poor' zoni, gubiš ranking u kompetitivnim queryjima. 'Needs improvement' nije panika, ali daj prioritet.
Treba li mi 100/100 PageSpeed score?
Ne. Cilj je u 'good' zoni za sve tri metrike. PageSpeed score iznad 90 je dovoljan, 100 nije realno za većinu WordPress sajtova.
Mobile ili desktop — koji je važniji?
Mobile. Google koristi mobile-first indexing po default-u. Mobile CWV su tvoj prioritet.
Što s SPA-ovima (Vue, React, Astro)?
INP je posebno težak za njih. SSR (server-side rendering) ili SSG (static site generation) je obično jedini način da prodju INP test. Pure SPA s client-side rendering pati.
Što ako koristim Cloudflare?
Cloudflare ne pomaže direktno CWV-u (osim ako ne koristiš njihov image optimization i Argo Smart Routing). Ali ne škodi, posebno za međunarodnu publiku.
Što WMD nudi za performance
- LiteSpeed Web Server s ugrađenim cache-om i ESI fragments
- NVMe SSD storage
- CloudLinux LVE izolacija — tvoj TTFB ne ovisi o drugima
- PHP 8.3 s OPcache uvijek uključen
- HTTP/2 + HTTP/3 podrška
- Brotli kompresija
- Auto-SSL bez performance hit-a
Za ozbiljniji performance audit — javi nam se. Pogledamo specifičan problem na tvom sajtu i kažemo iskreno što hosting može popraviti, a što treba developer da pipne kod.
Zaključak
Core Web Vitals u 2026 nisu novost — ali INP je promijenio igru. Plus mobile-first indexing znači da je mobile brzina prioritet jedan.
Pristup: mjeri prvo, popravi po prioritetu (LCP → INP → CLS), iteriraj svaki mjesec. Brzina je SEO faktor koji se isplaćuje godinama — vrijedi mu posvetiti vrijeme.
Pratit ćemo kako Google evoluira CWV (planiraju INP refinement i možda novu metriku za responsiveness u 2026/2027). Najnovije updateove uvijek publiciramo u našim vijestima.
