Core Web Vitals objašnjeni: LCP, INP i CLS jednostavnim jezikom

Core Web Vitals nisu test osobnosti za vašu web-stranicu

Core Web Vitals često se tretiraju kao tajanstvena bodovna kartica. Stranica dobije crveni broj, netko objavi snimku zaslona u Slacku, a tim se počne prepirati o JavaScript frameworkima.

To nije osobito korisno.

Bolji način razmišljanja o Core Web Vitals jednostavniji je: to su tri mjerenja koja pokazuju djeluje li stranica upotrebljivo stvarnoj osobi na stvarnom uređaju. Ne obuhvaćaju svaki aspekt performansi, pristupačnosti ili kvalitete. Ali hvataju tri česta izvora frustracije:

• Glavnom sadržaju treba predugo da se pojavi.
• Stranica sporo reagira kada korisnik pokuša nešto učiniti.
• Raspored se pomiče dok korisnik čita ili dodiruje elemente.

To su tri Core Web Vitals metrike: LCP, INP i CLS.

Google ih koristi kao dio svojih signala iskustva na stranici, ali SEO kut nije najbolji razlog za brigu. Bolji je razlog to što spore, nestabilne i neodzivne stranice troše vrijeme korisnika. Također se obično lošije konvertiraju, stvaraju više problema za podršku i loše stare.

Tri metrike u jednoj rečenici

Prije detalja, evo verzije jednostavnim jezikom:

• LCP, ili Largest Contentful Paint, mjeri koliko je vremena potrebno da se učita glavni vidljivi sadržaj.
• INP, ili Interaction to Next Paint, mjeri koliko brzo stranica odgovara na korisničke interakcije tijekom posjeta.
• CLS, ili Cumulative Layout Shift, mjeri koliko se stranica neočekivano pomiče.

Uobičajeni pragovi su:

| Metrika | Dobro | Potrebno poboljšanje | Loše | |---|---:|---:|---:| | LCP | 2,5 s ili brže | 2,5 s–4,0 s | Iznad 4,0 s | | INP | 200 ms ili brže | 200 ms–500 ms | Iznad 500 ms | | CLS | 0,1 ili niže | 0,1–0,25 | Iznad 0,25 |

Ti se brojevi obično procjenjuju na 75. percentilu stvarnih korisničkih posjeta. To je važno. Ne pokušavate postići jedno savršeno laboratorijsko mjerenje. Pokušavate učiniti iskustvo dobrim za većinu korisnika, uključujući ljude na sporijim telefonima i neurednijim mrežama.

Ako gledate automatizirano izvješće i niste sigurni odakle krenuti, korisno je odvojiti dijagnozu od panike. Imamo zaseban vodič o tome kako čitati Lighthouse izvješće bez panike, koji detaljnije pokriva taj tijek rada.

LCP: kada stranica djeluje učitano?

Largest Contentful Paint mjeri vrijeme iscrtavanja najvećeg vidljivog sadržajnog elementa u viewportu. U praksi je to često:

• hero slika,
• veliki naslov,
• istaknuta slika članka,
• slika proizvoda,
• veliki blok teksta.

LCP ne pita kada su se završili učitavati svaka skripta, tracking pixel i slika ispod prijeloma stranice. Pita: kada je postala vidljiva glavna stvar zbog koje je korisnik došao?

Zbog toga je LCP ljudskija metrika od staromodnog “vremena učitavanja stranice”. Stranica se tehnički može završiti učitavati kasno, ali i dalje djelovati brzo ako se glavni sadržaj pojavi brzo. Vrijedi i obrnuto: stranica može aktivirati load event dok je hero područje još prazno, zamućeno ili blokirano kašnjenjem renderiranja.

Česti uzroci lošeg LCP-a

Većina problema s lošim LCP-om dolazi iz nekoliko predvidljivih mjesta:

1. Spor odgovor poslužitelja

Ako HTML dokument stigne kasno, sve ostalo počinje kasno.

1. CSS ili JavaScript koji blokiraju renderiranje

Preglednik ima sadržaj, ali ga još ne može iscrtati.

1. Neoptimizirane hero slike

Najveći element je prevelik, u pogrešnom formatu, nema prioritet ili se greškom lijeno učitava.

1. Web fontovi koji odgađaju renderiranje teksta

Veliki naslov može biti LCP element, a učitavanje fonta može ga odgoditi ili vizualno promijeniti.

1. Kašnjenja renderiranja na klijentskoj strani

Ako stranici treba velik JavaScript bundle prije nego što može prikazati smislen sadržaj, LCP pati.

Kako poboljšati LCP

Počnite od stvarnog LCP elementa. Nemojte optimizirati nasumične resurse dok ne znate što preglednik mjeri.

Praktična rješenja uključuju:

