Izmerite v produkciji: Core Web Vitals audit za razvijalce in tržnike

Izmerite v produkciji: Core Web Vitals audit za razvijalce in tržnike

Core Web Vitals so tri merljive metrike: LCP, INP in CLS. Cilj na 75. percentilu je LCP pod 2,5 sekunde, INP pod 200 milisekund in CLS pod 0,1. Field podatke dobite iz Chrome User Experience Reporta in Google Search Console, lab diagnostiko pa iz PageSpeed Insights in Lighthouse.

Na kratko:

• Za natančno diagnostiko je ključna analiza field podatkov iz Chrome User Experience Reporta in Search Console, saj odražajo resnično uporabniško izkušnjo.
• Predlagani popravki vključujejo optimizacijo slik, razdelitev JavaScript nalog ter določanje dimenzij elementov, kar neposredno vpliva na izboljšanje LCP, INP in CLS.
• Pri zdravljenju težav je pomembno osredotočiti se na INP, ki je najbolj zahtevna, saj se pokaže šele pri dejanski interakciji uporabnikov.
• S spremljanjem podatkov prek knjižnice web-vitals in segmentacijo po napravi lahko natančno določimo, katere strani zahtevajo najboljšo optimizacijo.
• Celosten pristop, ki vključuje pregled, diagnostiko, ukrep in stalno spremljanje, zagotavlja trajne izboljšave v uporabniški izkušnji in SEO rezultatih.

Kazalo

• Kaj pravzaprav merijo LCP, INP in CLS
• Zakaj so core web vitals pomembne za izkušnjo in SEO
• Kako meriti core web vitals: field ali lab podatki
• Kako odpraviti težave: konkretni popravki za LCP, INP in CLS
• Kako izvesti core web vitals audit v praksi
• Katera orodja uporabiti in kje začeti z merjenjem
• Kako Moxy-web pristopa k izboljšanju core web vitals
• Kaj mislim, da razvijalci največkrat zgrešijo pri core web vitals
• Kako Moxy-web pomaga pri odpravi težav s core web vitals
• Viri
• Pogosta vprašanja

Kaj pravzaprav merijo LCP, INP in CLS

LCP (largest contentful paint) meri, kdaj se največji viden element naloži v vidnem polju. Najpogosteje je to hero slika, video ali blok besedila v naslovu strani. INP (interaction to next paint) je nasledil metriko FID in ne meri le prvega klika, temveč odzivnost skozi celotno sejo obiska. Zajame vsako interakcijo (klik, tap, pritisk tipke) in oceni, koliko časa preteče, preden brskalnik naslednjič nariše zaslon.

CLS (cumulative layout shift) je nekoliko drugačna žival. Izračuna se iz seštevka premikov postavitve znotraj časovnih oken (session windows), pri čemer se vsak premik uteži glede na velikost premaknjenega elementa in razdaljo premika. Tipični krivci za slab CLS:

• slike in oglasi brez določenih dimenzij (width/height ali aspect-ratio),
• pisave po meri, ki se naložijo pozno in premaknejo besedilo (FOIT/FOUT),
• dinamično vstavljena vsebina (bannerji, obvestila o piškotkih) brez rezerviranega prostora.

Razumevanje teh treh mehanik je predpogoj za pravo diagnostiko, ne le za površinsko popravljanje simptomov.

Zakaj so core web vitals pomembne za izkušnjo in SEO

Google Core Web Vitals uporablja kot del ocene page experience pri rangiranju. To ne pomeni, da bo hitra stran samodejno prehitela vsebinsko boljšo konkurenco, saj kakovost vsebine ostaja odločilna. Vendar pri dveh sicer enakovrednih straneh delujejo kot tiebreaker.

Poslovni učinek je še bolj otipljiv na strani uporabniške izkušnje. Počasno nalaganje in nestabilna postavitev lahko pomembno vplivata, ali obiskovalec ostane na strani ali zapre zavihek še preden vidi ponudbo.

Strokovni nasvet: Ne pričakujte takojšnjega odziva v Search Console. Poročilo temelji na 28-dnevnem drsečem oknu CrUX podatkov, zato se izboljšave v field podatkih pokažejo šele po približno mesecu, vidni premiki v iskalnih rezultatih pa se pogosto pojavijo šele čez dva do tri mesece.

Kako meriti core web vitals: field ali lab podatki

