Verkkosivujen moottorina toimii yleensä julkaisujärjestelmä. Mutta voiko hyvän saitin tehdä myös ilman? Entä mitkä tekijät vaikuttavat verkkosivuston nopeuteen – ja miksi nopeus on ylipäänsä tärkeää? Eikö nopeutta saa lisää hankkimalla vain isomman moottorin?
2 litran OHC turbo
Pikkupoikien – ja vähän isompienkin – ensimmäinen kysymys autosta usein on ”Mikä kone?” Auton tulee olla tehokas ja nopea. Myös autonvalmistajat tietävät tämän. Mikä muu voisi olla syynä autojen peräpeilistä löytyviin kryptisiin kromikirjainyhdistelmiin, jotka kertovat asiaan vihkiytyneille pellin alla piilevästä tekniikasta?
Myös verkkosivujen tulee olla nopeita. Nopeasti latautuvat ja kevyet verkkosivut ovat paitsi mukavia käyttää, ne myös saavat kävijät viihtymään sivuilla paremmin. Googlen klassisen tutkimuksen mukaan 53 % kävijöistä poistuu sivulta, jos latautuminen kestää yli kolme sekuntia. Sivuston nopeus korostuu mobiiliyhteyksien yli käytettäessä esimerkiksi kesämökillä tai muissa paikoissa, joissa yhteydet ovat tavallista heikompia. Nopeat ja kevyesti latautuvat verkkosivut voivat olla myös ekoteko ja osa yrityksen ympäristövastuullisuutta. Lisäksi nopeat sivut saavat paremman näkyvyyden hakukoneissa, sillä Googlen algoritmi painottaa sivun latausnopeutta osana yleistä käyttökokemusta.
Verkkosivujen nopeuteen vaikuttaa useita tekijöitä. Hosting-ympäristön tekniset resurssit, kuten muisti ja prosessorien määrä sekä verkkoliittymän nopeus ja kaistan paksuus, ovat vain yksi osatekijä. Sivuston arkkitehtuuri ja rakentamiseen käytetyt tekniikat vaikuttavat vähintään yhtä paljon kävijöiden kokemukseen.
Nopea vai hidas?
Voit tutkia sivujen latautumisnopeutta Googlen Lighthouse -työkalujen avulla. Nopeusmittari löytyy valmiiksi asennettuna Chrome-selaimesta.
Huonosti koodattu tai ”väärällä” tai vanhentuneella arkkitehtuurilla toteutettu sivusto voi helposti tuhlata isotkin palvelinresurssit, jolloin sivusto vaikuttaa hitaalta pienelläkin kuormalla.
Sivujen sisältö on kuningas myös nopeuden optimoinnissa. Tarpeeton tauhka kuten ylimääräiset koodikirjastot kannattaa karsia sivuilta ensimmäisenä. Turhien edelleenohjausten välttäminen ja kuvien puristaminen pienempään tilaan ovat seuraavia kohteita, joihin optimoijan katse kiinnittyy. Myöskään raskaasti latautuvaa Google-karttaa harvoin tarvitaan jokaisen sivun alatunnisteessa. Nämä ovat kuitenkin vain ensiapua, mikäli sivuston tekniikassa on lähtökohtaisesti tehty huonoja suunnitteluratkaisuja.
Kolmosen kautta nelosen puhaltimella
Suurin osa verkkosivuista rakennetaan jonkin julkaisujärjestelmän eli CMS:n päälle (Content Management System). Julkaisujärjestelmä on verkossa toimiva sovellus, joka sallii verkkosivujen sisällön muokkaamisen selaimessa toimivassa käyttöliittymässä. Julkaisujärjestelmällä luodut sisällöt tallennetaan tietokantaan, josta ne julkaisun jälkeen näytetään verkkosivuina kävijöille. Julkaisujärjestelmiä ovat esim. yleisesti käytetyt WordPress ja Drupal sekä kymmenet muut enemmän tai vähemmän tunnetut ja lukuisat jo historiaan hautautuneet järjestelmät.
Verkkosivut on mahdollista rakentaa myös ilman julkaisujärjestelmää. Tällöin sivujen luominen vaatii koodiosaamista tai erillisen tietokoneella käytettävän julkaisuohjelmiston. Tämä oli vielä 1990-luvulla käytännössä ainoa tapa verkkosivujen rakentamiseen. 2000-luvun alusta lähtien valtaosa verkkosivuista on rakennettu jonkinlaista julkaisujärjestelmää hyödyntäen.
WordPress on ylivoimainen markkinajohtaja
WordPress on asennettu yli 455 miljoonaan sivustoon. Sillä on TechJuryn mukaan 62 % markkinaosuus julkaisujärjestelmissä. Lähes 40 % kaikista verkossa olevista sivustoista käyttää WordPressiä.
Sisällön noutaminen tietokannasta on hidasta. Usein julkaisujärjestelmällä luodut sivut tallennetaan myös staattisina kopioina sivuston välimuistiin tai erilliselle sisällönjakopalvelimelle. Tarjoillessaan valmiiksi pureskeltuja HTML-tiedostoja verkkopalvelin joutuu vähemmälle kuormitukselle ja sivusto saadaan toimimaan huomattavasti nopeammin. Tämä on erityisen tärkeää silloin, kun sivustolla on paljon liikennettä ja runsaasti samanaikaisia kävijöitä.
Julkaisujärjestelmä voi myös sijaita täysin erillään sivujen käyttöliittymästä. Tällöin puhutaan niin kutsutusta headless CMS -ratkaisusta. Käyttöliittymä voidaan rakentaa esim. moderniksi verkkosovellukseksi vaikkapa Vue.js-sovelluskehyksellä. Tällöin sovellus ladataan kerran selaimen muistiin ja se noutaa sivulta toiselle siirryttäessä uuden sivun sisältämän datan API-rajapintaa hyödyntäen. Näin sivun vaihtaminen tarkoittaakin vain uuden datapaketin lataamista selaimessa jo olevaan sovellukseen. Kun koko sivua ei ladata uudelleen vaan ainoastaan muuttuva osuus, siirtymät sivulta toiselle saadaan toimimaan salamannopeasti – tai voidaan peräti hyödyntää siirtymissä animaatioita.
CMS jättää sen
Joskus julkaisujärjestelmää ei tarvita lainkaan. Jos sivusto on suppea tai sen sisältöä ei tarvitse päivittää usein, julkaisujärjestelmä olisi suurimman osan ajasta hyvin vähäisellä käytöllä tai peräti täysin tarpeeton. Tällöin voi olla fiksumpaa hoitaa sisällön muokkaus perinteisin menetelmin suoraan koodiin – siis sillä 90-lukulaisella tavalla.
Rakentamalla sivut tällä tavalla staattisina on mahdollista säästää työaikaa ja kustannuksia julkaisujärjestelmän asentamisen ja huoltamisen verran.
Ilman julkaisujärjestelmää sivustosta saadaan myös jonkin verran vakaampi ja tietoturvallisempi. Mitä vähemmän osia kokonaisuudessa on, sitä vähemmän on myös paikkoja, jotka voivat mennä rikki ja jotka vaativat ylläpitoa ja päivittämistä. Julkaisujärjestelmään ei voi murtautua, jos sellaista ei ole. Staattisen ratkaisun merkittävänä haittapuolena toki on, että sivujen ylläpitäminen vaatii koodiosaamista tai erikoistyökaluja.
Tilaajan näkökulmasta julkaisujärjestelmän hankintapäätös tehdään usein ”varmuuden vuoksi” -periaatteella tai järjestelmä hankitaan, koska sellainen on aina ennenkin ollut. Usein tilaaja haluaa pitää itsellään mahdollisuuden päivittää sivuja, vaikka jo tilausvaiheessa tiedetään, että käytännössä kaikki muutokset tullaan teettämään sivuston toteuttaneella toimittajalla. Mutta jos omaa halua sivuston päivittämiseen ei ole, kannattaa julkaisujärjestelmän hankinta ainakin hieman kyseenalaistaa.
Montako litraa satasella?
Matematiikka julkaisujärjestelmän hankintapäätöksen taustalla on lopulta varsin yksinkertainen. Julkaisujärjestelmän asennus ja ylläpito maksavat X euroa. Samalla summalla voi ostaa staattiseen sivustoon tehtäviä päivityksiä Y työtuntia. Jos Y koetaan riittäväksi määräksi, jolla tullaan toimeen, kannattaa sivusto toteuttaa staattisena. Tämä on toki raju yksinkertaistus ja vaakakupissa painavat rahan lisäksi myös muut tekijät, kuten toimittajan vasteaika ja kyky spontaaneiden päivitysten tekemiseen sekä julkaisujärjestelmän pois jättämisestä saavutettava tietoturva- ja nopeushyöty.
Olemme LM Somecossa toteuttaneet jonkin verran staattisia sivustoja asiakkaillemme. Tyypillisesti nämä ovat olleet kampanjaluonteisia tai sisällöltään suppeita lyhyen aikavälin sivustoja. Ilman julkaisujärjestelmää olemme rakentaneet myös sivustoja, joiden pääasiallinen sisältö ladataan dynaamisesti jostain muusta lähteestä kuten tuotetietokannasta. Tällöin sivusto on vain osin staattinen. Useimmiten kokonaiskustannukset ja käyttömukavuuden huomioiva matematiikka on kuitenkin puoltanut julkaisujärjestelmän hankintaa myös siinä tapauksessa, että sivustoa päivitetään pääsääntöisesti meidän eli toimittajan toimesta.
Olitpa sitten hankkimassa verkkosivustoa mihin käyttötarkoitukseen tahansa, pidä huoli, että sivuston käyttötarve ohjaa tekniikkavalintoja eikä toisinpäin. Vanha sanonta ”Oikea työkalu oikeaan työhön” pätee myös digimaailmassa. Varmista myös, että sivustosi takaluukusta löytyvät ne oikeat kromikirjaimet, etkä maksa turhaan sellaisesta, mitä et tule koskaan tarvitsemaan.
Kirjoittajan autossa on 2.5 litran vapaastihengittävä 4-sylinterinen polttomoottori ja 105 kW sähkömoottori. Kirjoittajan saitissa on WordPress julkaisujärjestelmä ja Nuxt-tekniikalla js-sovellukseksi rakennettu erillinen käyttöliittymä. Molempia huolletaan säännöllisesti ammattilaisten toimesta.
