Performanse weba su važne (i kako ih poboljšati)

Zvonimir Dimovski

Možemo razgovarati o UX problemima web stranica, uporabi A/B testova kako bismo odredili je li bolje pozicionirati gumb s lijeve ili desne strane ili o tome je li bolje upotrijebiti prikladne sheme boja kako bi se smanjilo kognitivno opterećenje i time povećala stopa konverzije posjetitelja webshopa. Međutim, glavna stvar koju nedvojbeno znamo jest da zbog loših web performansi kompanije gube svoje kupce.

Amazon je proveo istraživanje u kojem su namjerno usporili brzinu učitavanja stranica i dobili su zanimljive rezultate: svakih 100 ms kašnjenja reflektiralo se na pad prodaje od 1%. Također, i Google je proveo slično istraživanje iz kojeg su zaključili da će 53% korisnika napustiti web stranicu ako joj treba dulje od 3 sekunde za učitavanje!

Zbog čega se web stranice sporo učitavaju?

Web stranica je skup dokumenata i resursa (skripte, stilovi, slike itd.) koje je potrebno preuzeti kako bi preglednici prikazali nešto na zaslonu. Kada se korisnik želi spojiti na određenu stranicu, u pozadini se odvijaju razni procesi, a to pak produljuje vrijeme učitavanja: mapiranje alfanumeričkih naziva u IP adresu (engl. određeno DNS lookup), protokol kontrole prijenosa / komunikacijska usluga uspostave konekcije (engl. TCP handshake), TLS/SSL uspostava konekcije. Drugi nepovoljni faktor koji utječe na brzinu učitavanja je udaljenost između zatražene lokacije (lokacija servera stranice) i lokacije korisnika. Primjerice, ako korisnik iz središnje Europe (npr. u Zagrebu, Hrvatska) traži stranicu smještenu, na primjer, u New Yorku, udaljenost između te dvije lokacije je oko 6900 km. Ako znamo udaljenost između dvije lokacije te znamo da paketi mrežnih podataka putuju mrežom pri brzini sličnoj brzini svjetlosti (oko 200.000 km/s), možemo lako izračunati razdoblje čekanja. U prethodnom primjeru, čekanje bi bilo 69 ms (34,5 ms do New Yorka i još 34,5 ms natrag do Zagreba).

Mi programeri nemamo mnogo utjecaja na spomenute procese ili fizička ograničenja, ali možemo upotrijebiti razne metode i tehnike koje mogu poboljšati brzinu učitavanja tako što ćemo drukčije pristupiti problemima čekanja. Sve ove tehnike funkcioniraju preventivno, za uspostavu veze ili preuzimanje resursa odmah, a korištenje kasnije kada vam zatreba.

1. Preconnect

Kao što je već spomenuto, da bi preglednik uspostavio vezu s stranicom, određene radnje moraju biti izvršene, a to zahtijeva određeno vrijeme. Kako bi se smanjilo vrijeme čekanja povrata informacija, možemo upotrijebiti opciju preconnect. Ono što preconnect odmah čini jest da rješava process rezolucije, provodi komunikacijsku uslugu uspostave konekcije (engl. TCP handshake) i postavlja TLS za podatke koji se mogu upotrebljavati za trenutnu navigaciju.

Pogledajmo kako preconnect funkcionira i kako ga najbolje iskoristiti.

Zamislite da želite upotrijebiti Google font u svom projektu. Uobičajeni način za uključiti Google fontove je:

Kako bismo svugdje primijenili ovaj prekrasan font Girassol, moramo prilagoditi CSS:

Sada napravimo test da vidimo što će se dogoditi:

Bez preconnect-a

 

Iz ovog vodopadnog grafikona možemo vidjeti taj proces.

  • 1. korak. Dohvaćanje HTML dokumenta (mapiranje alfanumeričkih naziva u IP adresu, inicijalna konekcija, preuzimanje dokumenata)
     
  • 2. i 3. korak. Učitavanje resursa (popisi stilova) definiranih u HTML zaglavlju koje je započeto u isto vrijeme; međutim, popis stilova za Googleove fontove ponovno započinje s mapiranjem alfanumeričkih naziva u IP adresu, Pokretanje konekcije itd.
     
  • 4. korak. Nakon što su 2. i 3. korak potpuno dovršeni, započinje postupak preuzimanja web fonta (woff datoteka). Taj postupak ponovno pokreće procese mapiranja alfanumeričkih naziva u IP adresu, Pokretanje konekcije, SSL pregovaranja itd.

Pogledajmo što se događa kada primijenimo preconnect na ovaj kod. Prilično je jednostavno primijeniti preconnect; trebamo još jedan red koda u HTML dokumentu.

