Miten nettisivujen latausnopeus mitataan?

Nettisivujen latausnopeuden mittaamiseen on monenlaisia työkaluja, jotka kaikki mittaavat asioita vähän eri näkökulmista. Google PageSpeed Insights ei mittaa sivujen absoluuttista latausnopeutta, vaan analysoi sitä, että kuinka hyvin sivut on optimoitu latausnopeuden näkökulmasta. Esimerkiksi GT Metrix on monipuolinen työkalu latausnopeuden mittaamiseen. TestMySite WithGoogle puolestaan simuloi sivun latausaikaa 3G mobiililaitteella.

Miten nettisivujen latausnopeuksia voi parantaa?

Nettisivujen latausnopeus muodostuu monesta eri tekijästä: palvelin rautatasolla, käytetty ohjelmisto ja sen tietokanta, ladattavan tiedon määrä, protokolla ja tietysti myös samanaikaisten käyttäjien määrä. Nettisivujen nopeuttaminen kannattaa aloittaa kartoittamalla mikä on nykytilanne ja arvioimalla sen perusteella, että missä ovat isoimmat pullonkaulat ja mitkä asiat ovat kustannustehokkainta hoitaa kuntoon suhteessa oletettuun saavutettuun latausnopeushyötyyn. Osa asioista on helppo hoitaa. Optimointia ja säätämistä on mahdollista jatkaa vaikka kuinka pitkälle. Jossain vaiheessa täytyy tietysti kuitenkin laittaa raja vastaan. Rajan tietysti pitäisi kuitenkin olla jossain lähellä sitä pistettä, jossa latausnopeuden optimointi tulee kalliimmaksi kuin nopeammilla sivuilla saavutettu rahallinen hyöty.

Seuraavaksi käydään tarkemmin läpi edellä listaamani latausnopeuteen vaikuttavat kerrokset:

Palvelin

Palvelin rautatasolla on tietysti aina se peruslähtökohta, josta lähdetään liikenteeseen. Muut tasot sitten vaikuttavat siihen, että kuinka tehokkaasti ja viisaasti sitä käytettävissä olevaa rautaa hyödynnetään. Nettipalvelimen tärkeimmät elementit ovat muisti, prosessori(t) ja kovalevy. Ja jos kyseessä ei ole dedikoitu palvelin, niin sitten tietysti vaikuttaa myös, että montako muuta sivustoa on jakamassa näitä resursseja. Nykytilanteen kartoituksessa kannattaa hyödyntää palvelinasiantuntijoita. Pyydä heitä selvittämään, että missä palvelimen osassa on isoimmat pullonkaulat. Yksi tapa lähteä ratkaisemaan nopeusongelmaa on kasvattaa rautaa siihen pullonkaulaan. Eli jos prosessorit käy kuumana, niin lisää laskentatehoa vaan palvelimeen. Tämä on monesti helppo ja nopea tapa saada konkreettista muutosta aikaan. Tietysti järeämpi palvelin myös sitten aina maksaa enemmän. Ennen kuin lähdet tilaamaan lisää palikoita palvelimeen, niin lue kuitenkin tämä artikkeli ensin loppuun, koska todellinen hitauden aiheuttaja saattaa olla myös jossain ihan muualla.

Palvelimen ja sovellustason välissä on periaatteessa myös palvelinsovellus-taso. Www-palvelinohjelmistossakin on lukuisia asetuksia, jotka vaikuttavat sivujen latausnopeuksiin. Niihin en nyt tässä yhteydessä puutu.

Sovellustaso / Tietokantataso

Sovellustasolla tarkoitetaan julkaisujärjestelmän tai verkkokauppaohjelmiston teknistä toteutusta. Verkkosivustoilla sovellustaso ei kuitenkaan ole yleensä pullonkaula, vaan tietokanta, joka on käytännössä osa sovellusta. Kuinka ohjelmisto käyttää tietokantaa, vaikuttaa hyvin merkittävästi siihen, että kuinka paljon rautaa sen pyörittäminen vaatii ja kuinka isolla datamäärällä se vielä on mahdollista saada toimimaan hyvin.

Jotkut verkkokauppaohjelmistot ovat esimerkiksi tunnettuja siitä, että niiden pyörittäminen on tosi raskasta. Yleisesti ottaen mitä monimutkaisempi järjestelmä, niin sitä enemmän täytyy tehdä tietokantahakuja joka sivulla ja se tietysti kuormittaa palvelinta. Käytännössä myös ohjelmoijien tekemät tietokantarakenteet ja kyselyt eivät aina ole tehty fiksuimmalla mahdollisella tavalla. Aina koodarit eivät tule suunnitelleeksi kyselyjä ja tietokannan indeksejä sillä ajatuksella, että mitenkäs se toimii sitten, kun datamäärä kasvaa kymmentuhatkertaiseksi. Ja vaikka suunnittelisikin, niin jos suurella datamäärällä testaaminen jää tekemättä, niin…

