Optimizacija brzine sajta 2026: PageSpeed i Core Web Vitals

Optimizacija brzine sajta nije trka za zelenim brojem 100 u PageSpeed Insights-u. Cilj nije da alat bude zadovoljan — cilj je da stvarni korisnik brzo dobije sadržaj, može odmah da reaguje na interfejs i da se stranica ne pomera dok pokušava da klikne.

Spor web sajt može da izgubi korisnika pre nego što on uopšte vidi ponudu.

Ali postoji i druga krajnost.

Možete ukloniti gotovo svaki JavaScript, animaciju, font, tracking i funkcionalnost i dobiti odličan laboratorijski rezultat — dok istovremeno pravite lošiji proizvod.

Zato ozbiljna optimizacija performansi nije pitanje:

„Kako da dobijemo 100/100?“

Već:

„Šta tačno usporava iskustvo stvarnog korisnika, šta od toga možemo bezbedno da popravimo i kakav poslovni efekat očekujemo?“

Ako planirate novi sajt ili ozbiljan redizajn, performanse je mnogo lakše ugraditi u arhitekturu od prvog dana. Pogledajte naše usluge web dizajna i razvoja.

Primarne fraze

optimizacija brzine sajta · ubrzanje sajta · brzina sajta · PageSpeed optimizacija · Core Web Vitals · optimizacija performansi sajta

Uvod: brzina sajta nije jedan broj

Kada neko kaže:

„Sajt mi je spor.“

to može značiti potpuno različite probleme.

Možda se:

• server dugo ne javlja;
• glavna hero slika učitava predugo;
• sadržaj pojavljuje brzo, ali dugmad ne reaguju;
• stranica pomera dok se učitavaju fontovi i oglasi;
• mobilni uređaj guši zbog previše JavaScript-a;
• third-party skripta blokira glavni thread;
• checkout radi sporo iako homepage ima odličan skor.

Zato ne postoji jedna „brzina sajta“.

Postoji skup različitih problema koje treba meriti odvojeno.

1. Šta znači optimizacija brzine sajta?

Optimizacija brzine sajta je proces smanjivanja vremena i resursa potrebnih da korisnik:

• dobije prvi koristan sadržaj;
• vidi glavni sadržaj stranice;
• može da reaguje na interfejs;
• koristi stranicu bez neočekivanog pomeranja elemenata.

To zahteva rad na više slojeva:

• hostingu i serveru;
• cache-u;
• CDN-u;
• HTML-u;
• CSS-u;
• JavaScript-u;
• slikama;
• fontovima;
• third-party servisima;
• CMS-u;
• bazi podataka;
• frontend arhitekturi.

Zbog toga „instaliraj jedan speed plugin“ nije univerzalno rešenje.

2. Šta su Core Web Vitals?

Google trenutno koristi tri Core Web Vitals metrike koje predstavljaju tri različita dela korisničkog iskustva:

• LCP — Largest Contentful Paint: koliko brzo korisnik dobija glavni vidljivi sadržaj;
• INP — Interaction to Next Paint: koliko brzo stranica odgovara kada korisnik nešto uradi;
• CLS — Cumulative Layout Shift: koliko je stranica vizuelno stabilna.

Google trenutno kao „good“ pragove preporučuje:

• LCP ≤ 2,5 sekunde;
• INP ≤ 200 ms;
• CLS ≤ 0,1.

Ove metrike treba posmatrati na 75. percentilu stvarnih poseta, odvojeno za odgovarajuće korisničke uslove.

Izvor: Google Search Central — Core Web Vitals.

3. LCP: kada glavni sadržaj konačno postane vidljiv

LCP često predstavlja veliki element koji korisnik vidi u viewport-u:

• hero fotografiju;
• veliki naslovni blok;
• banner;
• veliku product fotografiju.

Loš LCP često nastaje zbog kombinacije problema:

• spor server;
• ogromna hero slika;
• slika se otkriva tek iz CSS-a ili JavaScript-a;
• render-blocking CSS;
• nepotrebno lazy-loading glavnog elementa;
• previše resursa sa visokim prioritetom.

Zato optimizacija LCP-a nije samo „kompresuj sliku“.

4. Nemojte lazy-loadovati ono što korisnik treba odmah da vidi

