Raske on leida e-kaubandusest rääkivat üritust, millel mõni ettekandja ei tooks järgmisi näiteid:
• Google: kui otsitulemuste kuvamine muutus 0,5 sekundit aeglasemaks, kaotasid nad 20% liiklusest;
• Amazon: kui lehe laadimine võtaks sekundi kauem, kaotaksid nad aastas 1,6 miljardit dollarit käivet.

Esimene uudis on aastast 2006, teine 2012. Ja Google uuris lehelaadimise kiiruseid 0,4 vs 0,9 sekundit. Praegu on aasta 2020 ning e-poe esilehe laadimine 5 sekundiga kvalifitseerub juba heaks tulemuseks.

Et soola veelgi sügavamale haava hõõruda läheme ajas tagasi aastasse 1968, kui R. B Miller avaldas teadusartikli ”Response Time in Man-Computer Conversation Transactions”, milles ta kirjeldas kasutuskogemuse seisukohalt olulisi viivitusi nii:
• 0,1 sekundit – süsteem tundub töötavat viivituseta;
• 1 sekund – kasutaja mõttelõime katkemise piir, vaevutajutav viivitus;
• 10 sekundit – kasutaja tähelepanu kadumise piir, tekib soov tegeleda muude asjadega.
Kuidas jõuda aastast 1968 ideaali ehk alla 1 sekundi avaneva leheni?

Sagedasemad probleemid

E-poes eduka müügini viiv sekundi-suurusjärgus olev kiirus koosneb hulgast komponentidest ja need kõik nõuavad tööd. Panemaks paika tegevuskava arendajale ja serveri¬haldajale võtame ette fiktiivse e-poe, mille probleemide näited pärinevad hulgalt Zone’I käest abi saanud päris-e-poodidelt.
• Pood on aeglane – esileht, kategoorialeht või tooteleht avaneb üle 3 sekundi.
• Ebastabiilne – esineb hetki, kui server vastab oluliselt aeglasemalt või annab veateate.
• Ei kannata koormust – üldiselt on kiire, aga kui tuleb kampaania, laeb lehte üle 10 sekundi ja hakkab andma “Error 500” veateateid.

Järgmistel lehtedel on selgitatud, kuidas Zone’is probleemseid veebe lahatakse ja kiiremaks tehakse. Kui see liiga keeruline tundub, võib lapata ruttu artikli lõpuni – seal on 7-punktiline investeerimissoovituste nimekiri, millega oma veebiarendaja jutule minna.

Lihtsaim alustamiseks – Google PageSpeed

Google PageSpeed on kõige lihtsam koht alustamiseks ja tulemuse saab kätte kasvõi nutitelefonist. Google hindab serverist veebilehe HTML-i kättesaamise kiirust, aga lisaks ka selle kuvamiseks vajalikke komponente, nagu pildid, .css stiilifailid ja .js skriptid.

Üsna tavapärane on kohata e-poe esilehte, mille kuvamiseks on brauseril vaja teha 100+ päringut kümnekonna erineva serveri suunal ning laadida alla üle 1,5 megabaidi. Sellest ehk kolmandik on pildid, ülejäänu moodustab veebilehe HTML ja stiilid-skriptid ehk sisuliselt tekst.

Minify JavaScript, CSS & HTML, Enable compression: olukorra saab kiiresti paremaks liites hulga väikeseid .js ja .css faile kokku suuremateks, eemaldades neist (ja lehe HTML-ist) liigsed tühikud ja kommentaarid ning lastes need serveril transpordi ajaks ZIP-iga kokku pakkida.

Kohati saab seda teha veebirakenduste seadistuse või lisaplugina abil, kuid parima tulemuse annab arendaja läbimõeldud tegevus. Lehe maht ja päringute arv väheneb kordades ja see annab eriti hästi tunda mobiilseadmete kasutamisel.

