Optimizacija brzine sajta: praktičan plan bez nasumičnog instaliranja dodataka

Optimizacija brzine sajta ima tri koraka koji se ne preskaču: dijagnoza (šta je zaista sporo, na kom uređaju i na kojoj stranici, mereno laboratorijski i na stvarnim korisnicima), najveće poluge redom po uticaju (slike, fontovi, JavaScript i višak dodataka, kritični CSS, keširanje, server) i kontrola (test da ništa nije pokvareno, ponovno merenje, praćenje Core Web Vitals). Cilj nije zelena ocena u PageSpeed-u, već LCP ispod 2,5 s, INP ispod 200 ms i CLS ispod 0,1 na mobilnom, za stvarne posetioce. Ovaj vodič daje plan koji radi na WordPressu bez instaliranja pet „dodataka za brzinu“ koji se međusobno tuku.

Za dodatnu proveru preporuka iz ovog vodiča pogledajte Google smernice za Core Web Vitals i Google vodič za SEO.

Spor sajt gubi posetioce pre nego što išta pročitaju, gura pozicije naniže, jer Google meri brzinu na stvarnim korisnicima, i smanjuje konverziju na svakoj sekundi čekanja. Većina vlasnika to zna i reaguje instaliranjem dodatka koji obećava „100/100“. Rezultat je najčešće sajt koji je u laboratoriji brži, u praksi isti, a povremeno se lomi. Brzina se rešava kao i svaki tehnički problem: prvo uzrok, pa lek, pa provera. Kako se uklapa u širi SEO rad objašnjeno je u SEO vodiču; ovde je samo brzina, do kraja.

Dijagnoza pre popravke

Dva sajta sa istom ocenom 45 u PageSpeed-u mogu imati potpuno različite uzroke: jedan učitava 6 MB slika, drugi 40 JavaScript fajlova iz buildera. Isti lek za oba ne radi, pa dijagnoza dolazi pre svega.

Laboratorijski i stvarni podaci

Laboratorijski podaci (PageSpeed Insights, Lighthouse u Chrome-u, WebPageTest) mere jednu stranicu u kontrolisanim uslovima, sa simuliranim sporim telefonom i mrežom. Dobri su za dijagnozu, jer tačno pokazuju šta se učitava, koliko traje i šta blokira prikaz; loši su kao jedini merilo, jer se razlikuju od posete do posete i ne odražavaju vaše stvarne korisnike. Stvarni podaci (deo „Discover what your real users are experiencing“ u PageSpeed-u, iz Chrome UX izveštaja, i izveštaj Core Web Vitals u Search Console-u) mere šta su posetioci zaista doživeli tokom poslednjih 28 dana, po stranicama i uređajima. To je ono što Google koristi za rangiranje i to je merilo uspeha. Pravilo: dijagnoza laboratorijski, odluka i praćenje po stvarnim podacima. Ako sajt nema dovoljno poseta za stvarne podatke, oslonite se na laboratoriju sa mobilnim profilom i merite više puta.

Tri metrike koje se gledaju: LCP (Largest Contentful Paint, koliko traje dok se najveći element prikaže; cilj ispod 2,5 s), INP (Interaction to Next Paint, koliko sajt kasni na klik ili dodir; cilj ispod 200 ms) i CLS (Cumulative Layout Shift, koliko se sadržaj pomera dok se učitava; cilj ispod 0,1). Ukupna ocena od 0 do 100 je izvedena i manje važna od ove tri.

Najsporiji šabloni i uređaji

Ne meri se „sajt“, već tipovi stranica: početna, stranica usluge, blog članak, kategorija i proizvod kod prodavnice, kontakt. Svaki šablon ima svoje uzroke (početna slajder i video, proizvod galeriju i skripte za varijante, blog ugrađene mape i komentare). U Search Console-u grupišite stranice sa lošim CWV po šablonu i počnite od onog koji ima najviše saobraćaja i najgore brojke. Uređaj je uvek mobilni: većina poseta i najgori rezultati su tamo, a Google rangira po mobilnoj verziji. Pre bilo kakve izmene zapišite polazne brojke za svaki šablon (LCP, INP, CLS, ukupna težina stranice u MB, broj zahteva), jer bez toga ne možete da dokažete šta je pomoglo, a šta ne.

Najveće poluge

Redosled ispod je po uticaju za tipičan WordPress sajt. Radi se jedna poluga, meri se, pa sledeća; rad na svemu odjednom onemogućava da znate šta je delovalo i teže se vraća ako nešto pukne.

Slike, fontovi i kritični CSS

Slike su najčešći i najveći uzrok: fotografija od 4.000 piksela i 3 MB koja se prikazuje u širini od 800 piksela. Rešenje ima tri dela: dimenzije (slike se otpremaju u veličini koja se prikazuje, ili se koriste responsive varijante koje WordPress pravi automatski ako ih tema traži), format i kompresija (WebP ili AVIF umesto JPEG/PNG, kvalitet 75 do 85, što smanjuje težinu 3 do 5 puta bez vidljive razlike; WordPress od verzije 6.5 pravi WebP kopije sam, ili dodatak za optimizaciju slika) i odloženo učitavanje (loading=”lazy” za slike ispod preloma, što WordPress radi podrazumevano, ali ne za sliku u hero sekciji, koja mora da se učita odmah i da bude označena kao prioritetna). Tipična ušteda: 1 do 3 sekunde LCP-a i 50 do 70 % ukupne težine stranice.