Lazy loading je odlična tehnika za sadržaj koji se nalazi daleko ispod prvog ekrana.

Ali ako glavnu hero sliku stavite iza agresivnog lazy-loading mehanizma, browser možda neće dovoljno rano shvatiti da je važna.

Rezultat:

stranica počne da se učitava, ali njen najvažniji vizuelni element kasni.

Pravilo nije:

„lazy-loaduj sve slike.“

Pravilo je:

„lazy-loaduj ono što ne mora sada.“

5. INP: sajt može izgledati učitan, a ipak biti spor

Ovo je posebno važno kod savremenih JavaScript-heavy sajtova.

Korisnik vidi stranicu.

Klikne meni.

Ništa se ne dogodi nekoliko stotina milisekundi.

Klikne ponovo.

Odjednom se sve otvori.

To je problem responzivnosti, a INP je dizajniran da ga meri.

Česti uzroci lošeg INP-a su:

• veliki JavaScript bundle;
• dugi main-thread tasks;
• teški event handleri;
• third-party skripte;
• previše DOM elemenata;
• kompleksne frontend biblioteke;
• neefikasan rendering.

6. JavaScript je često najskuplji bajt na stranici

Slika od 300 KB i JavaScript od 300 KB nisu isti trošak.

Slika uglavnom treba da se:

• preuzme;
• dekodira;
• prikaže.

JavaScript treba da se:

• preuzme;
• parsira;
• kompajlira;
• izvrši;
• eventualno manipuliše DOM-om.

Posebno na slabijem mobilnom telefonu veliki JS može biti mnogo skuplji nego što sama veličina fajla sugeriše.

7. CLS: zašto dugme beži baš kada želite da kliknete?

CLS meri neočekivana pomeranja sadržaja.

Tipičan primer:

1. učita se naslov;
2. korisnik vidi dugme;
3. iznad njega naknadno stigne slika;
4. dugme ode 200 piksela niže;
5. korisnik klikne pogrešnu stvar.

Česti uzroci:

• slike bez definisanih dimenzija;
• oglasi bez rezervisanog prostora;
• embed elementi;
• naknadno ubačen banner;
• font swap;
• dinamički UI bez rezervisanog prostora.

8. Field data i lab data nisu isto

Ovo je jedna od najvažnijih stvari za razumevanje PageSpeed Insights-a.

Lab data predstavlja kontrolisani test u simuliranim uslovima.

Field data predstavlja podatke stvarnih Chrome korisnika kada je dovoljno podataka dostupno kroz Chrome UX Report.

Zato možete videti:

• loš Lighthouse score, ali relativno dobre real-user CWV rezultate;
• odličan lab test, ali loš field INP;
• različite rezultate između URL-a i origin nivoa.

Lab je odličan za debugging.

Field data je ključan za razumevanje stvarnog iskustva.

9. Zašto se moj PageSpeed rezultat menja iz testa u test?

Zato što web nije laboratorijski konstantan sistem.

Rezultat može varirati zbog:

• server response vremena;
• cache hit/miss-a;
• third-party servisa;
• promena u mrežnim uslovima;
• CPU opterećenja;
• dinamičkog sadržaja.

Nemojte donositi ozbiljne arhitektonske odluke zato što je jedan Lighthouse test pokazao 71, a sledeći 79.

Tražite obrazac.

10. PageSpeed 100 nije poslovni KPI

Google eksplicitno savetuje da se ne juri savršen rezultat samo zbog SEO-a.

Dobar Core Web Vitals rezultat ne garantuje:

• prvo mesto;
• više leadova;
• bolji sadržaj;
• veći prihod.

Google-ovi ranking sistemi prvenstveno pokušavaju da prikažu relevantan i koristan sadržaj, a page experience je jedan deo šire slike.

Izvor: Google Search Central — Page Experience.

11. TTFB: ponekad frontend uopšte nije glavni problem

Ako server sporo vraća početni HTML, browser kasnije počinje gotovo sve ostalo.

TTFB može zavisiti od:

• hostinga;
• lokacije servera;
• backend aplikacije;
• baze podataka;
• cache strategije;
• network latency-ja;
• CDN konfiguracije.

Optimizovati slike dok backend troši dve sekunde da generiše dokument često je optimizovanje pogrešnog sloja.