Što je vidljivo iz ovog koda je da radimo preconnect na URL https://fonts.gstatic.com. Ova lokacija jest mjesto gdje se nalazi sam Google font (.woff datoteka). Ako se pitate zašto se koristi crossorigin, to je zbog toga što su fontovi podložni istoj politici crossorigina, a specifikacija lica fonta zahtijeva preuzimanje u anonimnom načinu CORS-a. Više o ovoj temi pročitajte na: https://webmasters.stackexchange.com/questions/89466/when-should-i-use-the-crossorigin-attribute-on-a-preconnect-link   

Sa preconnectom

 

Ovaj primjer prikazuje kako je uporaba preconnect-a na Google fontove već riješila pitanje DNS-a, spajanja i TLS upostave konekcije prije nego što su se popisi stilova (CSS) potpuno preuzeli i evaluirali. Međutim, samo preuzimanje datoteke fontova počinje tek nakon što se učitaju popisi stilova.

Vrijeme potrebno za potpuno učitanu traženu stranicu:

  • Bez preconnect-a – 0.499s
  • S preconnectom0.397s

Povećanje brzine je očito. Možda ćete misliti da 100 ms nije tako značajno poboljšanje, no uzmite u obzir da je ovo osnovna HTML datoteka sa samo nekoliko redaka koda. Zamislite da se radi o velikom projektu koji zahtijeva uporabu desetaka resursa.

Implementacija u sklopu stvarnh stranica ili aplikacija

Amazon upotrebljava preconnect za opciju autocomplete-a (kod pretraživanja) te tako postiže munjevitu brzinu pretraživanja. Zapravo, Amazonova aplikacija za pretraživanje je drukčija aplikacija koja “obitava” na drugom mrežnom mjestu – https://completion.amazon.com. Pregledavanjem Amazonove stranice možemo uočiti:

Podrška preglednika

Na umu valja imati i podršku preglednika. U ovom slučaju imamo solidnu podršku preglednika s 89,71 % obuhvaćenosti preglednika, uključujući Chrome, Firefox, Operu i Edge. Međutim, nije moguće iskoristiti prednosti preconnect-a u IE-u, no je li uopće koga briga za IE u 2020. godini? :) 

preconnect

 

2. DNS-prefetch

DNS-prefetch slično je preconnect-u, uz neke ključne razlike. DNS-prefetch izvršava samo mapiranje alfanumeričkih naziva u IP adresu (DNS lookup), bez otvaranja TCP konekcije ili TLS uspostave konekcije. DNS-prefetch bi se vjerojatno rabio u situacijama gdje će resursi možda potrebni u budućnosti, ali nismo sigurni.

Dobro korištenje DNS-prefetch-a bi, primjerice, bilo ako imate stranicu koja poziva/dohvaća niz JS datoteka iz CDN-a, a koje će se možda upotrijebiti kasnije za neku funkciju stranice. Stoga, na početku učitavanja možete odrediti vezu DNS-prefetcha i CDN-a kako biste riješili mapiranje alfa-numeričkih naziva u IP adresu računala (DNS lookup), a resursi bi se kasnije učitali i preuzeli/upotrijebili bržim tempom.

Mogli biste se zapitati zašto uopće upotrijebiti DNS-prefetch umjesto preconnect-a. Pa, odgovor ima više konotacija. Jedan aspekt takvog izbora je svakako dobra praksa razvoja software-a. Preconnect je “teža” radnja nego DNS-prefetch, stoga njegova uporaba za dobivanje resursa za koje ne znamo hoće li biti potrebni ili ne nije naročito dobra praksa.

Druga je konotacija iz poslovne perspektive. Vratimo se malo na primjer Amazona. Zasigurno da bi Amazon mogao upotrebljavati DNS-prefetch umjesto preconnect-a za svoju funkciju autocomplete-a jer zapravo ne znaju hoće li korisnik/posjetitelj upotrijebiti mogućnost pretraživanja ili ne. No, ono što im je istraživanje pokazalo jest da većina korisnika tijekom posjeta stranice doista koristi pretraživanje. Stoga, bilo bi mudro korisnicima pružiti rezultate pretraživanja što je brže moguće.

Podrška preglednika

Postotak podrške preglednika općenito je niži od preconnect-a. Međutim, svi glavni preglednici podržavaju DNS-prefetch, uključujući IE.

browser stupport

 

3. Prefetch

Sa prefetch možete preuzeti resurs (skriptu, slike itd.) na način niskog prioriteta i koristiti ga u kasnijoj / budućoj navigaciji. Imajte na umu da se preuzeti resursi ne izvršavaju odmah, već se pohranjuju u predmemoriju preglednika.

