Optimizacija performansi sajta znači da svaki zahtjev postane brži – od prvog bajta koji server pošalje do trenutka kada posjetilac zaista može kliknuti na dugme. Spore stranice koštaju na načine koji se rijetko vide na fakturi: kupci napuštaju korpu, budžet za oglase plaća klikove koji odmah odlaze, pretraživači rjeđe indeksiraju sajt, a server koji bi trebao izdržati nagli porast posjeta umjesto toga padne.
Sadržaj
U CodeWizu performanse posmatramo kao inženjerski problem, a ne kao plugin koji se instalira. Profilišemo aplikaciju, bazu podataka, server i mrežni put, a zatim rješavamo stvarna uska grla: keširanjem cijelih stranica u Varnishu, optimizovanim kodom, podešenim upitima i pravilno konfigurisanim CDN-om. Naš sajt codewizdev.com ima rezultat 100/100 u sve četiri kategorije PageSpeed Insightsa, i na mobilnim uređajima i na desktopu – istu disciplinu primjenjujemo i na projekte klijenata.
Usluga je namijenjena online prodavnicama koje usporavaju pod opterećenjem, sadržajnim sajtovima i WordPress instalacijama koje su rasle plugin po plugin, SaaS proizvodima i API-jima čije se vrijeme odziva povećava kako rastu podaci, te agencijama kojima treba pouzdan partner za spašavanje sajtova klijenata pred lansiranje. Ako račun za hosting stalno raste, a stranice su sve sporije, problem gotovo nikada nije „premalo servera”.
Kod teme performansi alati otvorenog koda su prvi izbor kada odgovaraju poslu.
Prvo mjerenje: odakle počinje optimizacija performansi sajta
Svaka optimizacija koju radimo počinje od početnog mjerenja. Nagađanje troši budžet: timovi kupuju jači server, a pravi uzrok je jedan upit bez indeksa, ili minifikuju CSS dok chat widget blokira glavnu nit punu sekundu. Kombinujemo laboratorijske podatke (ponovljivi testovi u kontrolisanim uslovima) i podatke sa terena (ono što stvarni posjetioci doživljavaju na svojim uređajima i mrežama).
Performansi kreće od sistema koji već radi, a ne od praznog šablona.
| Alat | Vrsta podataka | Šta nam govori |
|---|---|---|
| PageSpeed Insights i CrUX | Laboratorijski i terenski | Lighthouse dijagnostiku i Core Web Vitals stvarnih korisnika za posljednjih 28 dana, na 75. percentilu |
| WebPageTest | Laboratorijski | Waterfall prikaze, filmstrip, TTFB sa različitih lokacija i usporene mobilne konekcije |
| Chrome DevTools Performance panel | Laboratorijski | Duge zadatke, pomjeranje rasporeda, resurse koji blokiraju prikaz i skriptu koja odgađa interakciju |
| web-vitals biblioteka (RUM) | Terenski | LCP, INP i CLS po šablonu stranice, tipu uređaja i državi, od vaših posjetilaca |
| Profileri za server (SPX, Xdebug, Blackfire, Clinic.js) | Backend | Koja funkcija, upit ili eksterni poziv troši vrijeme zahtjeva |
| Slow query log, pg_stat_statements | Baza podataka | Upite koji ukupno najviše koštaju, a ne samo najsporiji pojedinačni upit |
Rezultat ove faze je kratak izvještaj sa prioritetima: šta je sporo, zašto, koliko će svaka izmjena vjerovatno pomoći i koliko posla zahtijeva. Googleova Web Vitals dokumentacija definiše ciljeve prema kojima radimo – LCP ispod 2,5 sekunde, INP ispod 200 milisekundi i CLS ispod 0,1 – ali za nas su to minimum, a ne cilj. Frontend stranu tog posla detaljno opisujemo u članku o tome kako CodeWiz postiže savršenih 100/100 page vitals.
Varnish keširanje za dinamične sajtove i online prodavnice
Varnish je HTTP reverse proxy koji gotove stranice čuva u memoriji i servira ih za nekoliko mikrosekundi, bez pokretanja PHP-a, Node.js-a ili upita prema bazi. Za WordPress, WooCommerce, Magento ili Laravel sajt sa pretežno anonimnim posjetiocima to je često najveće pojedinačno poboljšanje na strani servera: aplikacija generiše stranicu jednom, a Varnish servira hiljade narednih zahtjeva za nju.
Varnishu smo posvetili poseban članak o tome zašto je Varnish Cache tajno oružje brzih web stranica, pa se ovdje fokusiramo na ono zbog čega Varnish radi u produkciji, a ne samo u benchmarku.
Šta konfigurišemo
- Higijena kolačića: Varnish podrazumijevano ne kešira zahtjeve sa kolačićima, a kolačići za analitiku i saglasnost nalaze se na gotovo svakom zahtjevu. Uklanjamo kolačiće koji backendu ne trebaju, a zadržavamo samo one za sesiju i korpu.
- Čisti cache ključevi: parametri za praćenje poput
utm_source,gclidifbclidse uklanjaju, kako jedna kampanja ne bi rascjepkala cache na hiljade kopija iste stranice. - Grace mode: zastarjeli sadržaj se servira dok se nova verzija preuzima u pozadini, a sajt ostaje dostupan i ako backend nakratko otkaže.
- Precizna invalidacija: purge i ban zahtjevi – ili invalidacija po tagovima uz xkey modul – koje CMS pokreće kada se promijeni proizvod, cijena ili članak.
- TLS ispred: open-source Varnish ne terminira HTTPS, pa ispred postavljamo Nginx ili Hitch, a Varnish ide između njih i aplikacije.
vcl 4.1;
backend default { .host = "127.0.0.1"; .port = "8080"; }
sub vcl_recv {
if (req.url ~ "^/(wp-admin|wp-login|cart|checkout|my-account)") {
return (pass);
}
if (req.http.Cookie !~ "wordpress_logged_in|woocommerce_items_in_cart") {
unset req.http.Cookie;
}
set req.url = regsuball(req.url, "(utm_[a-z]+|gclid|fbclid)=[^&]*&?", "");
set req.url = regsub(req.url, "[?&]+$", "");
}
sub vcl_backend_response {
set beresp.grace = 24h;
}Nakon toga pratimo hit ratio alatom varnishstat, a preostale promašaje pronalazimo pomoću varnishlog. Dobro podešen Varnish na sadržajnom sajtu servira veliku većinu anonimnih pregleda direktno iz memorije. Zvanična Varnish dokumentacija je referenca za sam VCL.
Optimizacija koda: brži backend i lakši frontend
Keširanje sakriva spor kod od anonimnih posjetilaca, ali prijavljeni korisnici, korpe, checkout, kontrolni paneli i API-ji i dalje pri svakom zahtjevu pokreću aplikaciju. Optimizacija koda ubrzava upravo te dijelove koji se ne keširaju, a usput i svaki promašaj cachea čini jeftinijim.
Profilisanje i ispravke na backendu
Profilišemo stvarne zahtjeve umjesto da čitamo kod i nagađamo: SPX ili Xdebug za PHP, Clinic.js i ugrađeni --cpu-prof za Node.js, py-spy za Python. Nalazi su obično predvidivi:
- N+1 upiti – jedan upit za listu i još po jedan za svaki red u njoj, najčešći problem u ORM-ovima kao što su Eloquent, Doctrine, Sequelize i Prisma.
- Sinhroni posao koji pripada redu čekanja (queue) – slanje mejlova, generisanje PDF-ova, pozivi API-ja za plaćanje ili dostavu i obrada slika tokom samog zahtjeva.
- Ponovljeni skupi proračuni koje treba keširati u Redisu uz razumno vrijeme isteka.
- Loša konfiguracija runtimea – isključen ili premali PHP OPcache, uključen
opcache.validate_timestampsu produkciji, PHP-FPM poolovi dimenzionisani za pogrešnu količinu memorije ili Node.js event loop blokiran sinhronim radom sa fajlovima i kriptografijom.
// N+1: jedan upit za narudžbe, pa po jedan za svakog kupca
$orders = Order::latest()->take(50)->get();
foreach ($orders as $order) {
echo $order->customer->name;
}
// Ispravljeno: ukupno dva upita, bez obzira na dužinu liste
$orders = Order::with('customer')->latest()->take(50)->get();
// U razvoju prijavi grešku čim se lazy loading ponovo pojavi
Model::preventLazyLoading(! app()->isProduction());Isporuka frontenda
U pregledniku smanjujemo ono što se mora preuzeti, parsirati i izvršiti prije nego što stranica postane upotrebljiva: kritični CSS ugrađen u stranicu, uklonjen nekorišteni JavaScript, responzivne AVIF ili WebP slike sa zadatim dimenzijama, fontovi sa vlastitog servera uz font-display: swap i preload za glavnu sliku. Posebnu pažnju posvećujemo skriptama trećih strana – chat widgetima, tag managerima, heatmapama – jer su one najčešći uzrok lošeg INP-a.
Optimizacija baze podataka za MySQL, MariaDB i PostgreSQL
Većini aplikacija kojima „treba jači server” zapravo trebaju bolji upiti. Optimizacija baze podataka obično donosi najveći dobitak po satu rada, jer jedan nedostajući indeks može učiniti upit stotinama puta sporijim kako tabela raste – a to usporavanje dolazi postepeno, pa ga niko ne primijeti dok checkout ne počne pucati zbog isteka vremena.
Kako pronalazimo skupe upite
- MySQL i MariaDB: slow query log sa niskim
long_query_time, sažet alatompt-query-digestiz Percona Toolkita. - PostgreSQL:
pg_stat_statementsza rangiranje upita po ukupnom vremenu iauto_explainza planove sporih upita. EXPLAINiEXPLAIN ANALYZEnad svakim kandidatom, da vidimo pune prolaze kroz tabelu, filesort i privremene tabele.
-- Prije: pun prolaz kroz tabelu i filesort
EXPLAIN SELECT id, total FROM orders
WHERE customer_id = 4821 AND status = 'paid'
ORDER BY created_at DESC LIMIT 20;
-- Poslije: jedan kompozitni indeks koji prati filter i sortiranje
CREATE INDEX idx_orders_customer_status_created
ON orders (customer_id, status, created_at);Više od indeksa
- Konfiguracija servera: InnoDB buffer pool prilagođen radnom skupu podataka, razumni
work_memishared_buffersu PostgreSQL-u, ograničenja konekcija usklađena sa aplikacijom. - Connection pooling uz PgBouncer ili ProxySQL za aplikacije koje otvaraju mnogo kratkotrajnih konekcija.
- WordPress specifičnosti: prenatrpane autoload opcije, preveliki upiti nad
wp_postmeta, istekli transienti i prelazak WooCommercea na High-Performance Order Storage. - Read replike za izvještaje i pretragu, kako teška analitika nikada ne bi konkurisala checkoutu.
- Arhiviranje starih podataka, a kada jedna tabela zaista preraste jedan server, particionisanje ili sharding – pogledajte naš vodič o razlici između shardinga i particionisanja baze podataka.
Konfiguracija CDN-a koja zaista ubrzava sajt
CDN čuva kopije vašeg sadržaja u data centrima blizu posjetilaca, čime smanjuje kašnjenje za međunarodnu publiku i rasterećuje vaš server. Ipak, samo uključivanje CDN-a često donese mnogo manje od očekivanog: HTML se uopšte ne kešira, cache ključeve zagađuju kolačići i query parametri, a hit ratio ostaje nizak. Upravo konfiguracija CDN-a pravi tu razliku.
Šta uključuje CDN podešen za performanse
- Cache pravila za statičke fajlove sa dugim trajanjem i imenima fajlova sa hashom, tako da se kešira godinu dana, a nova verzija se ipak objavljuje odmah.
- Keširanje HTML-a na edge serverima za anonimne posjetioce gdje je to sigurno, uz pravila zaobilaženja za sesije, korpe i administraciju.
- Tiered caching ili origin shielding, kako promašaj na jednoj lokaciji ne bi značio zahtjev prema vašem serveru sa svake lokacije.
- Brotli kompresija, HTTP/3 i TLS 1.3, uz Early Hints gdje ih platforma podržava.
- Promjena veličine i formata slika na edge serverima, da svaki uređaj dobije fajl odgovarajuće veličine.
- Ispravna integracija purge zahtjeva sa vašim CMS-om ili deployment pipelineom.
Najčešće radimo sa Cloudflareom, a njegova podešavanja detaljno obrađujemo u članku o profesionalnoj Cloudflare konfiguraciji za maksimalne performanse. Bunny CDN i Amazon CloudFront su dobre alternative, zavisno od budžeta i postojeće infrastrukture.
Kako se slojevi keširanja uklapaju
Varnish, CDN i object cache nisu konkurenti – svaki rješava drugi dio problema. Prava kombinacija zavisi od vaše publike, koliko su stranice personalizovane i koliko se često sadržaj mijenja.
| Sloj | Šta čuva | Tipični alati | Najbolji za | Na šta paziti |
|---|---|---|---|---|
| Cache preglednika | CSS, JS, fontove, slike | Cache-Control, imena fajlova sa hashom | Ponovne posjete i sesije sa više stranica | Zastarjeli fajlovi bez verzionisanja imena |
| CDN edge | Statičke fajlove, po potrebi i HTML | Cloudflare, Bunny CDN, CloudFront | Međunarodnu publiku i rasterećenje servera | Kolačići i query parametri u cache ključu |
| Varnish | Cijele HTML stranice na serveru | Varnish uz Nginx ili Hitch za TLS | Dinamične CMS sajtove uz preciznu kontrolu kroz VCL | Prijavljeni korisnici, strategija purge zahtjeva |
| Object cache | Rezultate upita, izračunate fragmente | Redis, Memcached | Prijavljene korisnike, korpe, API-je | Logika invalidacije, dimenzionisanje memorije |
| Bytecode cache | Kompajlirani PHP | OPcache | Svaku PHP aplikaciju | Resetovanje pri svakom deploymentu |
Podešavanje servera i hostinga
I najbrži kod treba dobro podešen server. Podešavamo Nginx (keep-alive, kompresija, microcaching tamo gdje bi Varnish bio previše), upravljanje PHP-FPM procesima na osnovu izmjerene memorije po procesu, te Node.js klasterovanje uz PM2 ili systemd. Infrastrukturu dimenzionišemo prema stvarnim potrebama: ponekad prelazak sa shared hostinga na skroman VPS sa NVMe diskom donese više od bilo koje izmjene koda, a ponekad je iskren odgovor da je vaš server već predimenzionisan.
Budžeti performansi i stalni nadzor
Performanse opadaju neprimjetno: novi plugin, marketinški tag, teža naslovna slika. Zato postavljamo budžete performansi (maksimalna količina JavaScripta, ciljni LCP po šablonu) i provjeravamo ih Lighthouse CI-jem u deployment pipelineu. U produkciji praćenje stvarnih korisnika (RUM) prijavljuje Core Web Vitals po šablonu, a Prometheus i Grafana prate vrijeme odziva, hit ratio i spore upite, uz upozorenja prije nego što problem primijete kupci ili pretraživači.
Najčešće greške u optimizaciji performansi sajta
- Više plugina za keširanje jedan preko drugog, pri čemu svaki djelimično poništava rad ostalih.
- Učitavanje svih skripti i stilova na svakoj stranici, uključujući slidere, forme i mape koji se pojavljuju na samo jednoj.
- Lazy loading glavne slike, što odgađa LCP umjesto da ga ubrza.
- Kupovina jačeg servera da bi se nadoknadio N+1 upit ili nedostajući indeks.
- Greškom keširane stranice za prijavljene korisnike ili korpe, pa jedan kupac vidi podatke drugog.
- Optimizacija za laboratorijski rezultat, dok stvarni korisnici na telefonima srednje klase i dalje čekaju.
Kako radimo
- Analiza: prikupljamo laboratorijske i terenske podatke, profilišemo backend i bazu, te pregledamo konfiguraciju servera, CDN-a i keširanja.
- Prioriteti: dobijate izvještaj u kojem je svaka izmjena rangirana po očekivanom efektu i potrebnom radu, kako bi budžet otišao na ono što najviše znači.
- Optimizacija: uvodimo dogovorene izmjene – slojeve keširanja, izmjene koda i upita, CDN pravila, podešavanje servera – najprije na staging kopiji.
- Provjera: radimo testove opterećenja, poredimo metrike prije i poslije, te provjeravamo da korpe, prijave i personalizovane stranice ispravno rade uz uključeno keširanje.
- Puštanje u rad: izmjene uvodimo postepeno, uz pažljivo praćenje hit ratija, grešaka i vremena odziva.
- Nadzor: budžeti performansi i praćenje stvarnih korisnika čuvaju postignute rezultate, a po želji nastavljamo sa održavanjem.
Zašto CodeWiz
- Dokazano na vlastitom sajtu: codewizdev.com ima rezultat 100/100/100/100 u PageSpeed Insightsu, i na mobilnim uređajima i na desktopu.
- Full-stack znanje: Laravel, Node.js i WordPress kod pišemo sami, pa spor kod ispravljamo na izvoru umjesto da ispred njega samo dodajemo cache.
- Cijeli lanac u jednom timu: kod, baza, server, Varnish i Cloudflare – bez prebacivanja odgovornosti između različitih dobavljača.
- Open-source na prvom mjestu: Varnish, Redis, Nginx, PgBouncer i Prometheus znače bez troškova licenci i bez zavisnosti od jednog dobavljača.
- Fer cijene: vrhunski razvoj bez vrhunskih cijena, od tima iz Banje Luke koji radi na daljinu sa klijentima iz regiona i svijeta – saznajte više o CodeWizu.
Često postavljana pitanja
Koliko košta optimizacija performansi sajta?
Zavisi od platforme, veličine koda i broja slojeva koje treba srediti. Fokusirana analiza sa brzim poboljšanjima je mali projekat, dok je prerada keširanja, upita i infrastrukture za veliku online prodavnicu veći posao. Jasnu procjenu dobijate nakon početne analize, prije nego što počne bilo kakav rad.
Koliko brzo ću vidjeti rezultate?
Izmjene na strani servera, poput Varnisha, CDN pravila i indeksa u bazi, djeluju odmah. Laboratorijski rezultati se poprave čim se izmjene objave, dok se terenski podaci u PageSpeed Insightsu i Search Consoleu računaju za posljednjih 28 dana, pa ih sustignu u narednim sedmicama.
Da li mi treba Varnish ako već koristim Cloudflare?
Ne uvijek. Cloudflare može keširati HTML na edge serverima i nekim sajtovima je to dovoljno. Varnish donosi vrijednost kada trebate preciznu kontrolu nad onim što se kešira, invalidaciju po tagovima, grace mode ili zaštitu servera koji prima mnogo nekeširanog saobraćaja. Preporučujemo najjednostavniju kombinaciju koja ispunjava vaše ciljeve.
Možete li ubrzati WordPress ili WooCommerce sajt bez izrade novog?
U većini slučajeva možemo. Uklanjanje teških plugina i skripti, čišćenje baze, Redis object cache, keširanje cijelih stranica, CDN i podešavanje PHP-a obično donesu veliko poboljšanje bez redizajna.
Da li će keširanje pokvariti korpu, checkout ili članski dio sajta?
Neće, ako je pravilno podešeno. Sesije, korpe, checkout i korisničke naloge isključujemo iz zajedničkog cachea i svaki personalizovani tok testiramo na stagingu prije nego što bilo šta ode u produkciju.
Spremni za brži sajt?
Pošaljite nam adresu sajta i recite gdje vas brzina najviše muči – landing stranice, checkout, pretraga ili administracija – a mi ćemo vam pokazati šta ga usporava i šta je potrebno da se to riješi. Kontaktirajte nas i počnite sa analizom performansi ili pogledajte naše usluge optimizacije performansi.