12. Kada hosting jeste problem?

Hosting je verovatan kandidat kada:

• TTFB konstantno ostaje visok;
• performance pada pod većim brojem korisnika;
• server nema dovoljno CPU/RAM resursa;
• database query-ji čekaju;
• disk je spor;
• cache nije dostupan ili nije dobro konfigurisan.

Ali pre migracije treba meriti.

Mnogo sajtova promeni hosting, a prenese isti neefikasan WordPress, Magento ili custom kod na novi server.

13. Cache: najbrži posao je onaj koji server ne mora ponovo da radi

Cache može postojati na više nivoa:

• browser cache;
• page cache;
• object cache;
• application cache;
• CDN edge cache;
• database query cache.

Ali agresivan cache bez strategije može napraviti:

• zastarele cene;
• stari inventory;
• pogrešan personalizovani sadržaj;
• probleme sa login sesijom;
• stari CSS nakon deploy-a.

Cache nije ON/OFF dugme.

14. CDN: kada ima smisla?

CDN ima najveću vrednost kada:

• publika dolazi iz više geografskih regiona;
• imate mnogo statičkih asset-a;
• želite edge caching;
• origin server je daleko od dela korisnika;
• želite dodatnu zaštitu i kontrolu saobraćaja.

Ali CDN ne može popraviti svaku sporu backend funkciju.

Ako svaki request mora dinamički da ide do origin servera i čeka težak database query, samo „stavili smo Cloudflare“ ne rešava automatski problem.

15. Slike: najlakši veliki dobitak na mnogim sajtovima

Fotografija iz kamere može imati nekoliko megabajta.

Na webu možda realno treba:

• 900 px širine;
• moderni format;
• umerena kompresija;
• responsive varijanta.

Najvažniji potezi su:

• ne servirati sliku veću nego što je prikazujete;
• koristiti odgovarajuću kompresiju;
• koristiti WebP ili AVIF kada imaju smisla;
• koristiti srcset / responsive images;
• lazy-loadovati off-screen slike;
• ne lazy-loadovati kritični LCP asset bez razloga.

16. WebP ili AVIF?

Oba formata mogu biti veoma efikasna.

AVIF često može postići manji fajl pri određenom vizuelnom kvalitetu, dok je WebP široko korišćen i vrlo praktičan.

Ne treba birati format ideološki.

Merite:

• stvarnu veličinu;
• vizuelni kvalitet;
• kompatibilnost;
• trošak encode/decode workflow-a.

17. Video može da uništi odličan hero

Video background izgleda impresivno.

Ali može dodati:

• megabajte transfera;
• decode trošak;
• CPU/GPU rad;
• mobile data trošak;
• slabiji battery performance.

Ako video ne objašnjava proizvod ili ne doprinosi dovoljno iskustvu, treba preispitati njegovu cenu.

18. Fontovi: deset varijanti jednog fonta nije besplatno

Custom fontovi mogu biti važan deo identiteta.

Ali treba kontrolisati:

• broj familija;
• broj weight-ova;
• charset;
• preload;
• fallback;
• font-display ponašanje.

Ako koristite pet weight-ova, italic verzije i dve familije, browser može preuzimati veliki broj dodatnih fajlova.

19. CSS: da li korisnik čeka stilove koje neće videti?

Veliki globalni CSS bundle često sadrži stilove za:

• forme;
• slidere;
• e-commerce;
• admin komponente;
• modale;
• stranice koje korisnik nikada neće otvoriti.

Praktične tehnike mogu uključivati:

• uklanjanje unused CSS-a;
• critical CSS;
• code splitting;
• kompresiju;
• bolju organizaciju asset pipeline-a.

20. Minification nije isto što i prava optimizacija

Smanjiti CSS sa 181 KB na 151 KB je korisno.

Ali još je bolje otkriti da vam 100 KB tog CSS-a uopšte ne treba.

Isto važi za JavaScript.

Prvo smanjite količinu nepotrebnog rada.

Tek onda optimizujte način na koji se taj rad isporučuje.

21. Third-party skripte: performance dug koji niko ne želi da poseduje

Često najveći problem ne dolazi iz vašeg koda.

Dolazi od:

