Šest čestih grešaka u optimizaciji brzine koje viđamo na agencijskim projektima

Rad na brzini sajta obično počinje kada sajt „deluje sporo”, kada Lighthouse skor padne ili kada oglašavanje postane skuplje jer konverzije počnu da opadaju. I to je potpuno razumljivo. Ali ono što često viđamo nakon agencijskih predaja projekata nije nedostatak truda, već trud uložen na pogrešna mesta.

U nastavku izdvajamo šest grešaka koje se stalno ponavljaju, zašto prave problem i šta radimo drugačije kada radimo ozbiljnu optimizaciju brzine.

Zašto je brzina više od jednog skora

Brz sajt nije samo lep UX detalj. To je direktan poslovni faktor:

• Brže stranice uglavnom znače više završenih kupovina i poslatih upita.
• Manje pomeranja elemenata i kašnjenja smanjuje frustraciju, pogrešne klikove i odustajanja.
• Stabilniji sajt pomaže i SEO performansama i plaćenim landing stranicama.
• Bolje iskustvo smanjuje i broj prijava tipa „sajt ne radi”, iako je problem zapravo u sporom učitavanju.

Ali postoji jedna važna stvar: problemi sa brzinom retko dolaze od jedne velike greške. Najčešće nastaju iz nekoliko obrazaca koji se ponavljaju i vremenom se nagomilaju.

Greška 1: Jurnjava za Lighthouse skorom umesto za stvarnim korisničkim iskustvom

Lighthouse je koristan alat. Problem nastaje kada u agencijskim projektima postane cilj, umesto smernica.

Mnogi projekti ga tretiraju kao završni ispit: „Imamo 95, znači završili smo.” Ali korisnici ne koriste vaš sajt u laboratorijskim uslovima.

Suština je jednostavna: Lighthouse je laboratorijski test. Vaši korisnici nisu u laboratoriji.

Oni su na mobilnim telefonima, na slabijoj mreži, sa pet otvorenih tabova. Klikću brzo. Pokušavaju da pronađu proizvod, filtriraju listu, dodaju u korpu i završe kupovinu. Stranica može da ima odličan Lighthouse skor, a da i dalje deluje sporo, nezgrapno ili „lepljivo” u stvarnom korišćenju.

Kako ova greška izgleda u praksi? Optimizuje se samo početna strana, dok kategorije, proizvodne stranice, korpa i checkout ostaju teški. Ili se popravi samo ono na šta alat upozorava, dok se zanemari ono što korisnici zaista rade. Ili se testira na brzom laptopu i zaključi da je posao završen.

Najveća greška je praviti izmene koje popravljaju skor, ali ne popravljaju konverzije — ili čak pogoršaju UX.

Šta radimo umesto toga:

• Krećemo od stvarnih korisničkih putanja: početna → kategorija → proizvod → korpa → checkout.
• Gledamo field data kada je dostupan i upoređujemo ga sa lab rezultatima.
• Testiramo na mobilnim uređajima srednje klase i realnijim mrežnim uslovima.
• Definišemo šta „dobro” znači za biznis: bounce rate, konverzije, prihod po poseti.

Na primer: često je mnogo važnije da proizvodne stranice deluju trenutno, stabilno i lako za korišćenje nego da se iz početne strane izvuče još tri poena u izveštaju.

Ako ste trenutno u ovoj fazi, naš proces optimizacije brzine sajta napravljen je tako da „brzo” poveže sa konkretnim rezultatima, a ne samo sa brojevima.

Greška 2: Optimizacija slika se završava sa „kompresovali smo ih”

Slike su najčešće najveći deo ukupne težine modernog sajta. Ali kompresija je samo prvi korak.

Često viđamo hero slike od 4000px koje se na sajtu prikazuju u širini od 900px. Browser i dalje preuzima ceo fajl od 4000px, što troši vreme, protok, memoriju i procesor.

Takođe često viđamo zastarele formate, na primer JPEG svuda, samo zato što je to nekada bio podrazumevani izbor. Moderni formati kao što su WebP ili AVIF često mogu da pruže isti kvalitet uz znatno manju veličinu fajla. Manji fajl znači brže učitavanje.

Još jedan čest problem: isti URL slike koristi se za sve korisnike, bez responzivnih veličina. To znači da mobilni korisnici preuzimaju desktop slike. A to značajno usporava sajt. Mobilni ekrani su manji, ali su mobilne mreže često sporije. To je najgora kombinacija: veliki fajlovi na sporoj vezi.