Fontovi. Svaki font sa Google Fonts ili sličnog servisa je dodatni zahtev ka drugom domenu i čekanje pre nego što se tekst prikaže. Rešenje: fontovi se čuvaju na sopstvenom serveru u WOFF2 formatu, učitavaju se samo težine koje se koriste (obično dve do tri, ne osam), sa font-display: swap da tekst bude vidljiv odmah, i preload za glavni font. Ušteda 0,3 do 1 sekunda i uklanjanje pomeranja sadržaja. Kritični CSS. Pregledač ne prikazuje ništa dok ne učita sve CSS fajlove; tema sa builderom ima ih desetak. Rešenje je da se CSS potreban za prvi ekran ubaci direktno u stranicu, a ostatak učita odloženo; keš dodaci to rade automatski, uz proveru da nisu pokvarili prikaz. Ušteda 0,3 do 0,8 sekundi na prvom prikazu.

JavaScript, cache i server

JavaScript i dodaci. Ovo je uzrok lošeg INP-a i najteže se rešava dodatkom, jer je uzrok u drugim dodacima: slajder koji učitava 200 KB skripte na svakoj stranici iako je samo na početnoj, forma koja učitava svoj JS svuda, tri alata za analitiku i chat, builder sa sopstvenim slojem, dodaci za deljenje na mrežama koje niko ne koristi. Rešenje: popis svakog dodatka sa pitanjem „šta se dešava ako ga nema“, uklanjanje viška, učitavanje skripti samo na stranicama gde su potrebne, odlaganje nekritičnih (analitika, chat) posle prikaza, i, kod redizajna, tema bez buildera. Ušteda: INP sa 400 na 150 ms, 20 do 40 zahteva manje. Keširanje. WordPress sastavlja svaku stranicu iznova pri svakoj poseti; keš dodatak (jedan, dobar: WP Rocket, LiteSpeed Cache ako je server LiteSpeed, ili sličan) čuva gotovu stranicu i isporučuje je za deo vremena; uz to keširanje u pregledaču i, za sajtove sa publikom van Srbije, CDN. Ušteda 0,5 do 2 sekunde na svakom učitavanju posle prvog. Server. Deljeni hosting sa starim PHP-om i sporim diskom postavlja plafon koji nijedna optimizacija ne probija: vreme do prvog bajta (TTFB) iznad 600 ms znači da je server usko grlo. Rešenje: PHP 8.2+, hosting sa NVMe diskovima i serverskim keširanjem, po potrebi prelazak na managed WordPress ili VPS; kako izabrati, opisano je u vodiču o domenu i hostingu.

Kontrola posle izmene

Svaka od poluga može da pokvari nešto što je radilo: odloženi JavaScript može da onemogući formu, kritični CSS može da razbije prikaz na jednom šablonu, keš može da servira zastarelu korpu. Zato se optimizacija ne završava merenjem brzine, već proverom da sajt i dalje radi.

Regresioni testovi

Posle svake izmene prolazi se ista lista, na telefonu i računaru: forme šalju i prikazuju potvrdu; meni, slajderi i modali rade; kod prodavnice korpa, varijante, checkout i plaćanje; prijava u admin; prikaz svih šablona bez pomerenih elemenata; analitika i dalje beleži događaje (odloženi JS često „ugasi“ praćenje, pa izveštaji izgledaju kao pad saobraćaja). Izmene se rade na stagingu ili bar u vreme malog saobraćaja, sa kopijom pre, i sa mogućnošću da se za pet minuta vrati staro. Zatim ponovno merenje istih šablona istim alatom i upis u tabelu pored polaznih brojki.

Praćenje Core Web Vitals

Stvarni podaci kasne: izveštaj Core Web Vitals u Search Console-u pokriva 28 dana, pa se efekat vidi u potpunosti tek mesec dana posle izmene. Pratite ga mesečno, po šablonu i uređaju, i reagujte kada se grupa stranica vrati u „loše“. Brzina se najčešće kvari postepeno, kroz nove dodatke, novi font koji je dizajner dodao, video u hero sekciji, slike koje urednik otprema u punoj veličini. Zato tri pravila ulaze u redovno održavanje: novi dodatak se instalira tek posle pitanja „šta se dešava bez njega“ i merenja posle; urednici otpremaju slike u pravoj veličini ili sajt to radi automatski; kvartalno merenje ključnih šablona sa upisom u tabelu. Sve to je deo onoga što radimo u okviru održavanja sajta. Ako je tema ili builder plafon koji se ne može probiti, brzina je jedan od sedam znakova da je vreme za redizajn, i tada se rešava temom po meri koja je brza podrazumevano; kako to izgleda, na stranici SEO optimizacija i pri izradi WordPress sajta.

Najčešća pitanja o brzini sajta

Pragovi metrika prema Google web.dev dokumentaciji za Core Web Vitals; uštede su tipične vrednosti iz naše prakse i zavise od polaznog stanja sajta. Poslednja provera: septembar 2026.