• analytics alata;
• chat widget-a;
• heatmap-a;
• CRM integracije;
• retargeting pixela;
• A/B testing platforme;
• review widget-a;
• social embed-a.

Svaki pojedinačno „treba samo jednu malu skriptu“.

Zajedno mogu napraviti jednu ogromnu aplikaciju koju niko nije dizajnirao.

22. Google Tag Manager nije sam po sebi problem

GTM je kontejner.

Problem je ono što kroz njega učitate.

Loš GTM setup može sadržati:

• duplikate tagova;
• zastarele pixele;
• custom HTML koji blokira;
• tagove koji firing-uju na svakoj stranici iako ne treba;
• više analytics implementacija istog događaja.

Periodični tag audit je deo performance hygiene-a.

23. WordPress: plugin nije besplatan zato što košta 0 €

WordPress problem često nije WordPress sam po sebi.

Problem može biti:

• teška tema;
• page builder;
• 50+ pluginova;
• neoptimizovana baza;
• loš hosting;
• više pluginova koji rešavaju isti problem;
• ogroman DOM;
• nepotrebni asset-i na svakoj stranici.

Instalirati četvrti speed plugin preko tri postojeća često samo povećava kompleksnost.

24. Magento: performance problem je često arhitektonski problem

Magento e-commerce može imati mnogo zahtevnije scenarije:

• veliki katalog;
• complex pricing;
• customer groups;
• faceted navigation;
• checkout;
• extensions;
• product recommendations;
• full-page cache;
• Elasticsearch/OpenSearch sloj;
• ERP integracije.

Tu „kompresuj slike“ može biti samo mali deo problema.

Potrebno je posmatrati ceo application stack.

25. Custom development nije automatski brži

Custom sajt može biti neverovatno brz.

Može biti i katastrofalno spor.

Framework ne garantuje performanse.

React, Vue, Laravel, Next.js ili bilo koji drugi stack mogu se koristiti dobro ili loše.

Važnije je:

• koliko koda šaljete;
• šta renderujete na serveru;
• šta hydrate-ujete;
• šta keširate;
• koliko third-party zavisnosti uvodite.

26. Mobile performance mora biti glavni scenario, ne naknadna provera

Desktop računar na brzoj Wi-Fi vezi lako može sakriti performance problem.

Realni korisnik može imati:

• srednju klasu Android uređaja;
• slabiji CPU;
• 4G mrežu;
• više otvorenih aplikacija;
• slab signal.

Zato test na developer MacBook-u nije dovoljna reprezentacija publike.

27. Brzina i konverzije: korelacija nije uvek ista za svaki biznis

Sporiji sajt često povećava trenje.

Ali ne postoji univerzalna formula:

„svakih 100 ms = X% više prodaje“

koja važi za svaki sajt.

Uticaj zavisi od:

• publike;
• uređaja;
• industrije;
• trenutnog performance problema;
• conversion procesa.

Zato pre i posle optimizacije treba pratiti stvarne poslovne metrike.

28. Landing stranica je posebno osetljiva na performanse

Ako ste platili klik, svaka poseta koja odustane zbog sporosti već predstavlja plaćen izgubljeni pokušaj.

Za paid traffic zato pratite:

• landing page performance;
• bounce/engagement pattern;
• form start;
• form completion;
• conversion rate;
• CPA.

Kompletan CRO okvir nalazi se u vodiču Landing page koji prodaje.

29. Brzina sajta i SEO: važna, ali nije prečica do prve pozicije

Google navodi da Core Web Vitals koristi u svojim ranking sistemima i preporučuje dobre rezultate.

Ali takođe jasno kaže da:

• ne postoji jedan jedini „page experience signal“;
• savršen CWV rezultat ne garantuje vrh rezultata;
• relevantniji sadržaj i dalje može rangirati iznad brže stranice.

Zato je loša SEO strategija:

„Ne rangiramo jer imamo PageSpeed 83, hajde da potrošimo mesec da dobijemo 100.“

Prvo treba utvrditi stvarni problem kroz SEO analizu sajta.

30. Kako bih prioritizovao performance probleme?

31. Prvo rešavajte velike stvari

Tipičan redosled može biti:

