Core Web Vitals zvuče kao inženjerski ispit, pun kratica koje nitko izvan tima za performanse ne koristi u svakodnevnom govoru. Za vlasnika poslovanja, ipak, izravno se mapiraju na osjećaje koje posjetitelj već ima na vašoj stranici: stranica se predugo pojavljivala, dodiri su bili tromi i nereagirajući, ili se layout pomaknuo baš kad su htjeli nešto dodirnuti. Tri metrike, tri osjećaja - kad ih tako vidite, odlučivanje što popraviti prestaje izgledati tehnički.
Sporo, tromo, skakavo: tri metrike jednostavnim rječnikom
- LCP (Largest Contentful Paint) - sporo: koliko treba da se glavni sadržaj, obično hero slika ili naslov, stvarno pojavi na zaslonu.
- INP (Interaction to Next Paint) - tromo: koliko stranici treba da vidljivo reagira nakon što netko dodirne, klikne ili upiše nešto.
- CLS (Cumulative Layout Shift) - skakavo: koliko se sadržaj pomiče dok se stranica još učitava, što uzrokuje slučajne klikove na krivu stvar.
Googlove granice za „dobro“ su otprilike ispod 2,5 sekunde za LCP, ispod 200 milisekundi za INP i ispod 0,1 za CLS - no točni brojevi manje su bitni od smjera: jeste li udobno ispod granice, točno na rubu ili jasno padate na većini posjeta.
Zašto je Googleu bitan osjećaj, ne samo sirovo vrijeme učitavanja
Stranica se tehnički može brzo učitati, a ipak djelovati sporo, jer je vidljivom sadržaju trebalo vremena za render ili se sučelje smrznulo tijekom važnog dodira. Core Web Vitals izgrađeni su da mjere iskustvo stvarnog posjetitelja, ne samo vrijeme odgovora poslužitelja ili štopericu na cijelo učitavanje stranice. Zato utječu i na to kako Google procjenjuje iskustvo stranice uz tradicionalnije signale rangiranja - tehnički brz poslužitelj iza trzavog frontenda i dalje loše prolazi.
Lab podaci naspram field podataka: zamka zelenog desktop testa
Lab test - jedno pokretanje PageSpeed Insightsa ili Lighthousea na brzoj vezi - pokazuje kako stranica radi u idealnim, kontroliranim uvjetima. Field podaci dolaze od stvarnih posjetitelja na stvarnim uređajima i stvarnim mrežama, agregirani u Chromeu tijekom zadnjih 28 dana. Sasvim je moguće vidjeti zelene rezultate u lab testu na uredskom Wi-Fi-ju dok field podaci pokazuju da se većina mobilnih posjetitelja muči, jer se srednji Android telefon na nestabilnoj 4G vezi ponaša posve drugačije od mirnog desktop preglednika. Tretirajte lab podatke kao dijagnostički alat, a field podatke kao stvarnu presudu.
Kako provjeriti svoje stvarne brojke
PageSpeed Insights (pagespeed.web.dev) pokazuje i lab i field podatke za bilo koji javni URL, plus popis prilika prema prioritetu specifičan za tu stranicu. Izvještaj Core Web Vitals u Search Consoleu grupira URL-ove diljem cijele stranice po statusu - Dobro, Treba poboljšati ili Loše - što je korisnije od provjere stranica jednu po jednu, jer otkriva obrasce poput „svaka stranica proizvoda dijeli isti spori predložak“.
Jedan detalj vrijedan spomena: Googleova presuda na temelju field podataka temelji se na 75. percentilu posjeta, ne na prosjeku. To znači da stranica prolazi samo ako tri od četiri stvarna posjeta zadovoljavaju granicu - šačica brzih posjeta na dobrom Wi-Fi-ju ne može sakriti obrazac sporih iskustava na mobilnim mrežama, što je upravo poanta mjerenja na ovaj način.
Što popraviti prvo, metrika po metrika
- Za spor LCP: komprimirajte i pravilno dimenzionirajte hero slike, preloadajte glavnu sliku ili font i izbjegavajte skripte koje blokiraju render iznad prve linije preloma.
- Za tromi INP: smanjite ili odgodite skripte trećih strana (chat widgeti, teška analitika, oglasni tagovi) koje blokiraju glavnu nit dok netko komunicira sa stranicom.
- Za skakavi CLS: postavite izričitu širinu i visinu na slike i ugradnje te rezervirajte prostor za oglase ili dinamički učitani sadržaj prije nego stigne.
Stvaran primjer: brz poslužitelj, stranica koja se čini sporom
Landing stranica hostana na solidnoj infrastrukturi vraća početni HTML za manje od 200 milisekundi - samo po metrikama poslužitelja izgleda brzo. No stranica prije pojave hero slike učita šest skripti trećih strana: chat widget, dva analitička taga, font s vanjskog CDN-a i ugrađeni video player koji ne rezervira prostor dok se ne učita. Field podaci pokazuju LCP preko četiri sekunde i CLS znatno iznad 0,1, uglavnom na mobitelu. Ništa od toga nije krivnja poslužitelja - riječ je o nakupljenoj težini frontenda koju brz backend ne može nadoknaditi.
Popravak u ovom slučaju nije bio nadogradnja poslužitelja ni prepisivanje frameworka. Bilo je to uklanjanje jednog suvišnog analitičkog taga, odgađanje chat widgeta dok se stranica prvi put ne renderira, self-hosting fonta umjesto povlačenja s vanjskog CDN-a i rezerviranje fiksne visine za video player prije nego se učita. LCP je pao ispod dvije sekunde, a CLS blizu nule unutar jednog deploya - dokaz da su najveće pobjede u performansama najčešće oduzimanje, ne nova infrastruktura.
Kratak popis za prolazak kroz njega
- Provjerite izvještaj Core Web Vitals u Search Consoleu za stranice označene Loše ili Treba poboljšati i krenite od onih s najviše prometa.
- Komprimirajte i pravilno dimenzionirajte slike te posvuda postavite width/height atribute.
- Auditirajte skripte trećih strana i uklonite ili odgodite sve što nije nužno u prvih nekoliko sekundi.
- Rezervirajte prostor u layoutu za oglase, ugradnje i web fontove kako biste spriječili kasna pomicanja.
- Ponovno testirajte na srednjem Android telefonu na stvarnoj mobilnoj vezi prije nego proglasite pobjedu.
U Killer Clicku performanse sjede uz dizajn i SEO od početka projekta, ne kao naknadno čišćenje na kraju - jer lijepa stranica koja se čini sporom ili skakavom i dalje gubi klik koji ste platili, bio taj klik iz organske pretrage ili plaćene kampanje.