Core Web Vitals metrike i brzina stranice (page speed)

Core Web Vitals metrike - šta su?

Core Web Vitals se često spominju kada govorimo o performansama sajta. Google želi svojim korisnicima da pruži najbolje moguće korisničko iskustvo (UX – user experience) kako bi zadržao dominaciju među pretraživačima. Zato na razne načine pokušava da navede vlasnike i kreatore web stranica da u svakom segmentu zadovolje posetioce. U tom smislu, Google pozitivno ocenjuje bezbednosni protokol (HTTPS), dobru prilagođenost stranice mobilnim uređajima (mobile-friendly), odsustvo malware-a, stabilnost elemenata na stranici (odsustvo pop-up prozora).

Takođe je dobar pokazatelj korisničkog iskustva posećenost stranice i stopa konverzije (conversion rate). Međutim, postoje određene metrike koje nam mogu ukazati na nivo zadovoljstva korisnika. Vođeni tim metrikama možemo izvršiti poboljšanja u datim segmentima. Zbog svog značaja za korisničko iskustvo nazivaju se Core Web Vitals i njihove vrednosti utiču na rangiranje web stranice.

Core Web Vitals metrike - zašto su bitne za Google?

Core Web Vitals metrike se mogu brojčano izraziti nakon određenih računanja. Znamo da su bitne za korisničko iskustvo, ali pitanje je da li su one bitne za Google i iz nekih drugih razloga. Naime, ako Google botovi troše više bandwith-a (propusni opseg) zbog, na primer, sporog učitavanja velikih slika, potrošiće se i više resursa, više novca. Zato, u težnji da smanji svoje troškove, Google nameće određena pravila u vezi optimizacije. Drugim rečima, Google želi da postigne najmanju moguću cenu crawlering-a, odnosno obilaska botova.

U Core Web Vitals-e se ubraja više činilaca, ali se izdvajaju 3 najznačajnija:

Largest Contentful Paint (LCP)
First Input Delay (FID)
Cumulative Layout Shift (CLS)

Core Web Vitals metrike - istraživanja

Postoje istraživanja u kojima su vršena terstiranja i uglavnom se došlo do zaključka da PageSpeed, na koji značajno imaju uticaj navedeni činioci, značajno povećava stopu konverzije. Prema tim istraživanjima, 1 sekund bržeg učitavanja stranice povećava stopu konverzije za 1%, što u nekim slučajevima doprinosi značajnom povećanju profita.

Core Web Vitals:
Largest Contentful Paint (LCP)

LCP je vremenski interval od momenta kada posetilac klikne na link do momenta kada se vidi najveći element na ekranu. Najbitniji je najveći element koji posetilac vidi u Above the Fold, odnosno na ekranu odmah nakon otvaranja.

U vezi sa ovim bitno je razumeti tzv. rendering path (put rendanja ili prikazivanja, uobličavanja).

Na slici vidimo dva primera. Jedan je optimizovani (progresivni) rendering koji se smatra dobrim. Elementi se prikazuju postepeno i ostaju na istom mestu, odnosno, ne pomeraju se.

Kako poboljšati LCP

Najbolje bi bilo ako bi se svaka stranica sajta učitavala za manje od 2 sekunde. Ovaj rezultat je često teško postići na velikim sajtovima, na stranicama sa mnogo slika i raznih funkcionalnosti. U cilju smanjenja LCP-a mogu se ukloniti veliki elementi, minimizirati CSS, podesiti tzv. lazy loading (da se slike otvaraju tek nakon skrolovanja). Takođe se mogu ukloniti sve nepotrebne tzv. third-party skripte. Ovde važnu ulogu ima i keširanje.

Renderovanje bi trebalo definisati tako da se prvo prikaze LCP (najveći element), a potom da se ostali elementi prikazuju postepeno i da se ne pomeraju.