Programeri trebaju biti pažljivi kako i kada će upotrijebiti prefetch jer prerano stavljanje prefetch-a na resurse koji možda nikada neće biti upotrebljeni može usporiti trenutnu stranicu koju korisnik već gleda.

Implementacija prefetch-a jednako je jednostavna kao ranije spomenute metode

uz jednu iznimku. Sada imamo i atribut “as” i koristimo ga za definiranje vrste značajki (asset type). Moramo ga definirati kako bismo dali prednost zahtjevima preglednika, tj. vrstu značajke “stylesheet” treba preuzeti prije vrste značajke “image”.

Slučajevi uporabe

Ako korisnik klikne na košaricu na web trgovini možemo unaprijed predvidjeti da će korisnik nastaviti s postupkom kupnje, tako da možemo unaprijed dohvati resurse koji bi se koristili pri procesu kupnje kako bi korisniku pružili bolje korisničko iskustvo. Nadalje, eBay je implementirao prefetch na prvih pet rezultata kako bi ubrzao učitavanje stranica u budućnosti te je svjedočio pozitivnom utjecaju na stope konverzije

Podrška preglednika

Prefetch ima solidnu podršku preglednika, međutim nije podržan na Safariju i iOS Safariju. Glavni razlog zašto bismo upotrijebili sve spomenute metode ubrzavanja jest da smanjimo vrijeme čekanja i ubrzamo postupak učitavanja web stranice/aplikacije. Problem je još očitiji na platformama za mobitele i 3G vezama gdje čekanje može biti toliko dugo da značajno utječe na odziv stranice. Štoviše, to je glavni razlog zašto bi programeri mogli odustati od potpunog preuzimanja unaprijed zbog trenutačne podrške iOS Safarija. Dobra stvar je što možemo kombinirati različite metode, tako da ako preglednik ne podržava jednu metodu, možemo upotrijebiti drugu koja jest.

bla

 

4. Preload

Zadnje, ali ne manje važno, preload je možda najzanimljivija metoda od svih. Preload je nešto drukčiji od prefetch-a u smislu da preload prisiljava preglednik da preuzme resurs za trenutnu stranicu, nešto poput ranog prefetch-a.

Evo praktičnog primjera. Ako Stranica A započne zahtjev za preddohvaćanje resursa koji će biti upotrijebljen na Stranici B, taj resurs i zahtjev za navigaciju mogu biti dovršeni istovremeno. S druge strane, ako upotrijebimo predučitavanje za ovaj slučaj, ono će odmah biti otkazano pri prekidu učitavanja Stranice A.

Vratimo li se na naš prvotni primjer s web fontom i upotrijebimo preload request za značajku fonta, možemo napisati HTML na slijedeći način

Uporabom preload-a možemo vidjeti što se zapravo događa na ovom vodopadnom grafikonu:

 

bla2

Web font (broj 3) se obrađuje (proces rezolucije, TCP konekcija i TLS uspostava konekcije) i preuzima istovremeno s drugim značajkama, poput datoteka za stil. Takav čin značajno poboljšava korisničko iskustvo jer se resursi prikazuju odmah na korisnikovu zaslonu.

Implementacija u stvarnim svjetskim mrežnim mjestima ili aplikacijama

Shopify.com je implementirao preload zahtjev za dohvat webfontova i vrijeme potrebno da se na zaslonu pojavi tekst se poboljšalo za 50 %.

Shopify

 

Podrška preglednika

Preload ima prilično solidnu podršku preglednika. Najveći je problem Firefox koji zapravo može upotrijebiti preload, ali tu opciju treba ručno omogućiti u postavkama Firefoxa. Međutim, možemo se nadati da će Firefox omogućiti preload da radi izvan okvira, a postoje i neke naznake da će upravo to i učiniti. https://bugzilla.mozilla.org/show_bug.cgi?id=1222633

 

Zaključak

Današnji prosječni korisnik interneta zahtijeva informacije što je brže moguće. S druge strane, web stranice ili aplikacije imaju više značajki nego ikad prije. Zapravo, imaju ih toliko više da se mnoga mjesta muče s postizanjem visokog stupnja odziva.

Web optimizacija je interdisciplinarno područje i mnogo širi pojam od samo preconnecta, DNS-prefetch-a, prefetch-a i preload-a, ali uporabom ovih jednostavnih metoda možemo značajno poboljšati brzinu web stranice/aplikacije i sveukupno povećati korisničko iskustvo. Razlika je, ipak, puno razvidnija kod platformi za mobitele koje upotrebljavaju sporije veze, poput 3G.

Ako smo išta naučili iz obilja dostupnih analiza i istraživanja, onda je to da je brzina web stranice ili aplikacije presudna za postizanje poslovnih ciljeva.