Što je LCP (Largest Contentful Paint) i kako ga popraviti

Jedna od najčešćih grešaka na koju nailazim kad preuzmem stranicu na optimizaciju je glavna slika na vrhu koja se učitava lijeno (lazy-load), iako bi se trebala učitavati prva. Posjetitelj zuri u prazan prostor dok preglednik čeka, a upravo to mjeri LCP. Od tri Core Web Vitals metrike LCP (Largest Contentful Paint) mi je gotovo uvijek najtvrđi orah, pogotovo na mobitelu. U ovom tekstu objašnjavam što LCP mjeri, od čega se sastoji i kako smanjiti LCP na WordPress stranicama – na primjerima iz vlastite prakse.

Što je LCP?

LCP mjeri koliko vremena prođe od trenutka kad korisnik zatraži stranicu do trenutka kad se prikaže najveći sadržajni element vidljiv na ekranu bez skrolanja. Taj najveći element obično je velika fotografija na vrhu stranice, naslovni video ili veći blok teksta.

Ideja iza metrike je jednostavna. Kad se prikaže taj najveći element, posjetitelj u pravilu stekne dojam da je stranica učitana, čak i ako se u pozadini još nešto dovršava. Zato Google baš taj trenutak uzima kao mjeru toga koliko brzo stranica „djeluje” učitano.

Pragovi za LCP, koje Google mjeri, izgledaju ovako:

Zašto je LCP toliko često problematičan

Razlog zbog kojeg se LCP teško popravlja je taj što on nije jedna stvar, nego zbroj nekoliko faza. Da bi se najveći element prikazao, mora se dogoditi cijeli niz koraka: server mora isporučiti HTML, preglednik mora otkriti koja je slika glavna, mora je preuzeti i tek je onda prikazati. Ako bilo koji od tih koraka kasni, kasni i cijeli LCP.

Google taj ukupni LCP dijeli na četiri poddijela, i meni je to najkorisniji način razmišljanja jer mi pokaže gdje točno gubim vrijeme:

• Vrijeme do prvog bajta (TTFB) je vrijeme od zahtjeva za stranicom do trenutka kad preglednik primi prvi bajt HTML odgovora od servera.
• Kašnjenje učitavanja resursa je vrijeme između TTFB-a i trenutka kad preglednik uopće počne učitavati glavnu sliku. Ako je LCP element običan tekst, ovaj je dio nula.
• Trajanje učitavanja resursa je vrijeme potrebno da se sama glavna slika preuzme.
• Kašnjenje iscrtavanja je vrijeme od trenutka kad je slika preuzeta do trenutka kad je stvarno prikazana na ekranu.

Kad LCP razložim ovako, odmah vidim na čemu treba raditi. Na primjer, ako je trajanje učitavanja resursa veliko, problem je u prevelikoj slici ili sporom posluživanju. Ako je veliko kašnjenje učitavanja resursa, preglednik prekasno otkriva koju sliku treba, što je čest slučaj kad se slika učitava lijeno (lazy-load) ili je sakrivena iza JavaScripta.

Najčešći uzroci lošeg LCP-a

Lijeno učitavanje glavne slike

Ovo je greška koju viđam stalno. Lazy-load je koristan za slike niže na stranici jer odgađa njihovo učitavanje dok korisnik ne doskrola do njih. Problem nastaje kad se lazy-load primijeni i na glavnu sliku na vrhu stranice. Tada preglednik mora prvo potvrditi da je slika u vidljivom dijelu ekrana prije nego je počne učitavati, što umjetno odgađa LCP. Google je tu izričit: glavnu LCP sliku nikad ne treba učitavati lijeno.

Sličan problem nastaje kad je slika sakrivena iza nestandardnih atributa poput data-src koji zahtijevaju JavaScript da bi se uopće prikazala. Preglednik tada ne može otkriti sliku rano, nego mora čekati izvršavanje skripte.

Render-blocking CSS i JavaScript