Testpoel sai Zone esilehe 1,6 megabaidi pealt alla 690 kilobaidi peale – ainuüksi esilehe HTML vähenes 150 > 25kB ehk 6 korda! Suurima efekti andis pakkimine, mis on juba mõnda aega kõigil Zone’i serveritel vaikimisi sisse lülitatud.

Leverage browser caching: väga lihtne on teha ka seadistus, mis annab brauserile teada, et need failid (samuti pildid) lähema kuu aja jooksul ei muutu ning puudub vajadus igal järgneval lehekuvamisel nende värskust kontrollida. Tasub aga meeles pidada, et see võib tekitada olukorra, kus kujunduse- või sisumuudatus klientide (ja ka iseenda) brauseris niipea ei kajastu.

Optimize images: enamiku veebipiltide nähtav kvaliteet ei lange, kui neid veidi jõudsamalt kokku pakkida. Pole aga harv ka juhus, kui lehe päise- või taustapilt on lihtsalt üle mõistuse suur (nähtud rekord: 8,6 mega) või loetelus kuvatavate väikeste tootepiltide jaoks laetakse alla täissuuruses failid. Siin aitab läbimõeldud pildipoliitika reklaamide ja tootefotode üleslaadimisel, kvaliteetne kujundusteema ning veidike maagiat serveris toimuva pilditöötluse seadistamisel.

Probleemid detailsemalt – GTmetrix.com

Kui üldine pilt ees ja korrastatud, võib ette võtta GTmetrix.com, mis kuvab PageSpeed reeglite alusel tuvastatud probleeme detailsemalt ja lisaks ka “konkureeriva” testimislahenduse Yslow! näitajad. Seal tulevad mõned mõisted lisaks – näiteks CDN (content delivery network) kasutamine ja ilma küpsisteta domeenid. Aga neid on soovitatav mitte liiga tõsiselt võtma hakata, sest enamasti on probleemiks veebirakendus ise.

Selle mõistmiseks tuleks lahti võtta sakk “Waterfall” ehk lehe kuvamiseks vajalike päringute kaskaad ajateljel. Nimekirjas esimene on veebilehe “lehe enda” laadimine ning selle kohal hiirega peatudes kuvatakse info, kui kaua kulus serveril päringule vastuse koostamiseks (Waiting), kaua selle saatmiseks kliendi arvutisse (Receiving), kui kaua läks brauseril esimese näha oleva (above-the-fold) pildi joonistamiseks (First Paint) ja kui kaua lõplikuks laadimiseks (Fully Loaded).

Esimene ajakulu – lehe enda laadimine – on näidisel 1,17 sekundit. Kui veebileht kohal, hakkab brauser seda jupphaaval tõlgendama. Leides viite .css failile tuleb teha järgmine päring, sellest leitud taustapildi kuvamiseks järgmine jne. Sõltuvalt brauserist ja veebiserveriga suhtlemise protokollist (HTTP 1.1 või HTTP/2) käivitub korraga 8 kuni mõnikümmend päringut, seejärel lähevad teele järgmised. Kui osa pilti on valmis joonistatud ja midagi olulist muutub, hakkab joonistamine uuesti otsast peale jne.

Esimene kujutis – on näidisel 2,44 sekundit. Kui pilt on enam-vähem olemas, võib aga laadimine jätkuda – täiendavad skriptid, animatsioonid jms võtab igaüks aega.

Kui tuleme korraks tagasi PageSpeed’i näitajate juurde, võib siinkohal rääkida lahti ka järgmise mõiste: Eliminate render-blocking JavaScript and CSS in above-the-fold content. Ideaalselt optimeeritud veebilehel tuleb esimese vaate kuvamiseks vajalik JavaScript ja CSS kaasa juba lehe HTML-iga (vt smashingmagazine.com lehe lähtekoodi) või laetakse “laisalt” ehk alles siis, kui kasutaja nii kaugele jõuab (vt nt postimees.ee esilehe pildid, mis ilmuvad alles alla kerimisel). Selle pärast ei maksa veel muretseda – küll aga võiks seda endale veebilehe kuvamist vaimusilmas ette kujutadaes meeles pidada.