Zato treba koristiti responzivne slike.

Lazy loading je još jedan važan alat u optimizaciji brzine. On odlaže učitavanje slika dok browser ne proceni da se približavaju vidljivom delu stranice. Ali ako se lazy-loaduju pogrešne slike, posebno one koje korisnik treba odmah da vidi, najvažniji vizuali kasne. Stranica tada deluje prazno ili kao da se još uvek učitava, čak i kada je layout već prikazan.

Bolji pristup je jednostavan, ali veoma efikasan:

• Koristiti moderne formate kada je moguće, kao što su WebP i AVIF.
• Isporučivati responzivne veličine, tako da svaki uređaj preuzme ono što mu stvarno treba.
• Lazy-loadovati slike ispod prvog ekrana, ali ne i glavnu hero ili product sliku.
• Pažljivo preloadovati zaista kritične vizuale, ali ne sve redom.

Ovo je često jedna od najbržih pobeda u optimizaciji brzine, jer smanjuje potrošnju protoka i istovremeno poboljšava subjektivni osećaj brzine.

Greška 3: „Imamo keširanje” — ali ne ono koje stvarno rešava problem

Keširanje se često podešava kao checkbox stavka: „CDN uključen, cache uključen, završeno.” Ali keširanje ima više slojeva, a pogrešna postavka može da napravi čudne bugove ili da ne donese gotovo nikakvu korist.

Često nailazimo na HTML koji nije keširan, pa svaki zahtev ide direktno na server. Svaki put kada neko otvori stranicu, server mora ponovo da je generiše: pokrene backend kod, upite ka bazi i složi HTML. To povećava opterećenje servera, a pri skokovima u saobraćaju problem može brzo da postane mnogo veći.

Drugi čest slučaj su loše keširani statički fajlovi: slike, CSS, JavaScript i fontovi. Kratki TTL-ovi i česti cache miss-ovi znače da se browseru ili CDN-u govori da fajlove čuvaju kratko ili ih često ponovo preuzimaju. Statički fajlovi obično treba da imaju duži vek keširanja, često nedeljama ili mesecima, pod uslovom da postoji dobra cache-busting strategija.

Cache-busting je druga strana iste priče. Ako ažurirate CSS ili JS, a nemate cache-busting, neki korisnici će i dalje imati staru verziju fajlova u cache-u. Sajt tada može da izgleda polomljeno dok korisnik ne osveži stranicu. Versioned filenames ili query stringovi koji se menjaju kada se fajl promeni rešavaju ovaj problem.

Tip:
Ako posle deploy-a dobijate nasumične prijave da je „sajt polomljen” i ne možete da se oslonite na keširanje bez straha, verovatno vam treba bolji cache-busting.

Kod e-commerce sajtova posebno je važno razlikovati ponašanje prijavljenih i neprijavljenih korisnika. Keširanje ne sme tretirati sve posetioce isto ako prijavljeni korisnici vide personalizovan sadržaj: nalog, korpu, cene, loyalty nivoe ili preporuke. Najgori scenario je da jedan korisnik vidi delove korpe ili naloga drugog korisnika. Da bi se to izbeglo, timovi često „za svaki slučaj” potpuno isključe keširanje — i izgube performanse.

Još jedna česta greška je kada je CDN uključen, ali se veliki fajlovi i dalje serviraju sa origin servera. CDN je globalna mreža koja isporučuje keširane fajlove bliže korisnicima. Ako je CDN uključen, a veliki fajlovi i dalje dolaze sa glavnog servera, samo trošite resurse bez pravog efekta.

Pouzdan caching stack obično uključuje:

• Browser keširanje statičkih fajlova, uz dugi TTL i verzionisane nazive fajlova.
• CDN keširanje za globalnu isporuku slika, CSS-a, JS-a i fontova.
• Server-side keširanje tamo gde ima smisla, posebno kod stranica koje mnogo zavise od baze.
• Jasna pravila za dinamične stranice kao što su korpa, checkout i nalog.

Tu DevOps i hosting često prave razliku između „malo je brže” i „zašto ovo nismo uradili ranije?”

Greška 4: Previše third-party skripti, i to prerano

Sasvim je normalno da sajt ima analitiku, ad pixele, heatmap alate, chat widget, A/B testing, review widgete, recommendation engine, eksterni font ili icon biblioteku.