Ako preglednik mora prvo preuzeti i obraditi velike CSS ili JavaScript datoteke prije nego što može prikazati sadržaj, to izravno gura LCP prema gore. Kod stranica koje učitavaju desetke CSS datoteka, samo to odgađanje zna iznositi nekoliko sekundi. Tu pomaže ugrađivanje kritičnog CSS-a izravno u stranicu i odgađanje svega što nije nužno za prvi prikaz.

Prevelike slike

Slika koja se poslužuje u rezoluciji od 1280 piksela širine, a prikazuje se na 186 piksela, troši propusnost bez ikakve koristi. Na mobilnim vezama to se izravno osjeti na LCP-u. Rješenje je posluživanje slika u dimenzijama u kojima se stvarno prikazuju, u modernim formatima poput WebP-a ili AVIF-a, uz srcset za različite veličine ekrana.

Spor server (visok TTFB)

Ako server dugo isporučuje HTML, sve ostalo kasni jer se na frontendu ništa ne može dogoditi dok ne stigne prvi bajt odgovora. TTFB je u praksi najteže optimizirati jer ovisi o kvaliteti hostinga i o tome koliko je sama WordPress instalacija opterećena. Dobar hosting, kvalitetna predmemorija i Object Cache poput Redisa tu rade najveću razliku.

Kako smanjiti LCP na WordPress stranicama

Redoslijed kojim pristupam je manje-više uvijek isti, od stvari s najvećim učinkom prema sitnijima:

• Glavnoj slici dodajem fetchpriority="high" i uklanjam loading="lazy". Po zadanim postavkama preglednik slike u vidljivom dijelu ekrana učitava niskim prioritetom i tek ih kasnije, nakon obrade CSS-a, podiže na visoki. Atribut fetchpriority="high" taj korak preskače i govori pregledniku da sliku tretira kao prioritetnu od prvog trenutka.
• Osiguravam da je sliku moguće otkriti u HTML-u, dakle u običnom <img> elementu sa src ili srcset atributom, a ne sakrivena iza JavaScripta. Preglednik tako sliku može pronaći i početi učitavati odmah.
• Smanjujem render-blocking resurse ugrađivanjem kritičnog CSS-a i odgađanjem/uklanjanjem nekorištenog CSS-a i JavaScripta.
• Optimiziram samu sliku, u modernom formatu i u ispravnoj veličini za uređaj.
• Radim na TTFB-u kroz kvalitetnu predmemoriju, Object Cache i dobar hosting.

Korisno je razlikovati dvije tehnike koje se često brkaju. Preload utječe na to kada preglednik otkrije resurs, a fetchpriority na to koji mu prioritet dodjeljuje kad ga je već otkrio. Za glavnu sliku najbolji rezultat daje kombinacija oboje: rano otkrivanje (slika rano u HTML-u ili preko preloada) i visoki prioritet preko fetchpriority="high".

Primjer iz prakse: radnaodjeća.hr

Dobar primjer koliko LCP ovisi o ovim detaljima je web shop radnaodjeća.hr, čiju sam optimizaciju opisao u studiji slučaja.

Nakon tehničke optimizacije, mjerenje u PageSpeed Insightsu na računalu pokazuje LCP od 0,7 sekundi, što je u zoni „dobro”. Na mobitelu je LCP 3,1 sekunde, dakle još uvijek „potrebno poboljšanje”. No, mobilni LCP zahtjevniji je od desktopa, jer mobilni uređaji imaju slabije procesore i sporije veze. Treba imati na umu i da su ovo laboratorijski podaci s jednog mjerenja, a konačnu ocjenu daju terenski podaci stvarnih korisnika kroz idućih mjesec dana.

Zaključak

LCP mjeri koliko brzo se prikaže najveći element na stranici, a cilj je da to bude unutar 2,5 sekunde. Ono što ga čini zahtjevnim je činjenica da je zbroj više faza, od brzine servera do načina na koji se učitava glavna slika. Najveći učinak u praksi daje to da glavnu sliku ne učitavate lijeno, da joj date visoki prioritet i da je poslužujete u razumnoj veličini i formatu.

Ako vaša stranica ima loš LCP, a niste sigurni gdje točno gubi vrijeme, kontaktirajte h1 design i zatražite ponudu za SEO usluge.