U slučaju da imamo dinamičke stranice (recimo sa filterima i sl.), one se ne keširaju jer postoji veliki broj varijanti filtera. Međutim, ako imamo neku statičnu stranicu, na primer, neki članak, možemo obaviti keširanje, tj. omogućiti da se stranica učitava iz keša pretraživača. Ako radimo sa WordPress sajtom, imamo na raspolaganju plugin-e koji nam olakšavaju keširanje na nivou čitavog sajta. Ipak, moramo voditi računa da, ukoliko imamo dinamički sadržaj i uključili smo keširanje, ta stranica se neće ponovo generisati sve dok ponovo ne obrišemo keš.

Kako snimamo stranicu za proveru Core Web Vitals-a?

Otvorimo određenu stranicu, desni klik na miša i kliknemo Inspect. Uključimo prikaz za mobilne uređaje. Potom u gornjem levom uglu kliknemo na crni krug za snimanje i osvežimo stranicu. Čim se stranica osveži, zaustavimo snimanje na stop.

Možemo pročitati šta se desilo u nekoliko sekundi snimanja. Dobićemo podatke kao u WebPageTest alatu testu, ali preciznije jer oni predstavljaju realno korisničko iskustvo. Još bi bilo bolje te podatke pogledati u incognito prozoru

Klikom na LCP, u donjem prozoru možemo tačno videti i o kom je elementu reč.

Na osnovu dobijenih podataka možemo iznaći načine kako popraviti LCP metriku. Na primer, ako je LCP velika slika, moguće je smanjiti je, pa da tekst ispod bude LCP i sl.

Core Web Vitals:
First Input Delay (FID)

FID je vremenski interval za koji stranica odreaguje na neku akciju koju posetilac pokrene. Ako posetilac klikne na dugme, to je vreme za koje će se desiti aktivnost predviđena tim dugmetom. Jasno je da korisnici neće biti zadovoljni ako kliknu na dugme za unos mail-a, a onda čekaju neko vreme da im se pojavi polje za unos.

Ovaj faktor je posebno bitan ako se radi o stranicama koje imaju određene obrasce za popunjavanje, registraciju i slično. Za povećanje brzine reagovanja stranice možemo koristiti keš memoriju pretraživača, ukloniti nepotrebne skripte treće strane i minimizirati JavaScript kod.

Najčešće je odgovoran JavaScript kod, ali i CSS

Naime, za većinu reakcija na sajtu u velikom broju slučajeva zadužen je JavaScript kod. Ako se JavaScript-u pošalje neki zahtev, zaustavlja se učitavanje bilo čega drugog. Zato se skripte treće strane, kao što su Mouse Overflow ili Hotjar (programi koji prate ponašanje korisnika na stranici) stavljaju na kraju koda. Robot učitava stranicu odozgo na dole, pa ako mu odmah na vrhu dođe Hotjar i čeka par sekundi da se učita, FID i LCP će se značajno pogoršati. Iako su elementi poput menija vidljivi, klik na njega neće funkcionisati sve do se ne obradi prethodni zahtev. Drugim rečima, dolazi do blokada main tread-a.

Moramo voditi računa da se CSS učitava preko fajlova, nikako ne koristiti inline CSS, a takođe JavaScript uvek postavljati na kraj koda.

Učitavanje JavaScript-a koje smo objasnili je sinhrono, odnosno prema određenom vremenskom sledu. Postoji redosled učitavanja i sledeći element čeka dok se prethodni ne učita. Sinhrono učitavanje je po default-u. Sa druge strane, postoji i asinhrono učitavanje. Uz dodatak oznake async ili defer dobijamo situaciju da se ne čeka učitavanje JavaScript-a, već da se ostali elementi neometano renderuju.

Sinhrono i asinhrono učitavanje JavaScript-a

Zašto se uvek ne bi stavljale oznake async ili defer?

Neki framework-ovi, kao što je jQuery (JavaScript framework) ne radi adekvatno sa async ili defer. Zato je bitno promragerima objasniti da se zbog raznih načina praćenja (tracking kodova) ili nekih drugih izmena vezanih za JavaScript pogoršava FID. Sve u svemu, najčešći razlog lošeg FID-a je upravo JavaScript, što možemo proveriti u WebPageTest alatu.

FID je metrika koja se određuje na osnovu stvarnih poseta, a ne pomoću botova.