• Poslužujte HTML brzo: koristite predmemoriju gdje je prikladno, smanjite rad backenda, izbjegavajte spora preusmjeravanja.
• Optimizirajte LCP sliku: koristite prave dimenzije, kompresiju i format.
• Nemojte lijeno učitavati hero sliku iznad prijeloma stranice.
• Pažljivo koristite fetchpriority="high" za glavnu sliku kada je ona doista prioritet.
• Ugradite kritični CSS inline samo kada to smisleno smanjuje kašnjenje renderiranja.
• Smanjite JavaScript potreban prije prvog smislenog renderiranja.
• Koristite font-display: swap ili neku drugu promišljenu strategiju fontova.

Slike i fontovi česti su krivci. Kod slika kompromis nije samo “mala datoteka je dobra”. Važni su odabir formata, trud oko kodiranja i podrška preglednika, zato održavamo praktično stablo odluke za kada AVIF pobjeđuje WebP, a kada ne. Za stranice s mnogo teksta, web fontovi su i dalje jedan od najlakših dobitaka u performansama, jer mnoge stranice isporučuju više datoteka fontova nego što ih koriste.

INP: odgovara li stranica na dodir?

Interaction to Next Paint mjeri odzivnost. Preciznije, promatra kašnjenje između korisničke interakcije i sljedećeg vizualnog ažuriranja nakon što je preglednik obradio tu interakciju.

Interakcije uključuju stvari poput:

• klika na gumb,
• dodira izbornika,
• odabira potvrdnog okvira,
• tipkanja u polje obrasca,
• otvaranja akordeona.

INP je 2024. zamijenio First Input Delay kao Core Web Vital. To je bila dobra promjena. First Input Delay gledao je samo prvu interakciju. INP je širi: razmatra interakcije tijekom cijelog posjeta stranici i prijavljuje interakciju s velikom latencijom kao ocjenu odzivnosti stranice.

Jednostavnim jezikom: INP hvata stranice koje izgledaju učitano, ali djeluju zaglavljeno.

Vjerojatno ste koristili takvu stranicu. Izgleda spremno. Dodirnete izbornik. Pola sekunde se ništa ne događa. Dodirnete ponovno. Zatim se dvije stvari dogode odjednom. To je INP problem.

Česti uzroci lošeg INP-a

INP je obično problem glavne niti. Preglednik želi odgovoriti, ali JavaScript, rad renderiranja ili izračun rasporeda stoji na putu.

Tipični uzroci uključuju:

• velike JavaScript bundleove,
• skupe event handlere,
• hydration rad u aplikacijama koje se renderiraju na klijentu,
• skripte trećih strana koje se natječu za glavnu nit,
• dugotrajne zadatke nakon učitavanja stranice,
• složena DOM ažuriranja pokrenuta malim interakcijama,
• layout thrashing, pri čemu kod opetovano čita i piše vrijednosti rasporeda.

Marketinške oznake, analitika, chat widgeti i banneri za privolu mogu pridonijeti. To ne znači “uklonite sve”. Znači da svaka skripta na stranici ima cijenu, a latencija interakcije mjesto je na kojem ta cijena često postaje vidljiva.

Kako poboljšati INP

Poboljšanje INP-a manje je pitanje jednog čarobnog atributa, a više smanjenja natjecanja za glavnu nit.

Korisni pristupi uključuju:

• Razbijte duge JavaScript zadatke na manje dijelove.
• Odgodite nebitan rad dok stranica ne postane upotrebljiva.
• Uklonite neiskorišteni JavaScript umjesto da ga samo minificirate.
• Držite event handlere malima i predvidljivima.
• Izbjegavajte ponovno renderiranje velikih dijelova sučelja zbog sitnih promjena stanja.
• Koristite CSS za jednostavna vizualna stanja gdje je moguće.
• Revidirajte skripte trećih strana i učitavajte ih samo tamo gdje su potrebne.

Pogledajte i dizajn interakcija. Gumb koji daje trenutačnu vizualnu povratnu informaciju može djelovati odzivnije, čak i ako naknadni rad traje dulje. To nije zamjena za performanse, ali jest dio dobrog inženjeringa sučelja. Naš kontrolni popis za pristupačne web gumbe preklapa se s tim: jasna stanja, ispravna semantika i predvidljivo ponašanje pomažu i korisnicima i preglednicima.

CLS: ostaje li stranica tamo gdje je korisnik očekuje?

Cumulative Layout Shift mjeri neočekivano pomicanje vidljivih elemenata. Ako korisnik počne čitati odlomak, a oglas, slika ili banner učitaju se iznad njega i pogurnu tekst prema dolje, to pridonosi CLS-u.

CLS se ne mjeri u sekundama. To je rezultat temeljen na tome koliko se sadržaj pomaknuo i koliko daleko se pomaknuo. Niže je bolje.

