Headless-teknologia ei sovellu WordPress- markkinointisivustoille
Mitä headless tarkoittaa?
Headless-termillä tarkoitetaan sellaista arkkitehtuuria, missä verkkosivuston taustajärjestelmä on erotettu selkeästi esityskerroksesta – eli backend ja frontend ovat erillisiä. Sisältöä hallitaan taustajärjestelmästä ja sisältö haetaan taustalta rajapinnan kautta erilliseen esityskerrokseen.
Perinteisesti taustajärjestelmä ja esityskerros ovat teknisesti samaa toteutusta, eli headless-toteutus siis eroaa tästä pitämällä nämä osa-alueet selkeästi erillään. WordPress-maailmassa tämä tarkoittaa esimerkiksi sitä, että WordPressin ydin asennetaan normaalisti ja sivuston julkisesti näkyvät osat toteutetaan erillisenä esimerkiksi React-pohjaisella Next.js-kirjastolla.
Headless-toteutuksissa on tiettyjä etuja, joilla niitä myydään. Yksi tärkein myyntilupaus on nopeammat latausajat. Käyttöliittymä ladataan vain kertaalleen ja sen jälkeen selain lataa pelkästään sisältöjä julkaisujärjestelmästä. Parhaimmillaan tämä synnyttääkin vaikutelman nopeasta käyttöliittymästä ja selailukokemus voi siirtymineen olla jopa sovellusmainen.
Toinen tärkeä myyntivaltti on turvallisuus. Parhaimmillaan taustalla oleva julkaisujärjestelmä voidaan piilottaa julkisesta verkosta kokonaan ja näin ollen se ei ole myöskään altis tietomurroille. Vastaan on tullut headless-WordPress-toteutuksia, joiden lisäosia ei ole päivitetty aikoihin, koska tälle ei välttämättä ole akuuttia tarvetta.
Nämä väittämät ovatkin oikein toteutetun headless-sivuston etuja ja muutamien viime vuosien aikana Suomessa onkin tehty lukuisia headless-teknologiaan pohjautuvia WordPress-sivustoja.
Tosiasia markkinassa on kuitenkin se, että headless-trendin ansioista monissa organisaatioissa on ajettu rajusti seinään sivustojen kanssa ja ongelmat nousevat nyt esiin. Viimeisen vuoden aikana oman työpöytäni kautta on kulkenut hämmästyttävä joukko tarjouspyyntöjä, joissa halutaan epätoivoisesti eroon headless-toteutuksesta.
Myyntiesityksissä headless-toteutukset näyttävät houkuttelevilta, mutta käytännössä tilanne vaikuttaa olevan aivan toinen. Ironisinta on ehkä se, että headless-toteutusten yksi suurimmista ongelmista vaikuttaa olevan juurikin suorituskyky. Kalliin projektin lopputuloksena on usein laiminlyöty myös ihan perusasioita, kuten hakukonenäkyvyyttä. Ostajana kannattaa olla tarkkana – käyn nyt läpi joitakin headless-toteutusten isoimpia haasteita.
Suorituskyky
Headless-sivustoissa käyttöliittymä ladataan siis ensimmäisellä kerralla kokonaan ja sen jälkeen WordPressistä haetaan vain sisältöjä. Ongelma tällaisessa toteutuksessa on se, että etenkin isommissa projekteissa koodin määrä kasvaa ja itseasiassa ensimmäisestä sivulatauksesta tuleekin raskas, sillä koko käyttöliittymä pitää ladata kerrallaan. Siirtymät sivujen välillä voivat olla nopeita, mutta ensimmäinen lataus – se kaikkein ratkaisevin tekijä – on usein hidas. Kun käyttäjä on Googlessa klikannut linkkiä, odotus on, että sivu latautuu nopeasti. Sillä ei ole juurikaan merkitystä, että toinen sivulataus on nopea.
Nykyaikaisen verkkopalvelun suorituskyky on myös hyvin monisyinen asia. Monoliittiseksi paisunut React-sovellus saattaa vastailla hiiren klikkauksiin laiskasti, jos toteutusta ei ole tehty huolella. Isot kuvat ovat isoja kuvia headless-toteutuksessakin ja raskaat seurantaskriptit pitää silti ladata. Headless ei siis ole mikään oikotie nopeaan sivustoon.
Ilman headless-teknologiaa on täysin mahdollista tehdä nopeita sivustoja. Me ylläpidämme Evermadella suurikokoisia WordPress-sivustoja, ja valtaosa näistä sivustoista on perinteisiä WordPress-toteutuksia melko yksinkertaisella palvelininfralla. Suorituskyky on hyvin harvoin muodostunut ongelmaksi – ja vielä harvemmin ongelma on sellainen, jonka headless-toteutus pystyisi ratkaisemaan.
Käytäntöjen puute
Jos haluaa kehittää WordPress-sivuston, voi lukea virallisesta dokumentaatiosta parhaista kehityskäytännöistä. Moni asia on hyvin standardoitua ja selkeää yhteisten pelisääntöjen ansiosta. Jos haluaa tehdä WordPressiä käyttävän headless-sivuston, onkin yhtäkkiä täysin omillaan. WordPress-yhteisöllä ei ole mitään virallista tapaa tehdä headless-toteutuksia. Tämä tarkoittaa sitä, että yksinkertaisiakin asioita pitää toteuttaa alusta alkaen itse.
Hyvä esimerkki ovat lomakkeet. Jos haluaa käyttää lomakelisäosaa normaalissa WordPress-sivustossa, prosessi on yksinkertainen. Asennetaan lisäosa, luodaan lomake ja valitaan, millä sivulla se näytetään. Lomakkeen ulkoasu saattaa vaatia yksinkertaista tyylittelyä.
Headless-toteutuksessa lomakkeen esittäminen ja tietojen lähetys lomakkeelta pitää koodata itse. Yhtäkkiä normaalisti valmiina oleva toiminnallisuus vaatiikin omaa koodaustyötä. Sama asia pätee kaikkiin lisäosiin, joiden tulisi näkyä sivuston loppukäyttäjille. Perustoimintojen koodaus itse on hidasta, kallista sekä luo ylläpitovelkaa. Lisäosien päivitysten yhteydessä on myös mahdollista, että omaa koodia joutuu muokkaamaan.
Käytäntöjen puute näkyy myös siinä, että monet periaatteessa itsestäänselvät asiat pitääkin ratkaista itse. Metatiedot hakukoneille pitää muistaa lisätä kaikkiin sivupohjiin omin käsin, eikä sivujen esikatselu välttämättä toimikaan.
Sanon aina, että headless-sivustoilla menettää valtaosan WordPress-yhteisön ekosysteemihyödyistä. WordPressin suurimpia vahvuuksia on nimenomaan laaja ekosysteemi, joka tuo tukea, turvaa ja kustannussäästöjä.
Toimittajalukko
Yksi yleisesti käytettyjen ja avoimen lähdekoodin hankkeiden vahvuuksista on se, että ainakin teoriassa toimittajakumppania voi vaihtaa helposti. Tämä on pitkään ollut ostajan näkökulmasta yksi WordPress-alustan etu, joka nousee myyntitilanteissa säännöllisesti esiin. Mikäli yhteistyö nykykumppanin kanssa ei suju, on toimittajaa mahdollista vaihtaa.
Headless-maailma tuo tähän yhtälöön yhden ylimääräisen mutkan. Koska ei ole olemassa yhtä tapaa tehdä headless-toteutuksia WordPressille, toteutukset saattavat vaihdella keskenään hyvinkin paljon. Tämä tarkoittaa käytännössä sitä, että toisen toimittajan saattaa olla vaikea hypätä jatkokehittämään sivustoa. Vaikka headless-ratkaisut ovatkin tyypillisesti avointa lähdekoodia, hankaloittaa toteutusten kirjo toimittajan vaihtoa.
Monimutkaisuus
Vaikka asiaa tarkastelisi miten päin tahansa, on headless-arkkitehtuuri monimutkaisempi kuin perinteinen WordPress-toteutus. WordPress-palvelinympäristön lisäksi headless-sivustolla tarvitaan erillinen ympäristö frontend-toteutukselle. Tämä eriyttäminen on headless-teknologian ydintä ja teoriassa eri komponenttien pitäminen erillään selkeyttää arkkitehtuuria. Käytännössä se kuitenkin tuo mukaan uusia liikkuvia osia ja väistämättä monimutkaistaa projektia. Monimutkaisuus taas tarkoittaa vääjäämättä kalliimpaa jatkokehitystä ja kalliimpia palvelinkuluja. Mielestäni tämä voi olla perusteltua joissakin erityistapauksissa, mutta valtaosassa verkkosivustoja tällainen infra on kuitenkin yliampuva.
Tietoturva
Tietoturva on yksi headless-toteutusten myyntiargumentti. Hyökkääjät eivät pääse käsiksi piilossa olevaa WordPress-asennukseen. Tämä pitää paikkansa. Mikäli sivuston frontend toteutetaan esimerkiksi Next.js-kirjastolla, on taustalla oleva julkaisujärjestelmä käytännössä mahdollista piilottaa kokonaan. Tämä vähentää hyökkäyspintaa ja ratkaisu on turvallisempi.
Tämä ei kuitenkaan automaattisesti tarkoita, että perinteinen WordPress-toteutus olisi turvaton. Oikein ylläpidetty ja ajantasainen WordPress on turvallinen.
Toisaalta historia on osoittanut, että Javascript-maailma ei sekään ole mitenkään immuuni tietoturvaongelmille. Next.js:ssä on valtava määrä riippuvuuksia kolmannen osapuolen kirjastoihin ja myös näiden ajantasaisuudesta ja tietoturvasta on huolehdittava.
Mihin headless sitten soveltuu?
Headless-toteutukset ovat teknisesti hienoja ja mahdollistavat uusien teknologioiden kokeilun ja hyödyntämisen. Pidän itse erityisesti Reactin ja Typescriptin kirjoittamisesta ja Next.js on mielestäni hieno kirjasto. Headless-teknologia houkutteleekin erityisesti devaajia. En itse mitenkään erityisesti vihaa headless-projekteja. Mutta olen myös nähnyt aitiopaikalta sen, mitä markkinassa tapahtuu ja millaisia haasteita teknologia voi aiheuttaa.
Headless-toteutuksille on paikkansa ja mekin olemme niitä Evermadella tehneet. Headless soveltuu mielestäni erityisen hyvin suhteellisen staattisille sivustoille, joilla on merkittäviä skaalaustarpeita. Joissakin erittäin korkean tietoturvan projekteissa headless on oikea valinta mikäli huolehditaan siitä, että WordPress ei putkahda julkiseen verkkoon näkyville. Erityisen hyvin headless-soveltuu käyttötapauksiin, joissa sisältöä haetaan frontendiin useista eri lähteistä, jotka eivät juttele keskenään.
Suosittelisinko headless-toteutusta WordPress-markkinointisivustolle? Lähtökohtaisesti en. Headless-toteutuksissa on syytä varautua kalliisiin jatkokehityskustannuksiin, sillä asiat pitää tehdä pitkälti alusta alkaen itse. Myös WordPressin päivitysten tai uusien ominaisuuksien myötä on varauduttava siihen, että kehitystyötä tarvitaan. Toimittajan vaihto voi vaikeutua. Jotkut itsestäänselvältä tuntuvat ominaisuudet voivatkin olla työläitä.
Jos haluaa toimittajariippumattoman, ketterän ja joustavan markkinointisivuston pitkällä elinkaarella, suosittelen perinteistä verkkosivustoa.
