Web razvoj
Web performance bez magije: LCP/INP/CLS, slike, fontovi i real-user monitoring (RUM)

Web performanse se često tretiraju kao misterija: instaliraš caching, stisneš slike i nadaš se da će skor skočiti. U realnim projektima to obično ne radi, jer performanse nisu jedno dugme. One su skup trade-off-ova koje možeš da meriš, optimizuješ i validiraš.
U 2025. najkorisniji pristup je jednostavan: optimizuj ono što korisnici stvarno doživljavaju, a ne ono što jedan lab test prikazuje. To znači da razumeš Core Web Vitals (LCP, INP, CLS), da rešavaš realne uzroke (slike, fontovi, JavaScript, third-party skripte) i da koristiš Real-User Monitoring (RUM) kako bi dokazao da su promene donele rezultat.
Ovaj vodič je praktičan playbook: šta meriti, koje optimizacije najčešće donose pomak i kako da pokažeš jasan pre/posle napredak bez nagađanja.
Tri metrike koje najviše znače: LCP, INP, CLS
Core Web Vitals nisu teorija. One predstavljaju tri konkretne korisničke žalbe: „stranica se sporo učitava“, „sajt je trom kada kliknem“, i „stranica skače dok se učitava“.
- LCP (Largest Contentful Paint): koliko brzo se vidi glavni sadržaj
- INP (Interaction to Next Paint): koliko je sajt responzivan posle interakcije
- CLS (Cumulative Layout Shift): koliko je layout stabilan tokom učitavanja
Poboljšanje ovih metrika retko je „dodaj još“. Uglavnom je „skloni usko grlo“: render-blocking resurse, prevelike fajlove i nepotreban JavaScript koji se izvršava u pogrešnom trenutku.
Tabela: šta je „dobro“ i šta najčešće kvari rezultat
| Metrika | Cilj (dobar UX) | Najčešći uzroci | Šta najčešće rešava |
|---|---|---|---|
| LCP | Brz prikaz glavnog sadržaja | Spor server/TTFB, teška hero slika, render-blocking CSS/JS, kasno učitani fontovi | CDN/cache, optimizacija hero slike, critical CSS, defer nebitnog JS-a, preload ključnih resursa |
| INP | Brza reakcija na klik/unos | Dugi JS taskovi, teška hidracija, spori handleri, previše third-party skripti | Smanji JS, code-split, manje klijentskog posla, optimizuj handlere, odloži third-party |
| CLS | Bez skakanja layout-a | Slike bez dimenzija, kasni fontovi, ubacivanje banera/ads, dinamičke komponente guraju sadržaj | Rezerviši prostor, width/height, stabilni placeholderi, font-display strategija |
Korak 1: meri ispravno (Lab vs Real Users)
Najčešća greška je jurnjava za jednim lab skorom i ignorisanje realnih sesija. Koristi oba—ali razumi razliku.
- Lab podaci (Lighthouse / sintetički testovi): odlični za debug i ponovljive poređenja
- Field podaci (realni korisnici): jedini izvor istine za produkciju
Cilj nije „100 poena“. Cilj je merljivo bolje iskustvo: brži sadržaj, fluidnija interakcija i stabilan layout na različitim uređajima i mrežama.
Korak 2: napravi baseline koji možeš da braniš
Pre optimizacije definiši baseline. U suprotnom ne možeš da dokažeš da je nešto stvarno bolje.
- Izaberi 5–10 ključnih stranica (home, kategorija/listing, proizvod/usluga, checkout/lead forma, blog)
- Segmentiraj po uređaju (mobile vs desktop) i mreži ako možeš
- Prati LCP, INP, CLS + pomoćne metrike (TTFB, FCP, veličina resursa)
- Zapiši period i uzorak za ‘pre’ snapshot
Od tog trenutka performanse postaju proces: promeni jednu stvar, izmeri, zadrži ono što radi.
LCP: sredi hero, sredi server, ukloni render blocking
LCP često zavisi od jednog elementa: hero slika, banner, glavna produkt slika ili veliki heading blok. Kreni od toga—jer mala promena na LCP elementu može da donese veliki skok.
1) Olakšaj LCP element (najčešće sliku)
Ako je LCP slika, tretiraj je kao kritičnu komponentu. Mora biti tačno dimenzionisana, kompresovana i brzo dostavljena.
- Koristi moderne formate (WebP/AVIF) sa fallback-om gde treba
- Koristi responsive slike (srcset/sizes) da mobile ne vuče desktop fajl
- Izbegni ogromne hero slike koje vizuelno ne donose razliku, a teške su 5–10x
- Preload za hero sliku ako je uvek iznad fold-a
- Ne lazy-loaduj LCP sliku (lazy-load ide za below-the-fold)
2) Smanji TTFB i ubrzaj isporuku
Ako je server spor, sve je sporo. TTFB se najčešće popravlja „dosadnim“ ali efikasnim koracima:
- Full-page caching gde ima smisla (posebno javne stranice)
- CDN za statiku i edge caching kada je opravdano
- Optimizacija DB upita i manje backend posla po request-u
- Cache za API pozive i skupe kalkulacije
- Kompresija (Brotli/Gzip) i HTTP/2 ili HTTP/3 gde je dostupno
3) Ukloni render-blocking CSS i JS
Najveći neprijatelj je često ‘savršen’ CSS bundle i ‘za svaki slučaj’ JavaScript koji se učitava svuda.
- Inline minimalni critical CSS za above-the-fold
- Defer za nebitan JS (analytics, chat widget, A/B skripte) dok stranica ne postane upotrebljiva
- Split bundle po ruti/stranici da korisnik ne plaća kod koji mu ne treba
- Smanji unused CSS i framework overhead gde može
INP: učini da sajt bude brz posle učitavanja
Sajt može brzo da se učita, a da i dalje deluje sporo ako klikovi, unos, filteri ili meniji ‘seku’. INP to meri. Najčešći INP problem je JavaScript.
1) Ubij long taskove
Long task blokira main thread. Kad je main thread zauzet, sajt ne može da odgovori korisniku.
- Smanji teške klijentske kalkulacije (sortiranje velikih lista, parsiranje)
- Prebaci skupe operacije na server gde može
- Koristi web workere za CPU-heavy stvari ako moraju u browseru
- Razbij posao u manje delove (ne radi sve u jednom event-u)
2) Pažljivo sa hidracijom i klijent-heavy renderovanjem
Moderni framework-i su moćni, ali lako pošalju previše JavaScripta u browser. Ako je INP loš, proveri da li je stranica previše ‘hydrated’ ili se prečesto re-renderuje.
- Preferiraj server render za content-heavy stranice gde je moguće
- Interaktivne ‘islands’ neka budu manje i ciljane
- Izbegni teške UI biblioteke na stranicama koje uglavnom prikazuju sadržaj
- Smanji re-render: stabilizuj state/props i ograniči listenere
3) Odloži third-party skripte dok ne ‘zasluže’ mesto
Third-party skripte često ubijaju INP. Svaka dodaje CPU, mrežu i ponekad layout rad.
- Analytics učitaj posle consent-a ili posle prve interakcije
- Chat widget odloži dok korisnik ne scrolluje ili ne klikne ‘Help’
- Ukloni duple tagove i neiskorišćene pixel-e
- Redovno audituj tag manager, posebno posle kampanja
CLS: zaustavi ‘skakanje’ stranice
CLS je najčešće problem implementacije i dizajna, ne servera. Dešava se kada browser složi layout, a onda se nešto učita i pogura sadržaj.
1) Rezerviši prostor za slike i komponente
Ako browser ne zna koliko prostora element zauzima, ne može da spreči shift.
- Postavi width/height (ili aspect-ratio) za slike i video
- Koristi stabilne skeleton placeholder-e za dinamičke komponente
- Rezerviši prostor za cookie banner, promo bar i notice
- Ne ubacuj novi sadržaj iznad već vidljivog sadržaja
2) Fontovi: izbegni nevidljiv tekst i reflow
Fontovi jesu brending, ali često kvare performanse i stabilnost layout-a ako se pogrešno učitavaju.
- Koristi font-display: swap (ili sličnu strategiju) da tekst ne bude ‘invisible’
- Preload primarnih font fajlova iznad fold-a
- Subset fontova (samo potrebni karakteri i weight-ovi)
- Smanji broj font family-ja i weight-ova na prvom view-u
RUM: dokaži napredak na realnim korisnicima
Real-User Monitoring (RUM) skuplja performanse iz pravih sesija u produkciji. To je jedini pouzdan odgovor na pitanje: „Da li smo stvarno ubrzali sajt?“
- Prati Core Web Vitals po stranici i tipu uređaja
- Segmentiraj po regionu/državi i tipu mreže ako imaš podatke
- Prati percentile (p75 je čest standard), ne samo prosek
- Poveži performanse sa KPI-jevima (konverzija, bounce, lead forma)
RUM menja razgovor sa mišljenja na dokaze. Umesto ‘deluje brže’, pokažeš da je p75 LCP bolji, INP manji i CLS stabilniji na hiljadama sesija.
Pre/posle: kako da pokažeš rezultat
Da bi dokazao napredak, ne menjaj sve odjednom. Koristi kontrolisan pristup.
- Izaberi jedan cilj (npr. LCP na mobile product stranicama)
- Implementiraj 1–2 promene (npr. optimizacija hero slike + preload)
- Uporedi definisan ‘pre’ period sa ‘posle’ periodom uz iste segmente
- Proveri sporedne efekte (SEO, vizuelni kvalitet, tracking)
Dobar performance report nije screenshot skora. To je tabela ili graf koji pokazuje real-user napredak po tipu stranice i uređaju, sa jasnim datumima i uzorkom.
Brza checklista: najveći ROI popravke
- Optimizuj i preloaduj LCP element (često najveći dobitak)
- Smanji TTFB kroz cache/CDN i backend optimizacije
- Splituj JS bundle i deferuj nebitne skripte
- Rezerviši prostor da ubiješ CLS (slike, baneri, komponente)
- Olakšaj fontove (subset, preload, manje weight-ova)
- Uvedi RUM da stalno meriš i validiraš poboljšanja
Zaključak: performanse su proces koji se meri
Web performanse bez magije znače jedno: dokaz. Meri realne korisnike, popravi najveća uska grla prvo i dokaži napredak pre/posle poređenjem.
Kada LCP, INP i CLS tretiraš kao inženjerske metrike—uz strategiju za slike, fontove i RUM—prestaješ da pogađaš i počinješ da isporučuješ brže i stabilnije iskustvo.