Leht valmis – 5 sekundit.

Inspector

Läheme aga veel sammukese edasi – eelnevalt nähtud tööriistad on olemas ka igas tänapäevases brauseris ja need leiab, kui paremklõpsuga avanevast menüüst valida Inspect või Inspect Element (Safaril tuleb enne seadetest lubada Developer Tools).

Kui avada Network sakk ning paluda brauseril leht uuesti laadida, unustades kõik varem puhvrisse kogutu, hoides Reload-nupu vajutamise ajal all Shift-klahvi, siis näed seda protsessi täies võlus ja valus.

Kiire netiühenduse taga pole ilmselt vahet, kas alla on vaja laadida 1 või 10 mega. Selleks, et panna ennast “kliendi papudesse”, on Inspektoris võimalus lülitada sisse throttling ehk piirata testimiseks ühenduse kiirust. Näiteks Slow 3G annab tulemuseks esimese pildi üheksandal sekundil.

Juuresoleva pildi tarbeks on tekitatud olukord, kus paar tootefotot on puudu ehk annavad “Error 404” viga. Pildi serveerinuks meile veebiserver suurema jõupingutuseta, puuduva faili puhul käivitub aga kogu poerakendus, võetakse ühendust andmebaasiga ja siis väljastatakse… Kenasti kujundatud ja menüüdega leht mis sisaldab ainult veateadet.

Brauserit ühe pildi puudumine ei sega. Küll aga on protsessorit ja andmebaasi koormava päringuga tekitatud olukord, kus ühe kasutaja teenindamiseks kulutatakse kahe jagu ressursse. Kuniks veebis on 1–2 külastajat, pole sellest ilmselt suurt lugu. Kui aga puuduvaid pilte on rohkem kui üks ning 10-st külastajast saab seeläbi näiteks 40, on täiesti võimalik, et veebilehe genereerimine hakkab umbes 1 sekundi asemel võtma 2–5 sekundit. Ja lisandub veel kogu muu ajakaskaadis nähtav liiklus. Brrr…

Aga serveris?

Need kõik olid probleemid kliendi vaatest. Miks aga lehekülje genereerimine aega võtab ja koormuse tekkimisel veel aeglasemaks läheb?

Lehe kuvamiseks on vaja teha hulk andmebaasipäringuid: veebipoe seaded, tootekategooriad menüü jaoks, sisutekstid, nuppude tõlked, reklaampinnad, kolme sorti esile tõstetud tooted, filtritega navigatsioon (“punased, naiste, põlvikud, mummudega, maavillased, tootja: Suva”) koos valikule vastava toodete arvuga jne.

Magentos on kõige selle info hoidmiseks umbes 200 tabelit ning päringuid kiirendavate indeksite loomine võtab niikaua aega, et seda iga toote muutmise järel teha pole mõtet, vaid indekseerimiseks on kasutusel perioodiliselt serveris käivitatavad nn cron-tööd.

Kui on soov indeksit ette kujutada, tuleb mõelda raamatukogu tähestikulise kataloogi peale, seejärel kujutada võrdluseks ette, kuidas oleks lihtsalt suvalisest hunnikust raamatut otsida. Samuti on seal üsna hästi läbi mõeldud vahepuhvrid ja palju muid nippe. Aga see kõik peab olema asjatundlikult seadistatud ning tulemus reaalse toodete ja kategooriate hulgaga koormuse all läbi testitud.

WordPress + WooCommerce puhul on olukord nadim, sest suurem osa tooteinfost elab ühe “postituste metainfo” tabeli tekstiväljades ja ei ole indekseeritud. Kategooriate ja siltide abil navigeerimine toimib rahuldavalt, kõik keerulisemad liigutused lähevad aga väga aeglaseks niipea, kui toodete arv läheb üle mõnesaja.

Vahel on aga väga aeglane ka Magento – või lihtne WordPress. Siis on probleem enamasti kujundusteema või lisapluginate koodis ning ainus lahendus on lasta arendajal veebile “andurid” külge panna ja välja uurida, kust kohast täpselt king pigistab.