Ključna riječ je neočekivano. Promjene rasporeda uzrokovane korisničkom radnjom obično se ne računaju na isti način. Ako netko dodirne “prikaži više” i sadržaj se proširi, to je očekivano. Ako se newsletter banner pojavi na vrhu nakon tri sekunde i pogurne sve prema dolje, to nije.

Česti uzroci lošeg CLS-a

CLS neuspjesi često su prizemni:

• slike bez atributa width i height,
• oglasi ili embeds bez rezerviranog prostora,
• cookie banneri umetnuti iznad sadržaja,
• web fontovi koji se zamjenjuju fontovima s drukčijim metrikama,
• kasno učitane promotivne trake,
• dinamički umetnut sadržaj blizu vrha stranice.

Rješenje je obično rezervirati prostor prije nego što sadržaj stigne. Preglednik bi trebao znati oblik stranice što je ranije moguće.

Kako poboljšati CLS

Počnite od vidljivih pomaka. Pogledajte snimku ili upotrijebite alate preglednika kako biste prepoznali koji se elementi pomiču.

Zatim primijenite dosadna rješenja:

• Dodajte izričite atribute width i height slikama.
• Koristite CSS aspect-ratio za responzivne medijske spremnike.
• Rezervirajte fiksni ili minimalni prostor za oglase, embeds i iframes.
• Izbjegavajte umetanje bannera iznad postojećeg sadržaja nakon učitavanja.
• Odaberite fallback fontove s metrikama sličnima završnom fontu.
• Izbjegavajte animacije koje mijenjaju svojstva rasporeda poput top, left, width ili height; radije koristite transforms.

CLS je jedna od rijetkih metrika performansi kod koje disciplina pobjeđuje domišljatost. Ako stranica ima stabilne okvire, obično postiže dobar rezultat.

Terenski i laboratorijski podaci korisni su, ali odgovaraju na različita pitanja

Čest izvor zabune jest to što različiti alati prikazuju različite brojeve. To je normalno.

Terenski podaci dolaze od stvarnih korisnika. Odražavaju stvarne uređaje, mreže, lokacije i uvjete preglednika. Googleovo Chrome User Experience Report primjer je terenskih podataka.

Laboratorijski podaci dolaze iz kontroliranog testnog okruženja. Lighthouse je poznat primjer. Ponovljiv je i koristan za otklanjanje pogrešaka, ali nije isto što i proživljeno iskustvo vaših korisnika.

Koristite terenske podatke da odlučite imaju li korisnici stvaran problem. Koristite laboratorijske podatke da reproducirate i otklonite taj problem.

Također zapamtite da se Core Web Vitals obično procjenjuju po URL-u ili skupini URL-ova, a ne kao jedno apstraktno svojstvo vašeg brenda. Vaša početna stranica, članak na blogu, stranica s cijenama i checkout mogu imati vrlo različita uska grla.

Razuman redoslijed rada

Ako su sve tri metrike loše, napast je početi posvuda. Oduprite se tome.

Praktičan redoslijed je:

1. Prvo popravite očite CLS probleme

Nedostajuće dimenzije slika i nestabilni banneri često su brzi dobici.

1. Poboljšajte LCP za važne predloške

Usredotočite se na stranice koje su važne: stranice proizvoda, odredišne stranice, članke, tokove registracije.

1. Istražite INP kroz stvarne interakcije

Kliknite ono što korisnici zaista klikaju. Izbornici, filtri, obrasci i checkout kontrole često otkriju više od početnog traga učitavanja.

1. Revidirajte skripte trećih strana

Zadržite one koje opravdavaju svoju cijenu. Uklonite ili odgodite one koje je ne opravdavaju.

1. Postavite budžet performansi

Bez budžeta poboljšanja performansi propadaju. Nove skripte, slike i dizajnerske komponente tiho će poništiti rad.

Važna poanta: nemojte optimizirati za značku. Optimizirajte za korisničko putovanje. Marginalno poboljšanje rezultata na stranici s malo prometa može biti manje važno od malo nesavršene, ali mnogo brže checkout interakcije.

<!-- tool-cta:start -->

💡 Isprobajte ovo: Budući da je LCP obično problem sa slikom, smanjite svoj hero element pomoću Image Compressor kao prvi, jednostavan dobitak.

<!-- tool-cta:end -->

Što vam Core Web Vitals ne govore

Core Web Vitals korisni su, ali nepotpuni.

Ne govore vam je li vaš sadržaj dobar. Ne govore vam ima li vaša navigacija smisla. Ne jamče pristupačnost. Ne mjere privatnost, sigurnost, povjerenje, čitljivost ni odgovara li stranica na korisnikovo pitanje.

Također ne zamjenjuju prosudbu. Stranica može proći Core Web Vitals i i dalje biti neugodna. Složena aplikacija može promašiti prag, a ipak biti odgovorno projektirana za svoja ograničenja.

Tretirajte LCP, INP i CLS kao detektore dima. Kada se oglase, istražite. Kada šute, nastavite održavati zgradu.