Optimoimattomat tietokantakyselyt tulevat monesti vastaan vasta tuotantoympäristössä, kun sovellusta on käytetty jo pitemmän aikaa. Jos jotkut yksittäisten toimintojen suorittaminen sivustolla kestää kauan, vaikka sivut yleisesti ottaen latautuvat hyvin, voi se olla merkki tietokantaoptimoinnin tarpeesta kyseisten toimintojen osalta. Tämänkaltainen optimointi vaatii osaavan tekijän. Haasteena on myös se, että etukäteen voi olla välillä vaikea sanoa, että kuinka isotöinen optimointityö on ja etukäteen voi olla mahdotonta arvioida, että kuinka suuren nopeushyödyn optimointi tulee saamaan aikaan. Olen nähnyt parhaimmillaan, miten useita kymmeniä sekunteja latautuva sivu on pienellä tietokantaoptimoinnilla saatu optimoitua latautumaan alle kahteen sekuntiin. Tuollainen parannus voi kuitenkin onnistua vain, jos hidastuksen on aiheuttanut jokin suunnitteluvirhe ja osaava koodari hoitaa sen kuntoon. Tällaista pahan laatuista suunnitteluvirhettä ei saa korjattua pelkästään palvelimeen rautaa lisäämällä.

Tietokantaoptimointi kannattaa jättää osaajien käsiin.

Ladattavan tiedon määrä

Optimoimalla yksittäisellä sivulla olevan tiedon määrää ja kokoa, sekä HTTP-pyyntöjen määrää, voidaan merkittävästi nopeuttaa sivujen latautumista. Tämän osion asioista jokaisen verkkokauppiaan on varmasti helpointa ja kustannustehokkainta lähteä liikenteeseen. Tähän osioon saa helpoiten vinkkejä syöttämällä oman nettisivustonsa osoitteen Google PageSpeed Insights -työkaluun. Alla kerron lyhyesti yleisimmistä optimointikeinoista.

Kuvien optimointi

Kuvien optimointi on tämän koko listan ehkä helpoin asia hoitaa. Silti se näyttää monelta jäävän väliin. Yleensä asiakkaiden sivustojen hitausongelmia selvittäessäni tarkistan tämän asian ensimmäisenä. Usein sivuilla on ollut useita jopa parin megatavun kuvia. Esimerkiksi sivuston etusivun koko kuvineen päivineen saattaa olla 6-10 megatavua! Ja sitten ihmetellään, että miksi sivujen lataus tahmaa. Jos sivuillasi on paljon optimoimattomia kuvia, niin todennäköisesti saat pienellä vaivalla sivujen koon kutistettua vähintään puoleen – joskus jopa murto-osaan. Se tekee hyvää latausnopeuksille!

Kuvien kompressointiin hyviä työkaluja ovat esimerkiksi TinyPNG ja Compressor.io.

Resurssien minifointi

Jokainen ylimääräinen palanen koodia kasvattaa sivun kokoa. HTML-, CSS- ja JavaScript -koodissa on aina paljon ylimääräisiä välilyöntejä, sisennyksiä ja rivinvaihtoja. Kun koodia on paljon, niin näistä kertyy huomattava osa dataa, jota on ihan turhaa pitää hidastamassa latausaikoja. Minifoimalla em resursseista saadaan kutistettua ylimääräiset pois. Käyttäjälle muutos ei näy mitenkään – paitsi tietysti hiukan nopeampana latausnopeutena.

Samalla voi miettiä sitä, että olisiko CSS ja JavaScript -tiedostoja mahdollista yhdistää. Monesti sivustoilla on turhaan lukuisia CSS-tiedostoja ja JavaScript -tiedostoja, jotka olisi mahdollista yhdistää. Mitä vähemmän on siirreltäviä tiedostoja, niin sitä vähemmän täytyy tehdä erillisiä HTTP-pyyntöjä. Erilliset pyynnöt hidastavat turhaan sivun lataamista. Näin ainakin HTTP 1.1:ssä. HTTP/2 -versiossa tiedostojen yhdistely ei ilmeisesti tuo enää mitään erityistä nopeushyötyä. Lue HTTP/2:sta lisää kappaleesta Protokollatasot.

Selaimen välimuistin hyödyntäminen

Sivuston staattiset resurssit, kuten kuvatiedostot, voi määrittää latautumaan selaimen välimuistiin. Silloin käyttäjän ei tarvitse ladata niitä aina uudestaan sivuille palatessaan. Resurssit ladataan ensimmäisellä kertaa välimuistiin ja ne pysyvät siellä kunnes resurssin umpeutumisaika kuluu tai kun käyttäjä tyhjentää selaimen välimuistin. Kuvatiedostoille ja muille resursseille määritetään välimuistin umpeutumisaika www-palvelimen asetuksissa.

AMP

Mikä on AMP?