Zone’is on Virtuaalserverile lihtne lisada kahe erineva otstarbega analüüsi-tööriista litsentse. Ülimalt lihtsustatuna teevad need järgmist.

New Relic – jälgib veebilehe reaalset koormust, toob esile aeglased päringud ja aitab neist leida probleemse funktsiooni või andmebaasipäringu rakenduse koodis. Kiire kogemuse saab 14-päevase prooviversiooniga, aga mõistlik oleks see (vähemalt uue poe puhul) esimeseks aastaks peale panna.

BlackFire – võimaldab profileerida üksikpäringuid, leida ressursimahukaid funktsioone ja andmebaasipäringuid. Sobib arendaja tööriistaks mitte reaalajas jälgimiseks.

Serveri jõudlus

Kui kõik soovitused on läbi käidud (esilehe laadimiseks on vaja alla 50 faili, selle suurus on alla 500kB, “leht ise” saabub brauserisse alla 0,5 sekundi ning joonistatakse valmis hetkega) ning siis teatad Facebook’is välkkampaaniast – ja leht muutub hetkega tiguaeglaseks (esilehe laadimine 10+ sekundit) ning osa kasutajaid saab veateate “Error 500”. Mis toimub?

Ülimalt lihtsustatult öeldus suudab protsessor ajaühikus täita kindla hulga käske – ja kuigi mitme tuumaga protsessor toimib nagu mitu protsessorit paralleelis, tekib varem või hiljem ikkagi olukord, kus osad päringud jäävad lihtsalt eelmise lõppemist ootama.

Kuna ükski ressurss ei ole kummist, on serveris seatud rida piiranguid – ning jagatud ehk tavapärases veebimajutuseks kasutatavas virtuaalserveris peavad need tagama ka selle, et ühe kliendi koormus teiste veebide tööd ei segaks. Kui samaaegsete päringute arv jõuab seatud piirini, ei jää serveril muud üle kui anda veateade – sorry, aga hetkel rohkem ei mahu!

Zone Virtuaalserverites on see piir paketist sõltuvalt 50–200 “paralleeltööühikut” ehk korraga teenindatavat ühendust veebiserveriga (Nutika Pilveserveri ja Nutika Privaatserveri puhul seab piiri pigem protsessori tuumade arv). Kui kliendile veebilehe serveerimine (koos kõigi piltide ja lisadega) võtaks täpselt ühe sekundi, võiksime rääkida ka sarnasest numbrist samaaegsetest kasutajatest.

Nagu varasematel lehtedel näha oli, võtab see aga pigem 5 sekundit ning sõltub lisaks kontrollitavatele teguritele ka näiteks klientide internetiühenduse kiirusest. Kuniks esimesed saabujad avalehel olevat 7MB videotausta alla laevad, ootavad teised järjekorras või saavad veateate.

Tuleb välja, et veebipoe koormustaluvust võivad disaini osas tehtud otsused mõjutada isegi rohkem, kui arendaja optimeeritud kood! Mida lihtsam kujundus, seda kergem on tagada suurele hulgale klientidele eeskujulik kasutuskogemus ja pood reaalselt müüma panna. Või mis see eesmärk meil oligi?

Koormustestimine

Suure hulga paralleelsete päringute tekitamiseks on vaja “robotit” ning kõige lihtsam on alustada mõne selleks mõeldud teenusega. Lihtsamad, nagu näiteks loader.io, saadavad korraga teele tellitud koguse päringuid ühe või mitme lehekülje vastu, simuleerides nii kasutaja liikumist veebis ja joonistavad tulemuse kohta graafiku, millest näeb kasutajate paralleelselt teenindatavate päringute arvu.

Nende tasuta prooviversioon võimaldab katsetada üheminutist koormust ja kuni 50 samaaegset päringut. Esimene soovitatav test ongi saata ilma cache-ta esilehe pihta minuti jooksul 1 kuni 50 kasvav koormus ning vaadata, kui palju päringuid sekundis teenindada jõutakse. Kui tulemus ei rahulda, tuleb võtta suuremate limiitidega virtuaalserver või kolida privaatserverisse.