Greška nije u tome što ih koristite. Greška je kada se sve te skripte učitavaju odmah, na svakoj stranici i za svakog korisnika.

To usporava prvo učitavanje, posebno na mobilnim uređajima. A upravo taj prvi utisak najviše znači.

Dugmad mogu delovati neodazivno zbog blokiranja main thread-a. Main thread je deo browsera koji se bavi ključnim stvarima na stranici: prikazom sadržaja, izvršavanjem JavaScript-a, klikovima, tapovima, scrollovanjem, unosom teksta, animacijama i UI izmenama. Kada se preoptereti, browser ne može dovoljno brzo da reaguje na korisničke akcije.

Third-party skripte mogu izazvati i layout shift. To se dešava kada je stranica već vidljiva, a zatim se nešto dodatno učita i pomeri sadržaj. Korisnik čita ili se sprema da klikne, a onda tekst skoči nadole ili dugme promeni poziciju. Taj „nemiran” osećaj pri učitavanju je upravo layout shift.

Na primer: chat widget učita veliki bundle, zatim ubaci bubble i pomeri elemente na stranici.

Third-party skripte prave i dodatne mrežne zahteve koji se takmiče sa vašim stvarnim sadržajem. To je problem jer stranica ima ograničen „download budžet” baš u trenutku kada je najvažnije da se učita brzo. Važan sadržaj zbog toga stiže kasnije nego što bi trebalo.

Šta najčešće preporučujemo:

• Proveriti sve third-party tagove i ukloniti duplikate.
• Učitavati skripte samo na stranicama gde su stvarno potrebne.
• Odložiti nekritične skripte dok korisnik ne ostvari interakciju ili ne da pristanak.
• Zameniti teške widgete lakšim alternativama kada god je moguće.

Ako sajt „na papiru treba da bude brz”, ali i dalje deluje tromo, third-party skripte su vrlo čest krivac.

Greška 5: Nema podele po rutama ili tipovima stranica — ceo sajt se šalje svakoj stranici

Mnogi agencijski buildovi izgledaju uredno u repozitorijumu, ali korisniku isporučuju previše koda u runtime-u.

Na primer, ceo sajt ima jedan veliki JavaScript bundle. Sav JavaScript se spakuje u jedan fajl i učitava na svakoj stranici, čak i ako toj stranici treba samo mali deo tog koda.

Zašto je to loše? Veliki fajlovi se sporije preuzimaju. Browser mora da ih parsira i izvrši pre nego što stranica postane stvarno interaktivna. Mobilni uređaji to najviše osećaju.

Rešenje je da se učitava samo JavaScript koji je toj stranici potreban.

Na primer: checkout stranica ne treba da učitava kod za slider sa početne strane.

Sličan problem postoji i sa CSS-om koji uključuje sve komponente, iako stranica koristi samo pet. CSS fajl tada sadrži stilove za ceo sajt: svaki widget, svaku sekciju, svaki tip stranice. Čak i kada konkretna stranica koristi samo nekoliko elemenata. To usporava inicijalni render, jer browser mora da preuzme i obradi CSS pre nego što pravilno prikaže stranicu. Uz to se često krije i neiskorišćen CSS koji vremenom samo raste.

Rešenje je imati mali critical CSS za deo stranice koji se vidi odmah pri učitavanju. Ostatak se učitava kasnije ili po template-u / tipu stranice. Takođe je važno redovno uklanjati CSS koji se više ne koristi.

Code splitting je još jedna važna tema. Ako nema podele koda po rutama ili templejtima, sajt učitava isti JS za sve stranice. Korisnici tako plaćaju cenu koda koji na toj stranici nikada neće koristiti.

Kako izgleda dobar pristup?
Kod se deli po tipu stranice: product page JS, category filtering JS, checkout JS, blog page JS. Svaka stranica učitava samo ono što joj treba.

Još jedan čest problem su animacije i slideri koji se izvršavaju na stranicama gde uopšte nisu potrebni. Skripte za karusele i animacije, koje su deo bundle-a, učitavaju se i pokreću na celom sajtu, čak i tamo gde ti elementi ne postoje. To znači dodatni JavaScript i CPU posao bez ikakve koristi za korisnika. Može izazvati seckanje pri scrollovanju i čudne bugove, jer skripte pokušavaju da inicijalizuju elemente kojih nema.

Takve skripte treba učitavati samo na stranicama koje ih zaista koriste, ili ih inicijalizovati tek kada element postoji.