1. server/backend bottleneck;
2. kritični LCP asset;
3. ogroman JavaScript workload;
4. veliki nepotrebni asset-i;
5. third-party script problemi;
6. CLS greške;
7. cache politika;
8. manji micro-optimization detalji.

Nema smisla potrošiti tri sata na uštedu 3 KB ikonica ako homepage šalje hero video od 8 MB.

32. Kako meriti pre i posle?

Napravite baseline pre promene.

Zabeležite:

• Core Web Vitals field podatke;
• Lighthouse testove;
• server response;
• veličinu transfera;
• broj request-ova;
• conversion rate;
• CPA kada imate paid traffic;
• relevantne engagement metrike.

Zatim menjajte kontrolisano.

Ako promenite hosting, temu, JavaScript, CTA i kampanju istog dana, vrlo teško ćete znati šta je proizvelo rezultat.

33. Koje alate koristiti?

Za različite nivoe problema koriste se različiti alati.

• PageSpeed Insights — kombinacija field i lab konteksta kada su podaci dostupni;
• Chrome Lighthouse — lab dijagnostika;
• Chrome DevTools Performance — main-thread i rendering analiza;
• Network panel — request waterfall;
• Search Console Core Web Vitals — grupni field problemi;
• CrUX — real-user Chrome podaci;
• server/APM alati — backend problemi;
• RUM — sopstveno real-user merenje.

34. PageSpeed Insights nije zamena za developer-a

Alat može reći:

„Reduce unused JavaScript.“

Ali ne zna:

• koju poslovnu funkciju taj JavaScript podržava;
• da li je deo checkout-a;
• da li je potreban pravnoj saglasnosti;
• da li ga koristi marketing;
• kako ga bezbedno ukloniti.

Dijagnostika pokazuje simptom.

Inženjerska odluka zahteva kontekst.

35. Kada speed plugin ima smisla?

Na jednostavnom WordPress sajtu dobar performance plugin može brzo rešiti:

• page caching;
• minification;
• lazy loading;
• preload;
• određene CSS/JS optimizacije.

Ali plugin ne može pouzdano rešiti:

• lošu aplikacionu arhitekturu;
• sporu eksternu API integraciju;
• težak database model;
• nepotrebno kompleksan frontend;
• business logic bottleneck.

36. Kada je potrebna ozbiljnija rekonstrukcija?

Ako stalno popravljate posledice, a ne uzrok, možda je vreme za arhitektonsku promenu.

Signali mogu biti:

• svaka nova funkcija dodatno usporava sajt;
• pluginovi više ne mogu bezbedno da se ažuriraju;
• frontend ima ogromnu tehničku zavisnost;
• server ne može normalno da podnese rast;
• mobile UX zahteva potpuno drugačiju strukturu;
• legacy kod ograničava optimizaciju.

U toj situaciji nije racionalno beskonačno popravljati staru osnovu.

Može imati više smisla planirati novi web razvoj ili redizajn sajta.

37. Koliko košta optimizacija brzine sajta?

Ne postoji jedna cena jer problem može biti:

• jedna neoptimizovana hero slika;
• loš WordPress plugin setup;
• server konfiguracija;
• Magento arhitektura;
• veliki JavaScript refactor;
• kompletna migracija.

Pre cene zato treba uraditi audit problema.

To je isti princip kao kod izrade sajta: jednostavan projekat i kompleksna aplikacija nemaju istu ekonomiku. Više o širim web budžetima možete pročitati u vodiču koliko košta izrada sajta u Srbiji.

38. Da li novi sajt automatski treba da bude brz?

Trebalo bi da performance bude deo acceptance criteria-a.

Ali „nov“ ne znači automatski „brz“.

Novi sajt može već prvog dana imati:

• 6 MB hero video;
• četiri tracking platforme;
• veliki page builder;
• ogroman animation bundle;
• neoptimizovane slike;
• 30 font fajlova.

Zato performanse treba projektovati, ne proveravati tek nakon launch-a.

39. Performance budget: ograničenja definisana pre developmenta

Na ozbiljnijem projektu korisno je unapred definisati ciljeve.

Na primer:

• maksimalna početna JS količina;
• ciljana veličina hero asset-a;
• broj third-party skripti;
• CWV ciljevi;
• budžet request-ova;
• mobile test uređaji.