Mõlemal puhul tuleks aga lisaks üle vaadata kõigi rakenduse komponentide toimimine ning serveri seaded: näiteks üleminek PHP värskeimale versioonile võib anda kiirust juurde üle 2 korra. Sageli annab võidu ka loobumine esilehel olevatest erinevatest automaatselt genereeritavatest „soodukad-enimostetud-uued” pakkumistest või filtrite juures leitud toodete arvu kuvamisest. Need kõik on vajalikud komponendid, aga kui ilma nendeta on veeb oluliselt kiirem siis on see selge märk, et nende kasutamine maksab raha kas suurema serveri või arendaja tehtava optimeerimise näol.

NB! Jagatud ehk virtuaalserveri puhul tuleks selliste testidega olla eriti ettevaatlik ning arvestada ka naabritega!

Veebi pidev monitooring

Siiamaani oln selgitatud üksikute päringute probleeme või vaadatud mõnda minutit veebipoe elutsüklist. Pood peab aga töötama ööpäevaringselt ning selle kiirust mõjutab suur hulk tegureid.

Alloleval pildil on ühe saidi monitooringu-graafik teenuses Pingdom.com (see võiks olla kasutusel igas e-poes). Suurema poe puhul võib olla mõistlikum näiteks New Relic, mis annab lisaks detailset infot tarkvara toimimise kohta.

Tuvastatavate probleemide kohta mõned näited reaalsetest poodidest.

Väline teenus – pood laeb oma tootekataloogi välisest teenusest. Seda tehakse öösel, aga kella 3 ja 6 vahel on sellega pidevalt koormatud 10 % protsessori võimsusest. Päringute aeglustumine on minimaalne, aga graafikult siiski näha. Lahendus: koodi optimeerimine.

Hullunud Google – nädalate lõikes muutub sait üha aeglasemaks. Proovides probleemi mõista, avastatakse logidest, et enamiku päringuid teeb otsimootori robot, mis lappab läbi tootefiltreid. Lahendus: Google Webmaster Tools või robots.txt abil keelata filtrite indekseerimine – koormus langeb ja kaob SEO jaoks ülioluline duplikaatsisu probleem.

Andmebaasi varukoopia – keegi on unustanud peale sätte, mis talletab andmebaasi kõigi külastajate (sh otsirobotid) vaadatud tooted. Tulemus: baas on 8GB. Sellest tehakse igal öösel varukoopia, mis põhjustab täiendava koormuse serverile. Lahendus: puhastada andmebaas liigsest tränist ja keelata tarbetu salvestamise.

SEO-skänn – veeb on öösel ja päeval tunnikese aeglasem. Logisid analüüsides selgub, et tegemist on AHREFS-nimelise tööriistaga, mis kogu tootekataloogi läbi lappab ning selle kõrval on väiksemaks probleemiks kolm (ilmselt) konkurenti, kes hinnavõrdlust teevad. Lahendus: kui võimalik, piirata robots.txt abil tarbetute bottide ligipääs.

Boonus – kõik siinsed näited (peale andmebaasi varukoopia) on näha Serveri jõudluse peatüki graafikutel. Pidev koormus oli “hullunud google”, pidev kasv tõenäoliselt tingitud sellest, et otsimootor kaevas ennast filtreid mööda mutates aina sügavamasse auku. Järgi jäänud piigid on SEO-skänn või tootehindade võrdleja, ilmselt mõni konkurent. Ja kui täpselt vaadata, toimub öösel kella 1–2 vahel mingi andmebaasi koormav asi veel.

Mis ei tööta?

Nutikas lugeja on kindlasti taibanud, et kõige eelneva mõte on aidata e-poodnik lähemale arusaamisele: veebirakenduse kiirus ja töökindlus on investeering ning sellega tuleb arvestada nii uue poega alustades ja disainiotsuseid tehes, kui ka igapäevaselt.