Core Web Vitals:
Cumulative Layout Shift (CLS)

CLS je faktor koji se odnosi na stabilnost web stranice. Poželjno je da se prilikom učitavanja elementi ne pomeraju, već da se učitavaju na poziciji na kojoj će se finalno nalaziti. Ako se iz nekog razloga pomeranje ipak dešava, rezultat CLS metrike neće biti dobar.

Ako dolazi do pomeranja sadržaja prilikom učitavanja, lako se može desiti da korisnik klikne na nešto na šta uopšte inicijalno nije želeo, što umnogome pogoršava korisničko iskustvo.

Kako merimo CLS ako ne postoje jedinice u kojima se izražava?

Kao što vidimo iz gore date slike, ovaj interval ne merimo u sekundama ili nekim drugim jedinicama. Kako ćemo onda doći do ovih vrednosti i kontrolisati ih ako ne znamo u kojim jedinicama se izražavaju? Kako bi izračunao CLS, pretraživač posmatra veličinu ekrana i pomeranje nestabilnih elemenata u njemu između dve renderovana okvira. Formula izgleda ovako:

layout shift score = impact fraction * distance fraction

Impact fraction je čitava površina ekrana koju zauzima element, sve sa pomeranjem. Na donjoj slici sa zvaničnog Google-vog sajta, to je površina oivičena isprekidanom crvenom linijom. Element zauzima pola ekrana (50% ili 0,5), ali se vrši pomeranje još za 25%. To znači da impact fraction iznosi 75%.

Drugi činilac u gore navedenoj formuli je distance fraction. To je najveće rastojanje za koje se bilo koji nestabilan element pomerio u okviru ekrana (bilo horizontalno ili vertikalno) podeljeno sa najvećom dimenzijom prikaza ekrana (to je obično visina). U slučaju na sliči on iznosi 0,25. Prema tome, u ovom će slučaju CLS iznositi:

0,75 * 0,25 = 0,1875

Zašto su bitne dimenzije slika?

Da bi CLS iznosio nula, elementi se ne smeju pomerati tokom učitavanja. U cilju postizanja te vrednosti moramo obratiti pažnju na dimenzije slika. Obavezno moramo uneti širinu i visinu slike u kod. U suprotnom, slike prave problem.

Jedan od noviteta u HTML5 je to da je uveden tzv. srcset parameter u okviru koga možemo zadati rezolucije slike za različite širine ekrana.

Na slici je zadato sledeće: za 320 širinu ekrana učitava se dati fajl, za 1.5x veću širinu se učitava sledeći, a za 2x veću treći fajl. Za svaku veličinu rezolucije imamo fajl tačne veličine koja je potrebna. A pre svega, u CSS je navedena prvobitna veličina slike:

Takođe, postoji i element <picture> koji nam omogućava rešavanje problema sa promenom veličine slika u zavisnosti od veličine ekrana:

Cilj je da se slika učita na istom mestu na kome će biti, a ne da se menja veličina iste u toku prikazivanja (rendering-a).

Dosta više na ovu temu možete se informisati na Mozilla zvaničnoj stranici o responzivnosti slika. U smislu programiranja vezanog za ovu vrstu problema, na stranici Critical CSS možemo generisati određene kodove. To je posao za programere.

Takođe bi eventualnim reklamama trebalo odrediti tačno mesto gde će se nalaziti na stranici.

Core Web Vitals:
Time To First Byte (TTFB)

Da ne zaboravimo i bitnu staru metriku, a koja predstavlja vremenski interval od slanja zahteva za nekim resursom pa do početka pružanja odgovora na taj zahtev.

Na stranici Mozilla-e možemo pronaći definiciju dostupnu u okviru odgovarajućeg API-ja (spoljna funkcija koja se koristi za određene zadatke):

const ttfb = time.responseStart – time.navigationStart

TTFB je vremenski interval između početka navigacije do prvog bajta podatka u odgovoru.

