Ubrzavanje sajtova

Optimizacija sajta predstavlja seriju koraka koju je potrebno uraditi kako bi se sajt učitao brže -> vreme koje je  potrebno da vaš omiljeni browser sažvaće neku veb stranicu. Ako pratimo analogiju hrane, neke strane su omiljeno jelo, dok su neke – nejestive.

Šta je potrebno da uradimo da ubrzamo website?

Nažalost, ne može od babe devojka, ali može da se urade neke stvari kojim ćemo doći do boljih rezultata. Da bismo videli da idemo u pravom smeru, prvo moramo da vidimo gde smo, koristeći neki alat da vidimo koliko je sajt brz. Moji omiljen alat GTMetrix, sada se  nažalost bazira na Lighthouse engine-u, pa je svejedno da li njega koristite ili standardno Page Insights.

• PageSpeed Insights – prikazuje rezultate odvojeno za mobilne i desktop uređaje
• GTmetrix

Ne juri 100/100! Ne zato što je nemoguće, nego zato što je nepotrebno. Naravno da je super da imate što bolji rezultat, ali to ti sigurno neće zacementirati poziciju na google pretragama. Brzina učitavanja strana domena / vebsajta, je samo jedan od faktora koji pretraživači koji drže do sebe uzimaju u obzir kada rangiraju strane po ključnim rečima, ali nije jedini faktor.

Zašto ovo radimo?

Iako je logično zašto ovo radimo, možda nije najjasniji tehnički aspekt iza brzine učitavanja, pa da bih to objasnio, napraviću paralelu, uporediću vaš omiljen browser sa konobarom, konobarom koji ima određeni broj ruku sa kojim vam donosi obrok, da kažemo da je to oko šest ruku. Ruke se brzo popune tanjirima, a onda čekaju da im server spremi stotinak ručkova koji je zatražio pre toga…

Da bi ubrzali ovaj proces sa  jedne strane je potrebno grupisati resurse – smanjiti broj zahteva ka serveru, a sa druge smanjiti količinu podataka koji se prebacuju.

Elementi koji najviše usporavaju učitavanje strane

Popisaću redno, elemente koji procentualno (od sajtova koje sam do sada popravljao) najviše usporavaju učitavanje strana, od elemenata koji najviše usporavaju do elemenata koji imaju najmanji uticaj:

1. Slike
2. Nekontrolisan broj ubačenih javascript fajlova i CSS fajlova na strani
3. Gzip nije uključen
4. Keširanje – serversko i klijentsko
5. CDN

Slike

Problem implementacijom slika mogu podeliti na:

• Implementacione probleme
  Programeri često ubacuju slike tako što u tzv img tag, samo popune src attribut, upute ka slici i to je to. Jedna slika sada se kontroliše preko CSS-a, njene dimenzije i to izgleda ok i idemo dalje.
  Ali to je loše, veoma loše. Najviše zbog toga što se slika, koja je najčešće velikih dimenzija za mobilne uređaje, učitava na istim, a ne njena umanjena verzija. Zamislite, šta će slika 1200×400 piksela na mobilnom uređaju, čija je rezolucija 320×568. Zašto bi takav uređaj učitavao ogromnu sliku – rasipanje podataka. Osim src atributa, img tag podržava width, height atribute, kao i sizes i srcset atribute uz čiju pomoć pomažete browser-u da ne čeka da se slika preuzme sa servera da bi dobio njene dimenzije(width & height), nego mu i dajete opcije za preuzimanje odgovarajuće slike iz  bazena različitih, unapred napravljenih dimenzija, koje odgovaraju rezoluciji i tipu ekrana(retina vs not-retina) uređaja – sizes & srcset.
• Probleme oko odabira formata slike (ekstenzije)
  Često sam video da dizajneri ne znaju razliku, a samim tim ni prednosti i mane, između korišćenja jpg i png formata, a kamoli da tako nešto očekujemo od programera/administratora, koji ubacuju na strane iste te slike, bez razmišljanja da li su te slike u ispravnom formatu. Da ne ulazim sad u dubinu ili pokrivanje svih grafičkih formata, što ću uraditi u nekom od sledećih postova, pokriću par najčešćih, matorih formata(izašli su i novi formati, koji za sada 2021 nisu još uvek najpodržaniji u browser-ima):
  • JPG – raster – koristiš kada prikazuješ slike koje imaju mnoštvo boja, npr slika uslikana kamerom vašeg mobilnog telefona
  • PNG – raster – koristiš kada slika ima ograničen broj boja. Ako ima gradijent, senku ( mnoštvo boja 😀 ) – jpg, ali ako želiš transparentnost/providnost, osuđen si na png, pa koliko košta da košta
  • GIF – raster – ako želiš animiranu sliku, podržava transparenciju, ali ako nema animacije, idi sa png formatom
  • SVG – vektor – ovaj format može da se skalira u nedogled, u tekstualnom je obliku (xml) – prilikom povećavanja slike, ne dolazi do zamućenja/blurovanja, takođe podržava transparentnost
• Probleme oko optimizacija slika – kompresije – lossy i lossless
  Slike, u kojoj god ekstenziji se nalazile se mogu kompresovati (smanjuje se  veličina slike, na uštrb kvaliteta), čime se njihov očima primetan kvalitet može (lossy kompresija) pokvariti u većoj ili manjoj meri ili se to okom ne može primetiti (lossless kompresija). Online alat – tinyPNG
• Grupisanje grafičkih fajlova – sprite
  Sve grafike, umesto da se pozivaju pojedinačno, je bolje popakovati u jednu sliku, čije delove pozivamo i prikazujemo na odgovarajućim mestima, ili još bolje, ako postoji mogućnost grupisati sve slike u grafički font, ali za to je potrebno da imate vektorske formate svih grafika. Razlog grupisanja je taj da je u digitalnom svetu brže da dovučete jedan veći resurs, nego dvadeset manjih.