Kirjeldatud lahenduste hinnasilt algab ühest arendaja või veebihalduri töötunnist esmaste PageSpeed’i esile toodud vigade kõrvaldamisel ja jõuab sisulisemate koodist kitsaskohtade otsimisel kiirest 4–8 tunnini. Suuremad muudatused ja optimeerimine võivad vabalt võtta nädalaid. Ka lihtne küsimus Zone’i klienditoele: “Miks mu veeb aeglane on?”, tähendab tehnikutele minimaalselt ühte töötundi.

Selle kõige juures on loomulik, et tekib soov leida lihtsamaid ja kiiremaid lahendusi – seda nii tellija kui ka tegija vaatevinklist. Äkki on olemas mõni plugin või laiendus, mis teeb poe kiiremaks?

Täpselt samuti, nagu igast mahahäkitud veebist võib leida hulga turvapluginaid, mis ilmselgelt ei ole oma tööga hakkama saanud, leidub ma igas aeglases poes ka hulga midagi “optimeerivaid” pluginaid. Kindlasti on igaühel neist oma roll, aga läbimõtlemata kasutus lisab sageli protsessorile tööd juurde ning tekitab täiendava komponendi, mis saab mingis ettearvamatus olukorras katki minna.

Üks selline näide on cache. Iseenesest väga hea abivahend, mis puhverdab päringute teenindamiseks vajalikku infot ja paremal juhul terveid veebilehti, aidates sellega tagada suurele hulgale sama-aegsetele külastajatele < 1sekundilist esilehekuvamist. Lihtsalt super! Aga kui selle taha on peidetud optimeerimata kood ja tõsiasi, et tootelehe genereerimine võtab 5 sekundit, siis on see pood ikkagi käpuli niipea, kui seda külastab uudishimulik otsirobot, mis asub indekseerima kõiki lehti.

Ka cache’i efektiivne töö vajab optimeerimist ja monitoorimist ning kuniks seda tehtud pole, kehtib elutarkus: võttes cache-plugina maha, läheb veeb kiiremaks.

Millest pihta hakata ehk checklist

1. Monitooring – lisa vähemalt odavaim Pingdom’i monitooring (soovitatavalt koos RUM (real user monitoring) koodiga veebilehel). See annab tagasisidet järgmiste sammude õnnestumisest.
2. PageSpeed – lase veebiarendajal või -halduril tuvastada ja lahendada peamised esiletoodud probleemid ning põhjendada, miks osad GTmetrix.com põhjalikuma raporti leiud selles faasis reageerimist ei vaja.
3. Koormustest – proovi vähemalt loader.io tasuta testiga järgi, kuidas veeb koormuse all käitub. Lähtu tänasest reaalsest külastatavusest, aga plaani tulevikule mõeldes.
4. Esilehe genereerimine jõudeolekus alla 1 sekundi, selleks tehakse alla 50 päringu, lehe maht soovitavalt alla 1MB.
5. Rakenduse monitooring – võta kasutusele New Relic või mõni teine rakenduse töö analüüsiks mõeldud lahendus. Pane paika soovitud kvaliteedikriteeriumid ja arenguplaan, seo jõudlusnäitajad müüginumbrite või kasutajate rahuloluga.
6. Vali oma raskusklassi sobilik serverilahendus.
7. Hea arendaja ei pruugi olla parim süsteemiadministraator – küsi sellele spetsialiseerunud ettevõttelt “veebirakenduse täishaldust”. Võibolla ei peaks kõige selle monitoorimisega ise tegelema ning efektiivsem lahendus oleks, kui ops (operations) suhtleks dev-iga (developers) ning jagaks omanikule vaid executive level infot.

Väike vihje – kui koodi optimeerimine välja arvata (ja koormustesti natuke teisiti korraldada), on enamik siin kirjeldatud kitsaskohtade tuvastamise meetoditest rakendatavad ka konkurendi veebi peal – ära unusta jälgida nende tegevust ja arengut!