Bolji obrasci, bez nepotrebnog komplikovanja projekta:

• Podeliti kod po tipu stranice: home, category, product, checkout.
• Inline-ovati samo minimalni CSS potreban za layout iznad prvog ekrana.
• Odložiti nekritični JavaScript i izbegavati teške biblioteke kada jednostavan kod može da reši problem.

Ovo se direktno preklapa sa development radom, jer mnogi problemi sa brzinom nisu „podešavanja”. To su arhitektonske odluke.

Greška 6: Fontovi koji blokiraju prikaz i previše font fajlova

Fontovi su važni. Ali način na koji se učitavaju može postati ozbiljan problem.

Fontovi mogu blokirati prikaz kada browser čeka da se custom font fajlovi učitaju pre nego što prikaže tekst. Korisnik tada vidi kratak trenutak nevidljivog teksta, ili se tekst pojavi pa „skoči” kada se font zameni.

Bolje je da se tekst prikaže odmah, uz minimalno ili nikakvo pomeranje. To se postiže tako što se rano učitava samo najvažniji font, dok se ostali odlažu. Takođe pomaže swap strategija i manji broj težina i font fajlova.

Šta obično preporučujemo: 

• Koristiti pametnije učitavanje fontova.
• Smanjiti broj font weight-ova.
• Ne učitavati font fajlove koji se ne koriste.

Prioritizovati samo ono što je zaista važno za prvi prikaz stranice.

Kratka checklist-a za sledeći projekat

Ako želite brzu proveru pre optimizacije, postavite sebi ova pitanja:

• Da li merite brzinu kroz celu kupovnu putanju, a ne samo na jednoj stranici?
• Da li su slike responzivne i pravilno prioritizovane?
• Da li imate keširanje na nivou browsera, CDN-a i servera tamo gde je potrebno?
• Da li ste proverili third-party skripte i odložili one koje nisu kritične?
• Da li svaka stranica učitava samo CSS i JavaScript koji joj stvarno trebaju?

Ako na većinu ovih pitanja ne možete sigurno da odgovorite sa „da”, verovatno postoji još mnogo prostora za realno ubrzanje sajta.

Želite da brzo pronađemo usko grlo?

Ako želite jasan plan, a ne neodređenu listu tipa „poboljšati performanse”, pogledajte našu uslugu optimizacije brzine sajta i zakažite performance audit. Pronaći ćemo šta usporava vaš sajt, šta treba prvo popraviti i koje izmene mogu najviše da utiču na konverzije.

Ako bude potreban dublji rad, povezaćemo ga sa developmentom, DevOps-om i hostingom.

Ne dozvolite da vaš sajt sam sebi usporava rast

Optimizacija brzine nije jurnjava za još jednim poenom u izveštaju. Poenta je da se ukloni trenje, kako bi se korisnici, a sa njima i prihod, kretali lakše.

Ako vaš sajt pokušava da trči sa pet slojeva skripti, prevelikim slikama i „checkbox” keširanjem, vreme je za promenu garderobe.

Zakažite audit e-commerce sajta →FAQ

1. Koliko third-party skripti je „previše”?

Ne postoji magičan broj, ali ako imate više tracking alata koji rade istu stvar, ili skripte koje se učitavaju na svakoj stranici „za svaki slučaj”, verovatno ih je previše. Dobro pravilo je: zadržite samo skripte koje jasno utiču na prihod ili donošenje odluka, a ostale učitavajte samo tamo gde su zaista potrebne.

2. Da li treba da uklonimo skripte ili samo da ih odložimo?

Krenite od uklanjanja duplikata i svega što niko stvarno ne koristi. Nakon toga odložite nekritične skripte, kao što su heatmap alati, chat ili A/B testing, dok se glavni sadržaj ne učita ili dok korisnik ne da pristanak. Samo zaista ključne skripte treba da se učitavaju rano.

3. Koji problemi najbrže daju vidljivo ubrzanje?

Najčešće slike i third-party skripte. Kada se slike isporučuju u pravim dimenzijama i modernim formatima, a tagovi očiste i pravilno odlože, vreme učitavanja često se brzo smanji bez diranja bekenda.

4. Da li caching i CDN mogu da reše sve?

Mogu mnogo da pomognu, ali neće sami rešiti teške stranice. Ako sajt isporučuje ogromne JS bundle-ove, blokira render fontovima ili prerano učitava previše skripti, keširanje ne može da ukloni taj posao. Može samo brže da ga isporuči.