Ako performance cilj postoji tek na kraju projekta, svaka funkcija je već napravila svoj dug.

40. Performance je timski problem

Developer ne kontroliše sve.

Marketing može sutra dodati pet novih tagova.

Content tim može uploadovati hero sliku od 9 MB.

Dizajner može tražiti četiri web font familije.

Product tim može dodati novi chat widget.

Zato dobar performance proces zahteva pravila koja razume ceo tim.

41. Koliko često treba ponovo testirati sajt?

Performanse nisu jednokratni projekat.

Testiranje ima smisla:

• nakon većeg deploy-a;
• nakon promene teme;
• nakon novog tracking sistema;
• nakon dodavanja chat/widget sistema;
• nakon migracije hostinga;
• periodično za ključne landing stranice.

Sajt koji je danas brz može za šest meseci akumulirati značajan performance dug.

42. Performance checklist za produkcioni sajt

43. Šta ne treba raditi?

44. Kako bih radio performance audit u praksi?

Redosled koji ima više smisla od nasumičnog rešavanja Lighthouse warning-a:

1. Utvrditi najvažnije URL-ove — homepage nije automatski jedina stranica koja vredi analizirati.
2. Pogledati field podatke — gde stvarni korisnici imaju problem?
3. Napraviti lab reprodukciju — možemo li problem ponoviti i analizirati?
4. Identifikovati bottleneck — server, asset, JS, rendering ili third-party?
5. Procena impact/effort/risk.
6. Implementacija najvrednijeg fix-a.
7. Regression test — šta smo eventualno pokvarili?
8. Ponovno merenje.

45. Šta bih prvo optimizovao na malom poslovnom sajtu?

Najčešće bih proverio:

• hosting/TTFB;
• hero sliku;
• WordPress temu i pluginove;
• fontove;
• cache;
• third-party tagove;
• mobile hero i navigaciju.

Tu nekoliko velikih poteza često daje većinu rezultata.

46. Šta bih prvo proverio na e-commerce sajtu?

Prioritet se menja:

• category pages;
• product pages;
• search/filter;
• cart;
• checkout;
• image gallery;
• recommendation widgete;
• tracking i marketing tagove;
• backend/cache sloj.

Brz homepage ne znači mnogo ako korisnik čeka četiri sekunde da promeni varijantu proizvoda ili otvori checkout.

47. Šta bih prvo proverio na landing stranici?

Tu je cilj vrlo jasan:

• da hero brzo postane vidljiv;
• da CTA reaguje odmah;
• da forma ne kasni;
• da nema layout shift-a;
• da tracking ne blokira interfejs;
• da mobilni korisnik bez problema izvrši cilj.

Landing performance treba posmatrati zajedno sa conversion rate-om i CPA-om, ne odvojeno od kampanje.

48. Da li AI i generativna pretraga menjaju važnost brzine sajta?

Ne menjaju osnovni princip.

Čak i ako korisnik dođe preko ChatGPT Search-a, AI Overview-a ili drugog generativnog odgovora, nakon klika je ponovo običan web korisnik.

I dalje mora da:

• učita stranicu;
• pročita sadržaj;
• koristi interfejs;
• izvrši akciju.

Zato AI visibility ne čini web performance manje važnim.

Samo dodaje još jedan potencijalni izvor saobraćaja ka istom web iskustvu.

Zaključak: brz sajt nije sajt koji je osvojio PageSpeed — već sajt koji korisniku ne stoji na putu

Optimizacija performansi sajta ima smisla kada uklanja stvarno trenje.

Najvažnije je razumeti:

• šta stvarni korisnici čekaju;
• koji Core Web Vital pravi problem;
• da li je bottleneck frontend ili backend;
• koji resursi su stvarno potrebni;
• koliko third-party koda plaćamo performansama;
• kakav je rezultat na mobilnim uređajima;
• da li optimizacija poboljšava poslovni rezultat.

PageSpeed Insights je odličan alat.

Ali nije proizvodni cilj.

Najbolja performance optimizacija je ona koju korisnik ne primećuje — samo oseća da sajt radi odmah.

Ako je postojeći sajt spor zbog arhitekture, zastarele teme, tehničkog duga ili neefikasne aplikacije, pogledajte naše usluge web razvoja i redizajna.