AMP (eli Accelerated Mobile Pages) on open source -hanke, jonka tavoitteena on nopeasti latautuvat mobiilisivut. Hanketta tukee mm. Google, Baidu, Bing, Twitter ja Pinterest. AMP on käytännössä nettisivujen ylimääräisestä karsittu mobiiliversio. Parhaimmillaan AMP-sivut latautuvat jopa noin puolet tavallisia sivuja nopeammin. Nopeus ja käyttömukavuus auttavat AMP-sivuja rankkautumaan varsinkin mobiilihakujen hakutuloksissa korkeammalle. Google on muutenkin antanut vaiheittain monin tavoin buustia hakukonenäkyvyyteen sivustoille, joiden käyttökokemus mobiililaitteilla on miellyttävä.

Vuonna 2016 Google ilmoitti AMP-sivustojen saavan laajennettua näkyvyyttä hakutuloksissa. AMP siis vaikuttaa mobiilihauissa myös hakukonenäkyvyyteen suoraan. AMP on nyt responsiivisuudesta seuraava askel kohti parempaa käyttökokemusta mobiililaitteilla.

AMP latausaikoja nopeuttamaan?

AMP on tällä hetkellä vielä varsin vähän käytössä. Eli välttämättä vielä ei ole tulipalokiire ottaa sitä käyttöön. Toisaalta juuri nyt on erinomainen tilaisuus saada joksikin aikaa etumatkaa muihin ottamalla AMP käyttöön ennen kilpailijoita. Kannattaa siis ainakin ottaa asia harkintaan erityisesti, jos suunnittelee muutenkin nettisivujen uudistamista. Jos AMP:n aikoo ottaa käyttöön, niin projekti tulee suunnitella ja toteuttaa huolella, ettei samalla tule pilanneeksi sivuston käyttömukavuutta.

Samanaikaisten kävijöiden määrä

Samanaikaisten kävijöiden määrä vaikuttaa sivujen latausnopeuteen, koska mitä enemmän tulee samanaikaisia sivun latauspyyntöjä, sitä enemmän palvelin kuormittuu ja sitä enemmän palvelimelta vaaditaan tehoja. Samanaikaisten kävijöiden määrää ei tietysti kannata pyrkiä vähentämään, vaan rakentamaan palvelin sellaiseksi, että se ei kyykkää heti, kun markkinointikampanjat saa kävijät ryntäämään joukoittain sivuille. Joustava vaihtoehto on hyödyntää pilviteknologiaa, jossa pilvestä varataan automaattisesti aina sen verran resursseja kuin kulloinenkin tarve vaatii. Kävijäpiikki ei silloin hidasta palvelinta, vaan palveluntarjoaja lähettää vaan vähän suolaisemman laskun, jos palvelu on vaikka yksittäisen päivän ajan käyttänyt moninkertaisen määrän palvelinresursseja.

Protokollataso

Internetissä käytetään vielä varsin laajasti HTTP 1.1 (Hyper Text Transfer Protocol) tiedonsiirto-protokollaversiota. HTTP 1.1 on jo vanha ja siinä on omat puutteensa ja ylimääräistä hidastusta aiheuttavat piirteensä. HTTP/2 on uusi versio HTTP-protokollasta. Google on yksi isoista tahoista, jotka ovat olleet protokollaa kehittämässä.

Vanha ja vielä vallitseva protokollaversio toimii siten, että kun se noutaa nettisivun, niin se luo jokaista tiedostoa varten uuden yhteyden palvelimeen ja sitten katkaisee yhteyden saatuaan tiedoston siirrettyä. Tämä on vähän sama juttu kuin jos ruokakaupan asiakas veisi jokaisen tuotteen yksitellen kassalta autoon. HTTP/2 puolestaan luo yhden yhteyden, jonka välityksellä se siirtää kaikki tiedostot kerralla. Nykyään nettisivustoissa on helposti kymmeniä tai satoja ladattavia tiedostoja yksittäisellä sivulla.

HTTP/2 siis toimii huomattavasti vanhaa HTTP 1.1:stä nopeammin.

Isoimmat selaimet ovat tukeneet HTTP/2:sta jo vuodesta 2015 lähtien. Jollain pienemmillä selaimilla kuitenkin saattaa vieläkin tulla vastaan jotain odottamattomia ongelmia varsinkin monimutkaisilla nettisivustoilla. Lisäksi HTTP/2:n asentaminen www-palvelimeen voi olla vielä haastavaa. Sitä ei löydy palvelimista vielä vakiovarusteena. HTTP/2 ei siis välttämättä ole vielä nyt heti sivustosi latausnopeuden kehittämisprojektin kärkipään asioita, mutta lähivuosien aikana, kun protokollan loputkin ongelmat on saatu ratkottua, niin todennäköisesti HTTP2 alkaa pikkuhiljaa yleistyä ja viimeistään silloin sitä kannattaa alkaa hyödyntää.

‍

Tämä artikkeli on julkaistu alunperin vuonna 2017, eli se ei välttämättä ole kaikilta osin enää ajan hermolla.