Pri odločanju, kateremu orodju zaupati, velja preprosto pravilo prioritete. Field podatki iz Chrome User Experience Reporta in Search Console kažejo, kaj resnični obiskovalci na resničnih napravah dejansko doživljajo, zato so odločilni za SEO presoje. Lab podatki iz PageSpeed Insights, Lighthouse ali Chrome DevTools so simulacija na eni napravi in eni hitrosti povezave, zato so odlični za diagnostiko in testiranje popravkov, a ne odražajo razpršenosti resničnega prometa.

Za lastno spremljanje v produkciji je smiselno namestiti knjižnico web-vitals. Ta v brskalniku obiskovalca zbere vse tri metrike in jih pošlje v analitično orodje ali lastno bazo, kar je osnova za t. i. RUM (real user monitoring):

• namestite knjižnico prek npm ali CDN in poslušajte dogodke onLCP, onINP, onCLS,
• pošiljajte podatke skupaj z informacijo o napravi, povezavi in poti obiskovalca,
• segmentirajte 75. percentil ločeno za mobilne in namizne naprave, saj se rezultati med njima pogosto močno razlikujejo.

Brez te segmentacije lahko dobra povprečna vrednost skriva resno mobilno težavo.

Kako odpraviti težave: konkretni popravki za LCP, INP in CLS

Popravki se razlikujejo glede na metriko, prioriteta pa naj sledi tej logiki:

1. LCP. Preložite ključno sliko ali pisavo z <link rel="preload">, stisnite in pravilno velikostno prilagodite slike (WebP ali AVIF), izločite kritični CSS za nad-pregib vsebino in znižajte TTFB s CDN-jem ali hitrejšim gostovanjem.
2. INP. Razdelite dolga JavaScript opravila na manjše koščke (razbijanje »long tasks«), preložite nekritične skripte z defer ali async in pri intenzivnih izračunih uporabite web workerje, da ne blokirajo glavne niti.
3. CLS. Vedno določite width in height ali aspect-ratio za slike in videoposnetke, rezervirajte prostor za pasice in oglase pred njihovim nalaganjem ter se izogibajte animacijam, ki premikajo elemente znotraj postavitve (namesto top/left uporabite transform).

Nekateri popravki so hitre zmage, denimo dodajanje dimenzij slikam ali preklop na CDN. Druge, predvsem zniževanje INP na kompleksnih straneh s veliko interaktivnosti, pogosto zahtevajo arhitekturne posege, kot je razdelitev velikih JavaScript svežnjev ali prehod na lažje ogrodje. Konkretne primere teh ukrepov najdete tudi v pregledu najpogostejših napak pri razvoju spletnih rešitev.

Strokovni nasvet: INP je za mnoge strani najtrši oreh, saj se pokaže šele pri resnični interakciji uporabnika. Field podatki so zato pri INP praktično nujni za pravo diagnostiko, lab test namreč interakcije simulira zelo omejeno.

Kako izvesti core web vitals audit v praksi

Ponovljiv audit je zaporedje petih korakov: najprej field pregled v Search Console, kjer identificirate URL skupine z oznako Need improvement ali Poor. Nato izberete prioritetne strani po prometu in poslovni vrednosti (denimo strani izdelkov ali pristajalne strani kampanj). Sledi lab analiza v Lighthouse ali PageSpeed Insights za natančno diagnostiko vzroka. Nato implementirate popravke in nazadnje spremljate učinek prek RUM podatkov in ponovnega pregleda CrUX.

Merila za prioriteto naj vključujejo:

• obseg prometa na posamezni URL skupini,
• neposredni vpliv na prihodek ali konverzije,
• delež obiskovalcev, ki jih metrika dejansko prizadene.

Rezultate spremljajte redno, saj se Search Console poročilo posodablja z zamikom in en sam dober lab rezultat ne pomeni, da je težava rešena za vse obiskovalce. Podroben pregled ukrepov za hitrost strani najdete tudi v vodniku o optimizaciji spletne strani.

Katera orodja uporabiti in kje začeti z merjenjem

Vsako orodje ima svojo vlogo. Search Console prikazuje agregirane field podatke po URL skupinah, PageSpeed Insights združi field in lab pogled za posamezno stran, Lighthouse in Chrome DevTools omogočata poglobljeno lab diagnostiko s »waterfall« prikazom nalaganja, WebPageTest pa dodaja testiranje iz več lokacij in naprav. Za lastne field podatke uporabite CrUX API ali knjižnico web-vitals, ki jo vgradite neposredno v kodo strani in podatke pošiljate v svoje analitično orodje.