Na slici vidimo da je ovaj interval zbir raznih međufaza. Najbolje bi bilo da je ovaj vremenski interval manji od 0,8 sekundi, a sve u cilju najboljeg korisničkog iskustva. Svaka od gore predstavljenih strelica predstavlja merne tačke.

Kako popraviti TTFB?

Na prva četiri odeljka (do TCP) ne možemo uticati jer oni zavise od hostinga. Na ostale možemo uticati. Kako popraviti TTFB? Za razliku od FCP koji čini vidljiv element, TTFB može činiti pojava elementa koji zapravo ne vidimo. Zato bismo mogli, kada uđemo u source kod, pronaći favicon (ikonica koja se vidi u tabu, a ne na stranici). Potom odgovarajuće linije koda prebacimo u deo odmah ispod <head> elementa. Kada korisnik klikne enter, server završi sve što je do njega i vrati mu ikonicu koja je jako mala. Tada dobijemo tačan TTFT. Na ovaj način saznamo da li je za nepovoljan TTFB, ukoliko ga imamo, odgovoran server ili mi sami.

Za razliku od FID-a koji se može meriti samo kroz pretraživač, TTFB možemo meriti na svom serveru.

PageSpeed Insights – indikator Core Web Vitals metrika

LCP I CLS možemo izmeriti pomoću Google-ovog alata PageSpeed Insights tako što unosimo URL:

Ipak, ovako dobijene vrednosti nam predstavljaju više indikatore u kom smeru da optimizujemo sajt, nego tačne vrednosti.

Takođe možemo zapaziti da nam nije navedena vrednost FID-a jer bot na ovaj način ne može da ga izračuna.

Kako PageSpeed izračunava brzinu i koliki je udeo svakog od ovih činilaca možemo videti preko Lighthouse Scoring Calculator-a:

SERP Speed – kolika je brzina naše stranice?

Postoji alat koji se naziva SERP Speed i koji nam omogućava da saznamo brzinu naše stranice (page speed), ali i prosečnu brzinu stranica konkurencije koja se dobija na osnovu izabrane ključne reči:

Ova su nam poređenja bitna jer je važno kako se kotiramo u našoj niši. Na primer, nikada stranica sa mnogo slika u vidu nekog porfolija fotografa ne može biti brža od nekog informativnog članka koji se sastoji samo od teksta.

Dalje se u okviru ovog alata možemo informisati koji su to top 10 konkurenti i koliki su njihovi rezultati. Tako ćemo stvoriti sliku kako se kotira naša stranica. Ipak, ukoliko neki drugi konkurenti, koji su na nekim daljim pozicijama, imaju bolje rezultate, može se desiti da preskoče neke koji su na prvoj stranici Google-a. Google će im potencijalno pružiti šansu da proveri kako će proći i da li imaju potencijal da tu i ostanu.

U svakom slučaju, trebalo bi da se izborimo za najbolji rezultat i da ne dozvolimo da nas konkurencija u tome preskoči. Na raspolaganju su nam i drugi alati za proveru ovih faktora, kao što je Sistrix. Ipak, najrelevantniji alat koji imamo na raspolaganju je Google Search Console.

Semrush - Core Web Vitals metrike

Total Blocking Time (TBT)

Na Semrush-u možemo takođe odraditi Core Web Vitals izveštaj unutar Site Audit sekcije. Ovaj alat ne daje FID vrednost jer je nije u mogućnosti na ispravan način prikazati. Međutim, daje novu vrednost, a to je TBT (Total Blocking Time). Ova metrika nam govori koliko dugo je stranica blokirana u smislu sprečavanja posetioca da obavi neku interakciju. Ova metrika zapravo predstavlja zamenu za First Input Delay (FID). Main thread se smatra blokiranim svaki put kada se izvršava DUG ZADATAK, odnosno koji traje preko 50 milisekundi. Pretraživač mora čekati da se zadatak završi da bi mogao odgovoriti. Ukupan TBT stranice je zbir TBT-ova svakog dugog zadatka koji nastane između FCP i TTI (Time to Interactive – vreme moguće intereakcije).

Na slici imamo 3 zadatka od preko 50ms, odnosno duga zadatka: