Što su Core Web Vitals?

Core Web Vitals su skup metrika kojima se pokušava izmjeriti stvarno korisničko iskustvo web stranice.

Umjesto da gledamo samo koliko je vremena potrebno da se stranica tehnički učita, ove metrike pokušavaju odgovoriti na praktičnija pitanja:

• koliko brzo korisnik vidi glavni sadržaj
• koliko brzo web reagira kada nešto klikne
• pomiče li se sadržaj neočekivano tijekom učitavanja

Trenutni Core Web Vitals sastoje se od tri glavne metrike:

• LCP – Largest Contentful Paint
• INP – Interaction to Next Paint
• CLS – Cumulative Layout Shift

Preporučene vrijednosti za dobro korisničko iskustvo trenutno su LCP do 2,5 sekunde, INP do 200 ms i CLS do 0,1. Google ih procjenjuje na 75. percentilu stvarnih posjeta, odvojeno za mobilne i desktop korisnike.

Ali Core Web Vitals nisu samo još tri SEO broja koja treba dovesti u zeleno.

Njihova najveća vrijednost je u tome što mogu otkriti stvarne probleme koje korisnik osjeća tijekom korištenja weba.

Zašto postoje?

Tradicionalne metrike performansi često su bile vrlo tehničke.

Developer je mogao vidjeti da se određeni resurs učitao za određeno vrijeme, ali korisniku to ne mora ništa značiti.

Stranica može tehnički početi učitavanje vrlo brzo, dok korisnik još nekoliko sekundi gleda prazan ekran.

Može izgledati potpuno učitana, ali ne reagirati na klik.

Može prikazati sadržaj, ali se nakon sekunde sve pomakne jer se naknadno učitala slika.

Core Web Vitals pokušavaju te probleme približiti stvarnom iskustvu.

Tri glavne metrike

Pojednostavljeno:

LCP → koliko brzo vidim glavni sadržaj?

INP → koliko brzo web reagira kada nešto napravim?

CLS → ostaje li sadržaj tamo gdje očekujem?

Dobra stranica treba zadovoljiti sva tri područja.

Web koji se brzo pojavi, ali ne reagira na korisnika nije brz.

Web koji reagira odmah, ali mu sadržaj konstantno skače također nema dobro iskustvo.

Što je LCP?

Largest Contentful Paint mjeri vrijeme potrebno da se najveći relevantni element vidljiv u početnom viewportu prikaže korisniku.

To često može biti:

• hero fotografija
• veliki blok teksta
• H1
• velika ilustracija
• video poster

Google trenutno smatra LCP od 2,5 sekunde ili manje dobrim, vrijednosti između 2,5 i 4 sekunde područjem za poboljšanje, a više od 4 sekunde lošim rezultatom.

Primjer LCP-a

Zamislimo naslovnu stranicu.

Na vrhu imamo:

• logo
• navigaciju
• H1
• podnaslov
• veliku hero fotografiju

Ako je fotografija najveći element u viewportu, vrlo je moguće da će upravo ona biti LCP element.

Ako se:

• logo pojavi nakon 0,5 sekundi
• tekst nakon 0,8
• hero fotografija nakon 4,5 sekundi

korisnik će velik dio glavnog sadržaja čekati.

Problem nije što se ništa nije prikazalo.

Problem je što najvažniji dio početnog ekrana dolazi prekasno.

Što usporava LCP?

Česti uzroci su:

• prespora serverska reakcija
• velika hero slika
• kasno otkrivena slika
• render-blocking CSS
• JavaScript
• web fontovi
• vanjski resursi
• nepotrebni redirecti

Zato rješavanje LCP-a nije uvijek samo:

komprimiraj sliku.

Slika može biti potpuno optimizirana, a server svejedno toliko sporo odgovarati da dobar rezultat nije moguć.

Hero slika

Hero fotografije vrlo su čest LCP element.

Ako koristimo fotografiju od nekoliko megabajta, problem je relativno očit.

Ali postoje i manje očiti problemi.

Primjerice, hero slika može biti postavljena kao background unutar CSS-a.

Browser ju tada može otkriti kasnije nego sliku koja je pravilno navedena u HTML-u.

Ili se slika može učitavati s lazy loadingom iako se nalazi odmah na vrhu stranice.

Lazy loading je odličan za sadržaj niže na stranici.

Za glavni LCP element često nije.

Server također utječe

LCP ne počinje tek kada browser dobije HTML.

Ako serveru treba dugo da uopće odgovori, sve ostalo počinje kasnije.

Zato na LCP mogu utjecati:

• hosting
• backend
• baza podataka
• cache
• CDN
• redirecti

Web se ne može učitati prije nego što server počne slati sadržaj.

Optimizacija frontenda zato ne može uvijek riješiti problem sporog backenda.

Što je INP?

Interaction to Next Paint mjeri koliko brzo stranica reagira na korisničke interakcije.

To mogu biti:

• klik na gumb
• otvaranje menija
• odabir taba
• klik na filter
• unos u određene kontrole

INP pokušava procijeniti koliko dugo korisnik čeka da nakon interakcije vidi vizualni odgovor stranice.

Trenutno se INP do 200 ms smatra dobrim, od 200 do 500 ms područjem za poboljšanje, dok je iznad 500 ms loše.

Kako loš INP izgleda?

Korisnik klikne hamburger menu.

Ništa.

Nakon kratkog kašnjenja meni se pojavi.

Ili klikne:

Dodaj u košaricu

i gumb nekoliko trenutaka ne reagira.

Takva kašnjenja možda traju manje od sekunde, ali korisnik ih može vrlo jasno osjetiti.

Ako ne dobije nikakav feedback, možda će ponovno kliknuti.

To može uzrokovati:

• dvostruke akcije
• frustraciju
• osjećaj da web ne radi

JavaScript je čest uzrok

Browser koristi glavni thread za velik broj zadataka.

Ako se na njemu izvršava veliki JavaScript posao, korisnička interakcija može morati čekati.

Primjer:

Korisnik klikne gumb.

Ali browser upravo izvršava veliki JavaScript task.

Klik je registriran, ali rezultat se ne može odmah prikazati.

Korisniku web izgleda spor.

Previše skripti

Na web se vrlo lako dodaju:

• analytics
• chat
• heatmap
• cookie alat
• popup alat
• animacije
• remarketing
• social widget

Svaki alat može dodati JavaScript.

Nijedan pojedinačno možda nije problem.

Ali zajedno mogu značajno povećati količinu posla koju browser mora izvršiti.

Zato svaki third-party servis treba imati jasan razlog postojanja.

INP nije samo učitavanje

Ovo je važna razlika.

LCP je snažno vezan uz početno učitavanje.

INP prati iskustvo interakcije tijekom korištenja stranice.

Web se zato može vrlo brzo pojaviti, a svejedno imati loš INP.

Na prvi pogled djeluje brz.

Kada ga počnete koristiti, djeluje tromo.

Što je CLS?

Cumulative Layout Shift mjeri neočekivano pomicanje sadržaja.

Dobar CLS rezultat je trenutno 0,1 ili manje, od 0,1 do 0,25 treba poboljšanje, a vrijednosti iznad 0,25 smatraju se lošima.

CLS nema jedinicu poput sekundi.

Radi se o rezultatu koji predstavlja veličinu i utjecaj neočekivanih pomicanja elemenata.

Kako CLS izgleda?

Zamislite da čitate članak.

Želite kliknuti:

Pročitaj više

U tom trenutku iznad gumba učita se oglas ili fotografija.

Cijeli sadržaj se pomakne prema dolje.

Umjesto gumba kliknete nešto drugo.

To je izrazito loše korisničko iskustvo.

Najčešći uzroci CLS-a

Probleme često uzrokuju:

• slike bez rezerviranog prostora
• iframeovi
• oglasi
• embedovi
• fontovi
• banneri
• dinamički umetnut sadržaj

Ključna riječ je:

neočekivano.

Ako korisnik klikne accordion i sadržaj se proširi, pomicanje je očekivano.

Ako se sadržaj pomakne sam od sebe dok korisnik čita, to je problem.

Slike bez dimenzija

Jedan od klasičnih uzroka CLS-a je slika za koju browser unaprijed ne zna koliko će prostora trebati.

Prvo prikaže tekst.

Zatim se slika učita.

Browser tek tada napravi prostor.

Sav sadržaj ispod slike se pomakne.

Ako unaprijed rezerviramo odgovarajući prostor, sadržaj ostaje stabilan.

Fontovi

Fontovi također mogu uzrokovati promjene layouta.

Browser prvo može prikazati fallback font.

Nakon toga se učita stvarni font.

Ako fontovi imaju različite dimenzije znakova, tekst može:

• promijeniti širinu
• prijeći u novi red
• povećati visinu elementa

To može pomaknuti okolni sadržaj.

Zato optimizacija fontova nije samo pitanje nekoliko kilobajta.

Može utjecati i na vizualnu stabilnost.

Zašto 75. percentil?

Core Web Vitals se ne procjenjuju prema jednom savršenom testu na developerovom računalu.

Google za procjenu dobrog iskustva koristi 75. percentil stvarnih posjeta.

Pojednostavljeno, cilj je da barem velika većina posjeta bude unutar preporučenog praga, a ne samo najbolji korisnici s najbržim uređajima i vezama.

To je važna ideja.

Web treba dobro raditi za stvarne korisnike, ne samo za developerov MacBook spojen na optiku.

Lab i stvarni korisnici

Kod Core Web Vitals analize važno je razlikovati dvije vrste podataka.

Lab podaci

Web se testira u simuliranim i kontroliranim uvjetima.

Takvi podaci su vrlo korisni za debugging.

Možete ponavljati test i provjeriti je li određena optimizacija nešto poboljšala.

Field podaci

Nastaju iz stvarnog korištenja.

Uključuju korisnike s:

• različitim uređajima
• različitim mrežama
• različitim lokacijama
• različitim ponašanjem

Za stvarno stanje weba field podaci mogu biti posebno vrijedni.

Chrome UX Report

Google za podatke stvarnih Chrome korisnika koristi Chrome User Experience Report, odnosno CrUX.

To su agregirani podaci o stvarnom korisničkom iskustvu za stranice koje imaju dovoljno podataka.

Zbog toga se vaš rezultat iz lokalnog Lighthouse testa može razlikovati od podataka koje vidite u drugim Google alatima.

To nije nužno greška.

Mjeri se drugačiji skup korisnika i uvjeta.

PageSpeed Insights

PageSpeed Insights je jedan od najjednostavnijih načina za početnu analizu.

Može prikazati kombinaciju:

• stvarnih podataka kada su dostupni
• laboratorijskog Lighthouse testa

Tu je važno razumjeti što točno gledate.

Ako je Lighthouse test crven, to ne znači automatski da svi stvarni korisnici imaju isti problem.

Ako su field podaci loši, problem je puno teže ignorirati.

Lighthouse

Lighthouse je odličan alat za tehničko testiranje.

Može pomoći pronaći probleme poput:

• velikih slika
• render-blocking resursa
• nepotrebnog JavaScripta
• problema s cacheom

Ali Lighthouse score nije Core Web Vitals rezultat sam po sebi.

To je dijagnostički alat.

Ne treba graditi cijeli projekt s jedinim ciljem da krug bude zelen i broj pokaže 100.

Search Console

Google Search Console može pomoći pronaći grupe URL-ova s problemima vezanim uz Core Web Vitals.

To je posebno korisno kod većih webova.

Umjesto da ručno provjeravate stotine stranica, možete dobiti signal da određeni tip stranice ima zajednički problem.

Primjer:

sve stranice proizvoda imaju loš LCP.

To odmah sugerira da problem možda nije jedan proizvod, nego sam template proizvoda.

Template je važan

Ako imate 500 blog članaka koji koriste isti template, ne morate nužno optimizirati svaki članak pojedinačno.

Ako problem stvara zajednička komponenta, jedan popravak može poboljšati stotine URL-ova.

Isto vrijedi za:

• proizvode
• kategorije
• usluge
• landing stranice

Zato performanse treba analizirati i kroz strukturu sustava, ne samo pojedinačne URL-ove.

Desktop nije mobile

Core Web Vitals treba promatrati odvojeno za desktop i mobilne korisnike.

Web može biti odličan na desktopu, ali loš na telefonu.

Razlozi mogu biti:

• slabiji uređaji
• sporija mreža
• drugačiji layout
• mobilna navigacija
• dodatni sticky elementi

Zato jedan desktop Lighthouse test nije dovoljan.

Mobile iskustvo treba ozbiljno testirati, što detaljnije objašnjavamo u članku što je mobile-first dizajn.

Core Web Vitals i SEO

Core Web Vitals imaju SEO komponentu, ali treba izbjeći pogrešan zaključak:

Popravit ću Core Web Vitals i automatski doći na prvo mjesto.

To nije način na koji SEO funkcionira.

Stranica i dalje treba imati:

• relevantan sadržaj
• dobru strukturu
• odgovarati namjeri pretraživanja
• interne linkove
• autoritet

Core Web Vitals su dio ukupnog iskustva.

Ne zamjenjuju ostale SEO elemente.

Ne lovite 100

Vrlo česta greška je pokušati dobiti:

100 / 100 / 100 / 100

u Lighthouseu pod svaku cijenu.

Ako je web:

• brz
• stabilan
• responzivan
• funkcionalan
• dobar za stvarne korisnike

razlika između rezultata 96 i 100 vrlo često nije najvažnija poslovna stvar koju možete optimizirati.

Možda je puno vrijednije poboljšati:

• ponudu
• CTA
• formu
• sadržaj
• projekte

Performanse treba staviti u kontekst cijelog weba.

Nemojte ignorirati crveno

S druge strane, ne treba koristiti prethodni argument kao opravdanje za ozbiljno loše rezultate.

Ako:

• LCP traje 7 sekundi
• korisničke interakcije značajno kasne
• sadržaj konstantno skače

problem je stvaran.

Tada nije riječ o lovu na savršenstvo.

Riječ je o osnovnoj kvaliteti weba.

LCP nije samo slika

Ako je LCP loš, prvo treba identificirati stvarni LCP element.

