Twitter-virrassani vilahtaa linkki mielenkiintoiseen artikkeliin. Klikkaan. Sininen palkki selaimen yläreunassa singahtaa taipaleelleen kohti ruudun toista reunaa. Pienen odottelun jälkeen saan ruudulleni kasan erivärisiä laatikoita. Alareunan palkissa kerrotaan, että selain odottaa erään sosiaalisen median palvelun palvelimen vastausta.

Ei kuulu.

Odotellessani ehdin oivaltaa tuijottelevani vain sivuston elementtien taustavärejä. En ole vielä nähnyt yhtään kirjainta, saati janoamaani artikkelia. Murmelin kärsivällisyyteni on tapissa. Klikkaan selaimen kiinni, tuskin se kovin häävi artikkeli olisi edes ollut.

Lyhytkestoisen muistimme varsin rajallinen kapasiteetti kykenee pitämään ajatuksen katkeamattomana noin sekunnin odotuksen yli. Tämä siis tarkoittaa, että sivustolla on sekunti aikaa vastata käyttäjän huutoon, jotta käyttäjä kokee siirtymän sivustolle sulavana. Jokainen pidempään tuhrattu sekunti kasvattaa todennäköisyyttä, että käyttäjä pyörähtää kannoillaan ja katoaa kuin lapsi huvipuistossa. Odottelua ihminen sietää hermostumatta vain reilut kahdeksan sekuntia, kultakalakin jaksaa keskittyä pidempään.

Ja sitten tarkkana: Se että aikaa on sekunti ei tarkoita että koko internetin tulisi olla valmis sekunnissa.

“Näin nämä asiat koetaan”

Oleellisinta sivuston suorituskyvyssä on käyttäjän kokema nopeus. Ei ole juurikaan väliä kestääkö koko sivun lataus kellosta katsottuna 2, 5 vai 15 sekuntia, jos sivusto latautuu käyttäjän mielestä nopeasti.

Käyttäjän kokema odotusaika voidaan jakaa aktiiviseen ja passiiviseen odottamiseen. Passiivisesti odottaessa käyttäjä ei voi muuta kuin toljottaa staattista näkymää. Aktiivisessa odottelussa käyttäjälle saadaan tunne, että asiat etenevät. Ihminen kokee passiivisen odottelun todellista odotusaikaa pidempänä, joten passiivisen odottelun kesto pitää pyrkiä minimoimaan.

Nopean latausajan kulmakivet

Pisin passiivisen odottelun hetki käyttäjälle tulee hänen odotellessaan palvelimen ensimmäistä vastausta. Palvelimen vasteaika voidaan saada suhteellisen lyhyeksi tehokkaalla palvelimella ja hyvällä välimuistituksella, mutta kattavasti erinomaisiin tuloksiin päästään vasta huolellisella työllä.

Kun palvelimelta saadaan vastauksia, on hyvä priorisoida mitä ja missä järjestyksessä niitä käyttäjälle siirretään ja missä järjestyksessä käyttäjän selain niitä käsittelee. Tärkeintä olisi saada käyttäjälle ensimmäinen ruudullinen sisältöä kulutettavaksi mahdollisimman nopeasti. Tätä mittaa SpeedIndex-luku, joka kertoo miten nopeasti sivuston näkyvät osat saadaan piirtymään käyttäjän ruudulle.

SpeedIndex-luku on millisekunteja, joten Googlen suositusarvo “alle tuhat” peilautuu suoraan tutuksi tulleeseen yhden sekunnin sulavuusrajaan. Kun käyttäjälle on saatu ensimmäinen annos sisältöä ruudulle, voidaan loppusivua vielä siirtää ja käsitellä, sillä käyttäjä on koko sivun latautumisen näkökulmasta aktiivisessa odotustilassa.

On myös hyvä tunnistaa kriittiset riippuvuudet kolmansien osapuolien palveluihin. Pääseekö käyttäjä lukemaan artikkelia alkuunkaan, mikäli sivuston alaosassa oleva some-palvelun upotus latautuu hitaasti. Tai jos nättiä verkkofonttia tarjoava palvelu on nurin, näkeekö käyttäjä sivustollasi vain kuvat?

Kestääkö sivustosi lataus niin kauan, että käyttäjä keksii odotellessa muuta tekemistä?

Huolehdi, ettei kuorma kasva suotta

Kun sivuston suorituskykyyn on panostettu, tulee sitä myös vaalia ja pitää se mielessä sivustoa kehitettäessä.

Erään yrityksen sivuille oli toimitusjohtajan käskystä kovalla kiireellä asennettu juuri hankitun markkinoinnin automaatiojärjestelmän oma WordPress-lisäosa. Harmillisesti lisäosa oli koodin laadun perusteella askarreltu vasemman jalan isovarpaalla, silmät sidottuina. Tämän seurauksena sivuston aiemmin tappiin viilattu viidenkymmenen millisekunnin vasteaika venähti reiluun puoleen sekuntiin, kokonaisvaikutus latausaikaan oli lähes sekunti. Ja lisäosan sisältämistä ominaisuuksista hyödynnettiin yhtä: sitä jonka olisi helpoiten tehnyt ilman lisäosaakin.

Tämä suunnaton määrä läskiä sivuston latausajassa huomattiin sattumalta muutamaa viikkoa myöhemmin. Tutkimuksissa tuo lähes puolen sekunnin ylimääräin viive osoittautui jokaisella sivulatauksella toistuvaksi kyselyksi palvelun rajapintaan, jonka ongelmatilanteissa myös koko yrityksen sivusto olisi ollut jojossa. Oikein kunnolla kytenyt pesäke siis. Viivettä aiheuttanut siivu leikeltiin irti välittömästi, mutta koska järjestelmä oli tarkoituksena ottaa laajemmin käyttöön heti, kun ehdittäisiin, ei koko lisäosaa kuulemma voinut poistaa.

Tai no. Paria kuukautta myöhemmin kävin kaikessa hiljaisuudessa korvaamassa lisäosasta käytetyt toiminnallisuudet itse toteutetuilla ratkaisulla ja toimitin lisäosan Topinojalle. Näin siivutin latausajasta loputkin silavat pois eikä kukaan ole vielä tullut kyselemään kadonneiden, joskin käyttämättömien ominaisuuksien perään. Sivuston nopeudesta on sen sijaan tullut kiittävää palautetta.

Nopeusbudjetilla tuhlailu kuriin

Sivustosta ei tehdä nopeaa vivusta vääntäen. Vaikka palvelin- ja välimuistiratkaisuilla sekä teknisellä kehitystavalla voidaan huolehtia hyvistä lähtökohdista, on suorituskyky priorisoitava ominaisuus siinä missä moni muukin. Siksi suorituskyky on aina eräänlainen kompromissi. Vaakakupissa kannattaa kuitenkin huomioida, että nopea sivusto on myös ekologinen.

Sivustolle on hyvä asettaa nopeusbudjetti, esimerkiksi SpeedIndex-arvo alle tuhat. Sivustoa kehitetään tällöin asetetuissa raameissa ja niiden eteen pitää pystyä tekemään myös myönnytyksiä muissa ominaisuuksissa.

Jos epäilet, että sivustollasi viihtyvät vain kultakalat, ota yhteyttä! Tutkimme todellisen tilanteen ja saat kehitysehdotukset kaupan päälle.