cube-drone-angularSivustojen latausnopeus on ollut yksi tämän talven kantavista teemoista Qurun blogissa. Hitaasti latautuva sivu ärsyttää ja näkyy myös viivan alla, kun kävijät karkaavat ja hakukonenäkyvyys huononee. Tänään kerromme, mitä serveripuolen renderöinti on ja miten se parantaa käyttökokemusta.

Hitaus ja raskaus eivät ole mairittelevia ominaisuuksia, kun puhutaan verkkosivuista ja käyttökokemuksista. Nykyään ihmiset odottavat verkkosivustojen käyttäytyvän kuin mobiilisovellukset, eli latautuvan nopeasti ja toimivan selkeästi. Käyttökokemuksen on oltava virtaviivainen, eikä mikään saa tökkiä. Odotukset eivät kuitenkaan täyty kaikkien verkkosisältöjen kanssa. Palvelinpuolen renderöinti auttaa haasteen ratkaisemisessa.

Miten palvelinpuolen renderöinti toimii?

Palvelinpuolen renderöinnin etu on siinä, että se yksinkertaisesti nopeuttaa verkkosivuston latautumista kävijän päätelaitteessa. Ilman serveripuolen renderöintiä aikaa kuluu palvelimen vastaamiseen, koodien lataamiseen, käyttäjän selaimen alustamiseen, sisällön noutamiseen ja lopulta sisällön esittämiseen käyttäjän ruudulla.

Sisällön lataaminen perinteisesti

Sisällön lataaminen perinteisesti

Perinteisellä tavalla sivun latautuminen vie aikaa keskimäärin kolmesta kymmeneen sekuntia. Latausaikoja ja käyttökokemuksia koskevissa tutkimuksissa on kuitenkin huomattu, että yli puolet mobiilikäyttäjistä hylkää verkkosivuston, jos sen latautuminen kestää pidempään kuin kolme sekuntia. Ja jos olet alkuunkaan kiinnostunut verkkosivustosi näkyvyydestä hakukoneissa, serveripuolen renderöinti auttaa siinäkin. Googlasitpa sitten “kukkia” tai “mehiläisiä”, kymmenen ylintä osumaa napsahtavat näkyviin todennäköisesti palvelinpuolella renderöidyiltä sivuilta.

Palvelinpuolen renderöinti toimii niin, että kun palvelin saa pyynnön, se renderöi tarvittavat sivuelementit HTML-koodiksi ja lähettää paketin paluupostissa takaisin. Sen jälkeen asiakkaan päätelaite ottaa renderöinnissä ohjat käsiinsä. Tämä leikkaa merkittävästi sivuston latausaikaa tai ainakin antaa kävijälle vaikutelman, että sisältö on täysin latautunut ja käytettävissä ja sieltä voi alkaa etsiä ja hyödyntää hakemaansa palvelua, vaikka osa toiminnoista yhä latautuisikin taustalla.

Jos siis suunnittelet verkkosivujen tai -sovelluksen uudistamista, palvelinpuolen renderöinti kannattaa laittaa harkintaan – mitataanhan verkkosivujen ja -sovellusten hyvyys niiden kävijämäärissä sekä kyvyssä osallistaa ja muuntautua.

Historiaa

Palvelinpuolen renderöinti on hieno, muttei mikään uusi juttu. Ensimmäiset sukupolven verkkosovellukset kehitettiin jo yli kymmenen vuotta sitten. Siitä lähtien ne ovat vain parantuneet. Otetaanpa siis lyhyt katsaus palvelinpuolen renderöinnin historiaan.

Ensimmäinen sukupolvi

RubyVuonna 2005 kehitettiin Ruby on Rails, joka käyttää omaa serveripuolen ohjelmointikieltään. Renderöinti tapahtuu palvelimella. Kun siis vierailet Ruby-ohjelmointikieltä käyttävällä verkkosivulla, se tekee kyselyn tietokantaan ja rakentaa vastauksen html-koodina, jonka se lähettää pakettina asiakkaalle.

