Brzina i mobilna verzija sajta ustanove: šta testirati pre objave

Građanin sajt ustanove najčešće otvara sa telefona, u trenutku kad mu nešto treba odmah: radno vreme šaltera, broj za prijavu kvara, obrazac, stanje računa. Ako stranica na mobilnoj vezi učitava osam sekundi, a PDF od 20 MB se ne otvara, sajt je za njega nedostupan, bez obzira na to koliko je dizajn lep na monitoru u kancelariji. Ovaj tekst daje projektnom timu ustanove listu testova pre objave: šta građani rade i pod kojim uslovima, koje metrike meriti i na čemu, kako testirati forme, dokumente i pretragu na stvarnim uređajima, i kako napraviti plan poboljšanja i praćenja posle objave, sa ciljnim vrednostima koje se mogu upisati u specifikaciju i test listu primopredaje.

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

Zašto mobilni korisnik ne može da čeka

Sajt firme spor korisnik napusti i ode konkurenciji; sajt ustanove nema konkurenciju, pa spor sajt znači poziv, dolazak na šalter ili odustajanje od prava. Brzina je ovde pitanje pristupačnosti usluge, ne marketinga.

Najčešći zadaci građana

Pre testa tim popisuje šta građani zaista rade na sajtu; izvori su statistika starog sajta (ako postoji), pitanja na telefonu i šalteru, i zdrav razum. Tipična lista za ustanovu ili javno preduzeće: radno vreme i kontakt (šalter, dežurna služba, e-pošta prave službe); prijava problema (kvar, reklamacija) sa obrascem ili brojem telefona; obrazac ili dokument za preuzimanje i uputstvo šta uz njega treba; stanje računa ili link ka portalu; obaveštenja o prekidima i radovima u svojoj ulici; konkurs ili oglas sa rokom; pretraga dokumenta po nazivu; usluga: šta treba, gde, koliko traje. Svaki zadatak dobija merljiv cilj: „sa početne strane do broja dežurne službe za jedan dodir“, „obrazac se preuzima i otvara na telefonu“, „prijava kvara se šalje za manje od dva minuta bez registracije“. Lista zadataka je osnova strukture sajta (šta ide na početnu i u meni) i test liste primopredaje; kako se zadaci prevode u strukturu i obavezne funkcije, u tekstu šta treba da sadrži sajt javnog preduzeća.

Sporije veze i stariji uređaji

Sajt ustanove koriste svi, uključujući ljude sa telefonom od pre pet godina, na pretplati sa ograničenim prenosom podataka, u selu sa slabim signalom ili u zgradi ustanove gde mobilni internet jedva radi. Zato se testira pod uslovima koji su gori od prosečnih: veza: simulacija spore mobilne veze (u alatima za programere: „Slow 4G“ ili „3G“, sa kašnjenjem od 150–400 ms); uređaj: bar jedan stvarni telefon srednje ili niže klase star nekoliko godina, ne najnoviji model iz kancelarije; ekran: širina 360 px, sa uvećanim tekstom u podešavanjima telefona (mnogi stariji korisnici ga koriste), sa jednom rukom (dugmad i linkovi dovoljno veliki i razmaknuti, najmanje 44×44 px); okolnosti: sunce na ekranu (kontrast), bez zvuka, prekinuta veza na pola učitavanja (da li se vidi bar tekst). Cilj nije da sajt bude savršen na slabim uređajima, već da ključni zadaci rade: tekst se vidi pre slika, kontakt i dugmad rade i kad skripte kasne, obrazac se može popuniti, dokument se može otvoriti. Pristupačnost i brzina se ovde preklapaju: sajt koji radi tastaturom i čitačem ekrana obično je i lakši, jer nema suvišnih skripti; više u WCAG vodiču za organizacije.

Metrike i praktični testovi

Brojke omogućavaju da se brzina upiše u specifikaciju i proveri pri primopredaji; praktični testovi otkrivaju ono što brojke ne vide (dugme koje se ne može pritisnuti, PDF koji se ne otvara).

Core Web Vitals i stvarni uređaji

Tri metrike koje Google koristi i koje dobro opisuju iskustvo: LCP (Largest Contentful Paint: za koliko se prikaže najveći element, obično naslov ili slika; cilj ispod 2,5 s), INP (Interaction to Next Paint: koliko sajt kasni posle dodira; cilj ispod 200 ms), CLS (Cumulative Layout Shift: koliko se sadržaj pomera dok se učitava, ono što pomeri dugme baš kad ga pritisnete; cilj ispod 0,1). Kako meriti: laboratorijski (PageSpeed Insights ili Lighthouse, mobilni profil), po jedan test za svaki šablon (početna, usluga, dokumenti, vest, kontakt, pretraga), pre objave na probnom serveru i posle objave na živom; i na terenu (podaci stvarnih korisnika u Search Console-u, izveštaj Core Web Vitals, dostupni posle 28 dana i dovoljno posetilaca). Laboratorijski test je za primopredaju; terenski je za praćenje. Ciljne vrednosti u specifikaciji: „LCP < 2,5 s, INP < 200 ms, CLS < 0,1 na mobilnom profilu, za svaki od šest šablona, na probnom serveru pre objave“, uz ukupnu težinu stranice (cilj ispod 1 MB za tekstualne stranice) i broj zahteva. Stvarni uređaji su obavezni deo testa, jer laboratorija ne vidi: da li se dugmad mogu pritisnuti prstom, da li se meni otvara, da li tastatura telefona prekriva polje forme, da li se PDF otvara u pregledaču ili traži aplikaciju, kako sajt izgleda sa uvećanim tekstom. Minimum: jedan Android srednje klase i jedan iPhone, oba sa sporom vezom, plus tablet ako ustanova ima šaltere sa tabletima.