Možda je to hero fotografija.

Ali možda je:

• H1
• banner
• druga slika
• veliki tekstualni blok

Tek nakon toga ima smisla optimizirati.

Nemojte naslijepo smanjivati sve slike jer alat pokazuje loš LCP.

Prvo pronađite uzrok.

INP traži interakciju

Za INP treba analizirati što se događa kada korisnik stvarno koristi stranicu.

Primjerice:

• otvara mobilni menu
• koristi filter
• otvara accordion
• klikne Add to Cart
• mijenja varijaciju proizvoda

Problem se možda neće vidjeti ako samo otvorite stranicu i ništa ne kliknete.

To INP čini posebno važnim kod interaktivnijih webova i trgovina.

CLS traži promatranje

CLS je često relativno lako primijetiti vizualno.

Otvorite web i gledajte:

• pomiče li se naslov
• skače li navigacija
• pomiču li se gumbi
• pojavljuje li se banner naknadno

Ako stranica izgleda kao da se slaže pred očima korisnika, postoji velika šansa da treba analizirati stabilnost layouta.

Web shop je osjetljiv

Kod web trgovine Core Web Vitals mogu biti posebno izazovni.

Product page može imati:

• galeriju
• varijacije
• cijenu
• wishlist
• recenzije
• preporuke
• analytics
• remarketing
• chat

Svaki element dodaje novu kompleksnost.

Posebno treba paziti da glavne akcije poput:

Odaberi veličinu

i

Dodaj u košaricu

ostanu brzo responzivne.

WordPress također može biti brz

Ponekad se Core Web Vitals problemi automatski pripisuju WordPressu.

To je prejednostavno.

WordPress web može imati odlične performanse.

Problemi najčešće nastaju iz kombinacije:

• lošeg hostinga
• velikih slika
• nepotrebnih pluginova
• teških tema
• buildera bez optimizacije
• third-party skripti

Tehnologija postavlja određena ograničenja, ali način implementacije ima ogroman utjecaj.

Custom nije automatski brz

Isto vrijedi u drugom smjeru.

Custom web napravljen u modernom frameworku može imati jako loše rezultate ako šalje ogromne JavaScript bundleove, neopravdano učitava podatke i koristi kompleksne animacije.

Zato smo i kod usporedbe WordPressa i custom weba naglasili da tehnologiju treba birati prema stvarnim zahtjevima projekta.

Što prvo popravljati?

Ako web ima problema sa sve tri metrike, ne treba paničariti.

Prvo treba pronaći uzroke s najvećim utjecajem.

Primjer:

Loš LCP

Provjerite:

• server response
• LCP element
• hero sliku
• prioritizaciju resursa
• render-blocking sadržaj

Loš INP

Provjerite:

• velike JavaScript taskove
• third-party skripte
• event handlere
• količinu posla nakon klika

Loš CLS

Provjerite:

• dimenzije slika
• fontove
• oglase
• bannere
• kasno umetanje elemenata

Optimizacija tada postaje strukturiran proces.

Testirajte nakon promjene

Nakon optimizacije treba ponovno testirati.

Ako smo:

• smanjili hero sliku
• promijenili način učitavanja fonta
• uklonili skriptu

treba provjeriti:

1. jesmo li poboljšali metriku
2. jesmo li nešto drugo pokvarili

Performanse nisu izolirane od funkcionalnosti.

Testirajte ključne stranice

Nemojte provjeravati samo naslovnu.

Za poslovni web testirajte barem:

• naslovnu
• glavnu uslugu
• kontakt
• nekoliko blog članaka

Za webshop:

• naslovnu
• kategoriju
• proizvod
• košaricu
• checkout

Svaki template može imati drugačiji problem.

Performanse od početka

Core Web Vitals je puno lakše držati pod kontrolom ako se o performansama razmišlja tijekom razvoja.

To znači da prije dodavanja elementa možemo pitati:

• treba li nam
• koliko je težak
• kada se mora učitati
• postoji li jednostavnija opcija

Puno je teže završiti cijeli web i tek pred objavu zaključiti da treba ukloniti polovicu skripti.

Zato su performanse dio dobrog procesa izrade web stranice.

Stvarni cilj

Core Web Vitals nisu cilj sami po sebi.

Cilj je web na kojem korisnik:

• brzo vidi sadržaj
• bez čekanja koristi elemente
• ne gubi mjesto zbog pomicanja layouta

Ako uz to dobijemo dobre metrike, sustav radi kako treba.

Zato Core Web Vitals treba koristiti kao dijagnostički okvir za poboljšanje korisničkog iskustva.

Ne kao igru skupljanja zelenih brojeva.

Ako želite krenuti od šire slike, pročitajte kako brzina weba utječe na korisnike i SEO.

Ako planirate novi web, pogledajte naše pakete i cijene izrade web stranica.