Ruby on Rails merkitsi suurta loikkaa eteenpäin, sillä sitä käyttävät verkkosivustot renderöityvät kävijöiden selaimiin välittömästi. Sillä on kuitenkin heikkoutensa: aina kun vierailija tekee verkkosivustolla yhtään mitään, mikä muuttaa sisältöä, prosessi on suoritettava uusiksi aluksi eli koko sivusto on ladattava uudelleen. Tämän seurauksena vie aina hetken, jotta verkkosivusto reagoi vierailijansa klikkauksiin.

Toinen sukupolvi

JsonServeripuolen renderöinnissä nähtiin uuden ajan alku vuonna 2010, jolloin kehitettiin single page application -teknologia. Ensimmäisten joukossa syntyivät Backbone, AngularJS and Node.js, ja niitä seurasi muutama muukin.

Latausajoille toisen sukupolven ohjelmistokehykset tarkoittavat lisää kierroksia: kun vierailija tekee verkkosivustolla jotain, eli käytännössä klikkailee ja surffailee, HTTP-pyyntöä ei tarvitse tehdä joka ikisellä kerralla. Sen sijaan tehdään AJAX-pyyntö ja vastauksena serveriltä saadaan pätkä JSON HTML -koodia. Sen avulla pystytään tekemään osittaisia päivityksiä HTML-koodiin ilman, että sivu tarvitsee ladata kokonaan uudelleen. Tämä mahdollistaa sen, että verkkosivusto reagoi välittömästi kävijän klikkauksiin.

Nämä ohjelmistokehykset siirtävät kaikki loogiset operaatiot asiakkaan selaimen vastuulle. Tämä ratkaisee ensimmäisen sukupolven palvelinpohjaisen renderöinnin ongelmat, koska sivut reagoivat nopeammin. Pieni pullonkaula on kuitenkin olemassa: aloitussivun latausaika venyy, koska verkkosivusto renderöityminen täydellisen toiminnalliseksi vie aikaa. Tämä voi hermostuttaa turhautumiseen taipuvaista vierasta, joka ei odotellessaan tiedä, mitä tapahtuu, eikä pääse heittäytymään interaktiiviseen suhteeseen verkkosivuston kanssa.

Mitä tulee seuraavaksi?

Tulevaisuudelta on lupa odottaa askelia eteenpäin. Seuraavan sukupolven ohjelmistokehysten pitäisi kyetä tarjoilemaan sekä välittömästi renderöityjä että välittömästi toimivia verkkosovelluksia. Tämän pitäisi todellakin olla mahdollista. 15. joulukuuta 2015 ilmestyi beta-versio Angular 2, joka lupaa ratkaista tekniset haasteet ja saavuttaa päämäärän.

Tähän mennessä keskeinen haaste on ollut se, että kun verkkosivun vieras näkee täysin renderöityneen sivun edessään ja alkaa klikkailla ja touhuta sen kanssa, asiakkaan päätelaite ei ole vielä herännyt ruususen unesta. Selain ei pysty prosessoimaan klikkauksia, joten hiirenliikkeiden päämäärät hukkuvat tai sovellus reagoikin odottamattomalla tavalla.

Tämän ratkaisemiseksi Angular 2:een on rakennettu kirjasto nimeltä Preboot. Preboot on lyhyt pätkä Javascriptiä. Kun dokumentti yhä latautuu, Preboot alkaa nauhoittaa tapahtumia, ja kun asiakkaan laite on vihdoin valmis reagoimaan, Preboot laittaa tapahtumanauhansa pyörimään. Näin meillä on välittömästi renderöity ja välittömästi toimiva verkkosivusto.

Sivun lataaminen serveripuolen renderöintiä hyödyntäen

Sivun lataaminen serveripuolen renderöintiä hyödyntäen

Käännös englannista: Veera Järvenpää