Forme, dokumenti i pretraga

Forme na telefonu: svako polje ima oznaku koja ostaje vidljiva; tip polja odgovara sadržaju (telefon otvara numeričku tastaturu, e-pošta tastaturu sa @); polja dovoljno visoka za prst; greške se prikazuju uz polje, jasnim jezikom, bez brisanja unetog; prilog (fotografija kvara) se dodaje iz kamere ili galerije i ograničava na razumnu veličinu uz automatsko smanjenje; posle slanja jasna potvrda sa brojem prijave i šta sledi; forma radi bez registracije; zaštita od zloupotrebe ne blokira stvarne ljude (bez slagalica koje niko ne može da reši). Test: popuniti svaku formu na telefonu, sa sporom vezom, sa greškom pa ispravkom, i proveriti da je stigla gde treba. Dokumenti: PDF se otvara u pregledaču telefona bez dodatne aplikacije; veličina fajla se vidi pre preuzimanja; dokumenti od više desetina MB (skenirani izveštaji) se optimizuju (kompresija, prepoznavanje teksta) ili dele; kad je moguće, ključne informacije iz dokumenta (rok, uslovi, iznos) stoje i kao tekst na stranici, jer se tekst učitava odmah, a PDF ne; naslov dokumenta, datum i veličina vidljivi u listi. Test: otvoriti pet najvećih dokumenata na telefonu na sporoj vezi. Pretraga: vidljiva na svakoj strani (na telefonu ikona koja otvara polje), radi po naslovu i sadržaju dokumenata, toleriše ćirilicu i latinicu i greške u kucanju (ц/c, ч/č), rezultati pokazuju vrstu i datum, i vraćaju se za manje od sekunde. Test: deset stvarnih upita koje građani kucaju (naziv obrasca, „radno vreme“, „reklamacija“, naziv ulice), na oba pisma.

Plan poboljšanja

Kad test pokaže gde sajt pada, poboljšanja se rade po redu uticaja: prvo ono što najviše usporava, obično slike i skripte, pa fontovi i server. Većina sajtova ustanova dostiže ciljeve bez promene dizajna.

Slike, fontovi i skripte

Slike su najčešći krivac: fotografija zgrade od 6 MB na početnoj strani. Rešenje: moderni format (WebP ili AVIF), dimenzije prilagođene prikazu (ne 4000 px za mesto od 800 px), više veličina za različite ekrane (WordPress to radi ako je tema podešena), odloženo učitavanje slika ispod prve strane, i pravilo za urednike (sajt automatski smanjuje slike pri unosu, pa urednik ne mora da zna ništa o tome). Za ustanove je česta i greška da se logotipi i grbovi drže kao velike PNG slike umesto SVG. Skripte: svaki dodatak i ugrađeni servis (mape, video, društvene mreže, slajderi, animacije) dodaje kilobajte i kašnjenje; pravilo je minimalan broj dodataka, ugrađeni sadržaj tek na klik („klikni da učitaš“, što rešava i pitanje pristanka), bez slajdera na početnoj (niko ih ne gleda, a koštaju), skripte za analitiku i pristanak lake i odložene. Fontovi: najviše dva fonta, lokalno hostovani (ne sa spoljnih servera: brže i bolje za privatnost), sa podešavanjem da se tekst prikaže odmah sistemskim fontom dok se pravi ne učita; ćirilični podskup uključen. Server i keširanje: keš stranica na serveru, kompresija (Brotli/Gzip), HTTP/2 ili HTTP/3, kеš u pregledaču za statične fajlove, po potrebi CDN; hosting koji nije preopterećen (odziv servera ispod 200–400 ms). Opšti redosled i alati isti su kao za bilo koji sajt, sa detaljima u tekstu optimizacija brzine sajta. Dokumenti: PDF se pri unosu optimizuje (kompresija, tekstualni sloj), veličina se prikazuje; skenirani izveštaji se obrađuju pre objave. Sve ovo se ugrađuje u sajt jednom, a onda se održava: nova tema ili dodatak može sve da pokvari.

Praćenje posle objave

Sajt je najbrži na dan objave; posle toga urednici dodaju slike od 5 MB, neko instalira dodatak, dokumenata je sve više. Zato brzina ulazi u redovno praćenje: Search Console, izveštaj Core Web Vitals (terenski podaci stvarnih korisnika, po grupama stranica) i izveštaj o mobilnoj upotrebljivosti, pregled mesečno; nezavisan nadzor dostupnosti i vremena odziva (spoljni servis koji svakih par minuta meri i javlja), jer spor server ne vidi niko iznutra; laboratorijski test šest šablona kvartalno i posle svake veće promene (nova tema, dodatak, redizajn); provera unosa: mesečno pregled najvećih slika i dokumenata dodatih u prethodnom periodu, sa pravilom i obukom za urednike; test na stvarnom telefonu pet ključnih zadataka kvartalno, isti test kao pre objave. Rezultati idu u mesečni izveštaj o održavanju, sa brojkama uz polazne vrednosti iz primopredaje; pad ispod cilja je zadatak za izvođača u okviru održavanja, ne novi projekat. Ovo je jedan od razloga zašto sajt ustanove mora da ima ugovoreno održavanje sa jasnim sadržajem; šta ono obuhvata i kako izgleda izveštaj, na stranici održavanje sajtova, a kako to organizujemo za ustanove, sa zapisnicima i proverama, na stranici rešenja za javni sektor.

Najčešća pitanja o brzini i mobilnoj verziji sajta ustanove

Ciljne vrednosti su Googleovi pragovi za Core Web Vitals i uobičajena praksa; primenjuju se na mobilni profil. Testovi su oni koje koristimo pri primopredaji sajtova ustanova. Poslednja provera sadržaja: septembar 2026.