Nekontrolisan broj ubačenih javascript fajlova i CSS fajlova na strani

Ako otvorite source sajta koji je baziran na themeforest temi – ovo su prizori koji možete da zateknete …

20+ javascript fajlova, i 30+ css fajlova?!?

Zašto bre to tako? Bitno je da sajt izgleda, a ne da bude brz – e pa može i jedno i drugo, samo neko ili ne zna da je potrebno da sajt bude brz(klijent) inicijalno, pa sazna posle i neko da može da bude brz (dizajneri i programeri, vas gledam).

Svaki alat, od šrafcigera i čekića sa jedne kao i wordpress-a, drupala ili čega već sa druge, može da se koristi ispravno i neispravno. I jedni i drugi imaju mogućnost da se pogrešno koriste, a u samoj osnovi je neznanje, nedovoljna upućenost šta neki alat može sve ili ako ne može, šta treba sve.

Gzip nije uključen

Gzip je način minifikacije tekstualnih asset-a, slično zipovanju, između servera koji radi gzip i browsera koji taj minifikovan resurs čita, umesto slanja nekompresovanog fajla sa servera. Ponekad kompresija nije omogućena na serverskoj strani, ponekad iako jeste – ne koristi se – nedostaje konfiguracija, koja liči na nešto ovako(apache konfiguracija, dodatak koji treba ubaciti u .htaccess – prethodno uradite backup htaccess fajla):

# GZIP kompresija fajlova: HTML, CSS, JS, Text, XML, fontovi
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
</IfModule>

Keširanje – serversko i klijentsko

Osnova keširanja je isporuka bajatog resursa korisniku, umesto svežeg, zarad brzine. Keširanje može biti:

• klijentsko keširanje
  npr slika pera.jpg se dostavlja sa jedne adrese. Ta adresa slike, se pamti u kešu vašeg browsera uz  samu sliku koja se već preuzela onog momenta kada ste otvorili neku web stranicu. Iako se desi da može da se slika promeni na serveru, vaš browser može da i dalje prikazuje staru. Pa odakle dolazi ta stara slika, ako se više ne nalazi na serveru? Pa iz keša vašeg browsera. Šta više, mi programeri imamo specijalne moći, kojim govorimo browserima koliko dugo da skladište te slike u vašim browserima. To se sve radi u cilju da  se strana što pre učita, odnosno da se ne preuzimaju datoteke iznova i iznova, npr logo nekog sajta ili sprajt(pomenuo sam ovo kada  sam pričao o optimizaciji slika), nego da se taj isti logo, kada se već preuzeo i snimio u neki keš browser-a, uzme odatle i time se preskoči opet preuzimanje sa servera i smanji potrošnja interneta. To nam nekad odgovara, nekad ne, baš u slučaju kada dođe do promene slike, ali to je opet neka druga tema, sada je jasnije šta je klijentski keš, odnosno keš browser-a. Ispod možeš naći opet primer za .htaccess, gde definišemo datum isteka roka nekih tipova resursa na serveru
  # Keširaj ove tipove fajlova ne period od jedne nedelje od preuzimanja
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|svg)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch">
• serversko keširanje
  da bih ovo objasnio, moram da pojasnim kako se učitavaju podaci većine sajtova, iza kojih postoji neka baza podataka. Kada dođe zahtev ka strani, programski jezik uspostavlja komunikaciju ka bazi podataka, uzimaju se podaci iz baze i onda se prikazuju na strani. To košta vremena. Mnogo je bolje ako su svi ti podaci već na samoj strani, da ne moraju da se dohvataju iz baze, ali to bi onda značilo da imamo hiljade i hiljade fizičkih html strana na serveru, što otežava administraciju(administratori bi morali biti programeri) iako bi se brže prikazivale. E tu ulazi keširanje, gde se strana servira kao statična, ali je zapravo unapred generisana, koristeći podatke iz baze podataka. Za ovo je  potrebna odgovarajuća arhitektura servera i aplikacije koja podržava keširanje, što uglavnom i jeste slučaj, ali češće je slučaj da je loše konfigurisan sistem za keširanje, tako da ili se podaci nikad ne osveže ili se  uopšte ni ne koristi keširanje, što za posledicu usporava učitavanje strana, ili prilikom povećane posete, može da blokira/onesposobi hosting server, koji ne može da isporuči toliko odgovora na sve te zahteve ka resursima.

CDN – Content Delivery Network

Mreža na koju sve vama bitne fajlove distribuira vašim posetiocima sa njima najbližih servera. Zamislite da je naš sajt hostovan u Srbiji, a da naš posetilac dolazi iz Kanade. Svi podaci, bitni da se strana lepo i brzo učita se moraju preuzeti sa servera iz Srbije, što otežava preuzimanje slika, jer ti podaci fizički moraju da pređu ogromne količine kilometara, za razliku od posetilaca iz Srbije, koji praktično instant dobijaju podatke. CDN nije obavezan, više pitanje da li imate interes da npr ponudu svojih artikala nudite tržištu Kanade, ili ne. To je poslovna odluka, zato, iz tog ugla kažem da CDN nije obavezan. Sajt će se naravno učitati i posetiocima iz Kanade, samo nešto sporije nego bližim posetiocima vašem serveru.

Ovo je samo neka standardna lista kroz koju obavezno prolazim kada gledam brzinu nekog sajta, dok postoji još faktora koji mogu da utiču – od hostinga, izabrane arhitekture vaše aplikacije.

Ako se ne snađeš sam, ništa strašno – tu smo da pomognemo – kontaktiraj nas.