Core Web Vitals 2026: kaj Google dejansko meri

Core Web Vitals so trije podatki, ki jih Google zbira pri resničnih obiskovalcih vaše strani — ne v laboratoriju, ampak na njihovih telefonih in povezavah. Prav zato se rezultat iz orodij za testiranje pogosto razlikuje od tistega, kar vidite v Search Console.

Tu je, kaj vsak od treh pomeni, kaj ga najpogosteje pokvari in po kakšnem vrstnem redu se jih splača popravljati.

LCP: kako hitro se pokaže glavna stvar

LCP meri, kdaj se prikaže največji element v vidnem delu strani — običajno slika v glavi strani ali velik naslov. Meja za dobro oceno je 2,5 sekunde.

Skoraj vedno je krivec slika. Prevelika po dimenzijah, v starem formatu, brez določene velikosti ali naložena šele takrat, ko se je že vse ostalo naložilo. Popravki po vrsti učinka: zmanjšajte sliko na velikost, v kateri je dejansko prikazana, shranite jo v WebP ali AVIF, glavni sliki dodajte fetchpriority="high" in ji nikoli ne dajte loading="lazy".

Drugi pogost vzrok je strežnik, ki predolgo razmišlja, preden odgovori. Če prvi bajt pride po več kot pol sekunde, slike ne bodo rešile ničesar — problem je nižje, pri gostovanju ali pri vtičnikih, ki gradijo stran ob vsakem obisku.

INP: kako hitro se stran odzove na dotik

INP je zamenjal starejši FID in meri, koliko časa mine od klika do vidnega odziva. Meja je 200 milisekund.

Vzrok je praktično vedno JavaScript. Vsak vtičnik, vsaka sledilna skripta in vsak vgrajeni pripomoček dodajo delo, ki ga mora brskalnik opraviti, preden se sploh odzove na dotik. Na WordPress strani z dvajsetimi vtičniki INP pade sam od sebe, brez da bi kdo karkoli naredil narobe.

Kaj pomaga: odstranite vtičnike, ki jih ne uporabljate, skripte, ki niso nujne za prvi prikaz, naložite z defer, vgrajene zemljevide in videe pa naložite šele ob kliku.

CLS: koliko vsebina poskakuje

CLS meri premikanje vsebine med nalaganjem — tisto, ko hočete klikniti povezavo, pa se pod prstom premakne in zadenete oglas. Meja je 0,1.

Trije običajni krivci: slike brez navedene širine in višine, pisave brez rezervne nastavitve (besedilo se prerazporedi, ko se naloži prava pisava) in pasice za piškotke ali oglase, ki se vrinejo nad vsebino.

Vse troje se popravi hitro. Slikam dodajte width in height, pisavam font-display: swap z rezervno pisavo podobne širine, pasice pa naj bodo v plasti nad vsebino, ne v toku strani.

Po kakšnem vrstnem redu popravljati

Najprej LCP. Pri večini strani je tam največ pridobljenega za najmanj dela, ker gre za slike in gostovanje.

Nato CLS. Popravki so majhni in učinek je takojšen.

Na koncu INP. Ta zahteva največ dela, ker pomeni odstranjevanje ali odlaganje kode, in pogosto odpre vprašanje, ali stran sploh potrebuje toliko vtičnikov.

Kje preverjate rezultat

V Google Search Console, v poročilu Core Web Vitals. Pomembno: podatki so 28-dnevno drseče povprečje resničnih obiskovalcev. Popravek, ki ste ga naredili danes, se v poročilu pokaže šele čez nekaj tednov, polni učinek pa po 28 dneh.

Zato ne popravljajte enega elementa in čakajte. Popravite ves seznam naenkrat in nato merite.

PageSpeed Insights vam med tem pokaže laboratorijsko meritev, ki je uporabna za odkrivanje vzrokov, ni pa tisto, kar Google uporablja za oceno. Ne zamenjujte ju.

Kaj to pomeni za uvrstitev

Core Web Vitals so eden od signalov, ne odločilni. Dobra vsebina s slabimi meritvami bo še vedno pred slabo vsebino z odličnimi. Pri dveh primerljivih straneh pa zmaga hitrejša — in to je položaj, v katerem je večina malih podjetij v Sloveniji.

Drugi, manj omenjeni učinek je neposreden: počasna stran izgubi del obiskovalcev, preden se sploh naloži. Ta izguba se zgodi ne glede na to, kje ste uvrščeni.

Če hočete vedeti, kje vaša stran stoji in kaj je na njej vredno popraviti najprej, to pogledamo v sklopu SEO optimizacije. Povejte, katero stran naj pogledamo.

Viri

Ti je članek koristil? Dodaj GudWeb med priljubljene vire na Googlu