• Search Console: field podatki, skupine URL-jev, oznake Good/Need improvement/Poor.
• PageSpeed Insights: kombinacija field in lab podatkov za eno stran.
• Lighthouse/DevTools: podroben lab waterfall za diagnostiko posameznega vzroka.
• web-vitals knjižnica: RUM meritve neposredno pri resničnih obiskovalcih.

Kako Moxy-web pristopa k izboljšanju core web vitals

Avtor tega vodnika, Žiga iz ekipe Moxy-web, pri vsakem projektu najprej preveri field podatke, šele nato lab rezultate. Pri prvem pregledu stranka dobi konkreten seznam prioritet, ne splošnega poročila. Poudarek je na ukrepih, ki jih je mogoče izmeriti v naslednjem CrUX ciklu.

Kaj mislim, da razvijalci največkrat zgrešijo pri core web vitals

Največja napaka, ki jo vidim pri delu z ekipami, ni pomanjkanje znanja o metrikah, temveč zanašanje na en sam Lighthouse test kot na dokončno oceno. Lab številka z ene naprave in ene povezave pove le, kako se stran obnese v idealnih pogojih, ne pa kako jo doživlja resnični obiskovalec na starejšem telefonu z počasnim omrežjem.

Druga podcenjena stvar je INP. Veliko ekip še vedno optimizira predvsem LCP, ker je najbolj viden in najlažje razumljiv, INP pa pušča ob strani, dokler jih ne opozori padec v Search Console. To je narobe obrnjena prioriteta, saj je INP pogosto tista metrika, ki najprej pade iz praga na straneh z veliko interaktivnosti, kot so filtri, košarice ali obrazci.

Tretja stvar, ki jo priporočam vsakemu razvijalcu: ne popravljajte na podlagi ugibanja. Namestite web-vitals knjižnico, poglejte, katera stran skupina resnično trpi, in šele nato posežete v kodo. Hitrost brez podatkov je samo občutek, ne strategija.

— Ziga

Kako Moxy-web pomaga pri odpravi težav s core web vitals

Namesto da sami usklajujete field podatke, lab teste in kodne popravke, lahko celoten postopek prepustite ekipi, ki ga izvaja vsak dan. Moxy-web za podjetja izvede pregled trenutnega stanja, pripravi predlog konkretnih popravkov po prioriteti in jih tudi implementira, brez dolgotrajnega usklajevanja med razvijalcem in oglaševalsko agencijo. Postopek je preprost: najprej pregled obstoječe strani, nato predlog z jasnimi koraki, nazadnje implementacija skupaj s gostovanjem in tekočim vzdrževanjem, da se rezultati ne poslabšajo ob naslednji nadgradnji. Za spletne trgovine, ki poleg hitrosti urejajo tudi sprejem plačil, je smiselno pogledati tudi rešitve za POS terminale v povezavi s spletno trgovino. Če želite konkretno oceno stanja svoje strani in predlog ukrepov, si oglejte ponudbo na Moxy-web in zahtevajte pregled še danes.

Viri

• Understanding Core Web Vitals and Google search results
• Core Web Vitals
• Core Web Vitals report - Search Console Help

Pogosta vprašanja

Kaj so core web vitals?

Core Web Vitals so tri Googlove metrike uporabniške izkušnje: LCP za hitrost nalaganja, INP za odzivnost in CLS za vizualno stabilnost strani.

Kaj sta CLS in LCP?

LCP meri, kdaj se največji vidni element na strani naloži, CLS pa meri, koliko se elementi med nalaganjem nepričakovano premaknejo po zaslonu.

Ali so core web vitals še relevantne leta 2026?

Da, Google jih še naprej uporablja kot del ocene page experience, INP pa je od uvedbe postal ena od najtežje dosegljivih metrik na interaktivnih straneh.

Kaj velja za dober rezultat core web vitals?

Dober rezultat na 75. percentilu pomeni LCP pod 2,5 sekunde, INP pod 200 milisekund in CLS pod 0,1, medtem ko so bistveno višje vrednosti po standardih običajno ocenjene kot slabe.

Kako hitro se izboljšave core web vitals pokažejo v field podatkih?

Ker Chrome User Experience Report uporablja 28-dnevno drseče okno, se izboljšave v field podatkih pokažejo šele po približno mesecu, morebitni SEO učinki pa običajno čez dva do tri mesece.

Priporočeno

• Hitrost nalaganja strani: poslovni vodnik za odločevalce
• Zakaj testirati spletne rešitve za uspeh podjetja
• Checklista za izdelavo spletne strani: vodič 2026
• Vloga hitrega nalaganja strani za podjetnike 2026