Headless-väittelyyn maustetta WordPress-kentältä
Jaakko Alajoki Evermadelta osallistuu alalla vellovaan headless-keskusteluun esittämällä väitteen, että markkinointisivustoille ei pitäisi headless-mallia käyttää. Toinen Alajoen argumentti liittyy headless-maailman vakiintumattomuuteen: ei ole ekosysteemejä joihin nojata.
Aktiivisimmat headless-mallin puolustajat ovat olleet aina räätälikoodaamista muutenkin edustavia tahoja, ja kuten tässä blogissa on usein huomautettu, on tällöin niin sanotusti oma lehmä ojassa. Headless-urakat ovat isoja, monimutkaisia ja sopivat räätälitekemistä muutenkin suosiville koodaritiimeille, ja osittain siksi heidän on helppo myös puhua tämän mallin puolesta.
Samalla tavalla WordPress-urakat sopivat parhaiten kokeneille WordPress-toimistoille. Täten Evermaden Jaakko Alajoki ei ole mitenkään puolueeton argumentoija tässä asiassa, mutta kuten aiemmissakin artikkeleissa, argumentteja kannattaa tarkastella joskus myös irrallaan niiden esittäjistä. Aivan kokonaan ei toki kannata irtautua taustan vaikutuksesta. Evermade on WordPress-kentän isoin kissa, yli neljän (4) miljoonan euron WordPress-liikevaihdolla. Heidän liiketoiminnallinen intressi on puolustaa WordPress-tekemistä henkeen ja vereen.
No niin, se siitä, sitten argumentteihin.
Alajoki kiteyttää artikkelissaan hyvin headless-kentän keskeiset myyntiväitteet, kuten latausnopeuden ja turvallisuuden, mikäli headless-malli on toteutettu laadukkaasti.
“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.”
Tämän teoreettisen, ja joskus käytännössäkin, toteutuvan todellisuuden kääntöpuolena Alajoki toteaa olevan headless-toteutuksiin liittyvät laatutasovaihtelut.
“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ä.”
Tästä ongelmasta on tässäkin blogissa kirjoitettu aiemmin, koska esimerkiksi myös North Patrol on havainnut saman ilmiön. Headless-toteutukset ovat keskimäärin huomattavasti monimutkaisempia ja teknisesti vaativampia kuin isotkaan WordPress- tai Drupal- tai Optimizely-toteutukset. Tämä taas altistaa nämä hankkeet huomattavasti isommille riskeille, ja jos tekijätiimi ei ole erityisen kokenut, on lähes varmaa, että ongelmia tulee. Tämä ei tee mallia huonoksi, mutta se tekee sen huomattavasti riskialttiimmaksi.
Alajoki kritisoi artikkelissaan myös monien headless-toteutusten laatua. On tosiaan ironista, että moni headless-toteutus on varsin hidas loppukäyttäjälle. Usein hitaus korostuu ensimmäisellä latauksella, joskus hitaus jatkuu läpi koko sivuston, ja etenkin jos käytetään vähän vanhempaa mobiililaitetta tai tietokonetta.
Sivustojen nopeushan on aina ollut enemmän asia, joka liittyy tekijöiden osaamiseen kuin valittuun toteutusmalliin. Jos tekijätiimi on kokenut webin tekijä ja ollut virittämässä monia isoja sivustoja nopeiksi, osaa kyseinen tiimi todennäköisesti virittää minkä tahansa sivuston nopeaksi. Asiakkaiden kannattaisikin kiinnittää huomattavasti enemmän huomiota toimistojen referensseihin tässä asiassa, kuin siihen mitä he myyntipuheissaan sanovat.
Myös paremman tietoturvan väite on osittain ontuva käytännössä. Headless-sivustoja tehdään hyvin monilla eri malleilla ja erikoinen toteutusmalli altistaa aina riskeille. Toki jos ympäristöt on hyvin eriytetty, ovat isot tietomurrot vaikeampia. Sivustojen sotkeminen tai rampauttaminen on kuitenkin myös ihan yhtä mahdollista headless-malleissa. Sisältöjen hallintajärjestelmään murtautuminen ei suinkaan ole ainut tapa sotkea asioita, ja tämä tuntuu jatkuvasti unohtuvan headless-toimittajilta, kun he myyvät kaksitasoisen arkkitehtuurin etuja.
“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.”
Alajokikaan ei pidä headless-mallia täysin tuomittuna, mutta selvästi Evermaden teknisen johtajan pöydällä on näkynyt varsin paljon tilanteita, joissa headless-malli on tehnyt markkinointitiimin elämästä vain hankalampaa.
“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ä.”
Esimerkiksi asiointisivustoihin tai mihin tahansa hyvin asiakaskohtaiseen toteutukseen, kannattaa harkita headless-mallia, koska jos sisällönhallinta ei korostu, ei välttämättä kannata rakentaa sivustoa julkaisujärjestelmän päälle. Sama logiikka pätee verkkokauppapuolella. Jos hallintavälineet ovat muualla, voi verkkokauppa olla headless-tyyppinenkin, mutta jos kauppaa halutaan optimoida, pyörittää ja toteuttaa vaativia markkinointioperaatioita, kannattaa palvelu yleensä rakentaa jonkun aiheeseen erikoistuneen järjestelmän päälle.
Ja etenkin markkinointisivustojen kohdalla on syytä olla hyvin tarkkana, että ei päädy tilanteeseen, jossa uuden sivuston kanssa toimiminen onkin hankalampaa ja kalliimpaa, vaikka myyntipuheissa kaiken pitikin olla mahtavaa, helppoa ja ihanaa.
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
