Headless CMS -tuotteet Suomessa ja muissa Pohjoismaissa

Suomessa Contentful on kiistaton pioneeri tällä alueella, ja tämä historia näkyy tämänkin selvityksen tuloksissa. Contentfulin osuus on selvästi suurempi kuin muilla kilpailevilla ratkaisuilla. Sama tilanne on muissakin Pohjoismaissa, Norjaa lukuunottamatta. Norjassa kotikentältä ponnistava Sanity on yleisin ratkaisu. Contentfulin pitkä historia ja panostukset paikalliseen edustukseen näkyvät kuitenkin hyvin tässä katsauksessa.

Allekirjoittanutkin on haastatellut Contentfulin toimaria ensimmäisen kerran vuonna 2014 Berliinissä, joten historiaa on jo kertynyt kohtuullisesti.

Viime vuosina Contentful on saanut osakseen paljon kilpailijoita, mutta monet tämän alueen työkalut ovat jääneet tähdenlennoiksi tai hiipuneet hyvin kapean asiakaskunnan työkaluiksi. Nyt ehkä aivan viime vuosina on norjalainen Sanity nostanut ainakin täällä pohjoisessa hieman päätään, mutta Sanitynkin asiakaskunta on vielä varsin pieni verrattuna Contentfuliin.

>> Lue North Patrolin datakatsaus: Rajapintalähtöiset CMS-tuotteet Pohjoismaissa

Headless CMS:t ovat täsmäratkaisuja räätälöityjen palveluiden sisällönhallintaan

Maailmanlaajuisesti Contentfulin tunnistetut sivustot ovat 40 000 sivuston luokkaa, Sanityn jäädessä noin puoleen tästä luvusta. Esimerkiksi jos tätä vertaa vaikka HubSpottiin, on HubSpotin vertailuluku huomattavasti isompi, noin 120 000 sivustoa. Täten lukumääräisesti asioita katsoen, ovat nämä headless CMS -tuotteet maailmallakin edelleen hyvin vahvasti täsmätyökaluja erityistilanteisiin.

Todellinen kilpailu tuleekin perinteisempien julkaisujärjestelmien ja verkkokauppa-alustojen suunnasta. Suomessakin kovin kilpailija lienee WordPress, joka on varmasti esimerkiksi Contentfulia isompi alusta headless-kentällä, jos lasketaan sivustojen määriä. Myös Drupalia käytetään headless-tyyppisesti varsin paljon. Osa headlessistä innostuneista tahoista kokeekin nämä kaupalliset tuotteet outoina ratkaisuina tällaisessä arkkitehtuurissa, koska jos arkkitehtuurin idea on vähentää sen CMS:n merkitystä ja siirtää se taustalle, miksi siitä pitää maksaa enemmän kuin aiemmin?

Saman ihmettelyn voi tehdä myös toiminnallisesta näkökulmasta, koska moni näistä tuotteista on vielä aika paljon jäljessä monia perinteisempiä CMS-ratkaisuja. Hinnoittelu saattaa kuitenkin olla isoissa ympäristöissä jo varsin kova (esim. Contentful), tai sitten todelliset hinnat ovat vielä selviämättä, koska asiakashankintaa tuetaan niin paljon riskirahalla (esim. Sanity).

Headless-tyyppinen mallihan ei käytännössä mitenkään edellytä erityistä headless CMS -tuotetta, koska käytännössä lähes kaikki julkaisujärjestelmät pystyvät tukemaan tällaista toteutusmallia. Headless CMS -tuotteiksi itseään kutsuvat tuotteet ovatkin käytännössä aina tuotteita, jotka ovat vain alusta asti luotu tukemaan pelkästään tällaista arkkitehtuurimallia, jossa sisällönhallintajärjestelmä jätetään taustalle, pelkkään sisältöpalasten hallintaan. Ne eivät siis ole mitenkään olennaisesti erilaisia tuotteita, kuin perinteisemmät julkaisujärjestelmät. Ne ovat yleensä vain yksinkertaisempia tuotteita, jotka tarjoavat sisällöt rajapintojen kautta ja jättävät varsinaisen esityskerroksen rakennettavaksi projektissa erikseen.

Asiakkaan kannalta headless ei todellakaan ole headless

Asiakkaiden kannalta se isompi keskustelu pitäisikin aina olla se, että tarvitsemmeko ja haluammeko sitoa itseämme toteutukseen, joka perustuu johonkin Javascript-kehyksellä toteutettavaan täysin räätälöityyn esityskerrokseen. Se, mikä headless CMS -tuote meillä on sen Javascript-pohjaisen verkkopalvelun takana, on huomattavasti pienempi ja ehkä jopa vähemmän merkityksellinen keskustelu. Ja tämä sama pätee vaikka Javascript-kehyksen sijasta ajatus olisi julkaista verkkopalvelu staattisena html-versiona hyödyntäen jotain sivustogeneraattoria tai vastaavaa ratkaisua.

Headless-termihän on ehdottomasti yksi oudoimmista slangitermeistä, joita tämä ala on kehittänyt. Jollain tavallahan se asiakkaille näkyvä palvelu pitää kuitenkin rakentaa, oli CMS:stä apua tai ei. Asiakkaiden näkökulmasta headless CMS on tavallaan auto ilman moottoria. Kyllä, se on halvempi, se on kevyempi, se ei kuormita ympäristöä, ei tarvitse lataamista, ja niin edelleen.

Useimmat asiakkaat kuitenkin haluavat autonsa jonkun moottorin kanssa, joten siksi pitäisi aina puhua myös siitä, että miten ne asiakkaille näkyvät verkkopalvelut sitten tehdään, jos CMS on mallia headless.

Alan toimistoille ja kehittäjille headless on kutsu buffet-pöytään

Toimistojen ja monien kehittäjien näkökulmasta headless-mallit ovat myös suhteettoman houkuttelevia, koska käytännössä kysymys on räätälöityjen ratkaisujen rakentamisesta uusimmilla vehkeillä mitä maailmasta löytyy. Liiketoiminnan näkökulmasta jokainen headless-projekti on helposti 2-3 kertaa isompi asiakkuus kuin perinteisen mallin vastaava projekti. Kehittäjien näkökulmasta jokainen headless-projekti on myös keino päästä tutustumaan uusimpiin tekniikoihin ja harjoittelemaan erilaisten rajapintojen ja sovelluskehysten kanssa työskentelyä. Monelle toimistolle tämä kehittäjien innostus on myös tärkeä tekijä, koska koodareiden korkea vaihtuvuus aiheuttaa nopeasti isoja ongelmia.

Ehkä juuri siksi moni toimisto näkee paljon vaivaa sen eteen, että yrittää keksiä headless-arkkitehtuurille hyötyjä myös asiakkaiden näkökulmasta. Valitettavasti se on aika hankalaa, eivätkä useimmat väitteet oikein kestä vettä.

Toimistot julkaisevat ahkerasti headless-mallia ylistäviä juttuja

Parin viime vuoden aikana on oikein kilpailtu sillä, että mikä toimisto julkaisee enemmän headless-mallia käsitteleviä blogiartikkeleita. Yhdistävä tekijä useimmille näille jutuille on lähes täysi kritiikittömyys mallia kohtaan. Tässä muutamia poimintoja alan toimistojen julkaisemista jutuista

Nitron juttu on alle vuoden ikäinen artikkeli, joten ennakko-oletus oli, että ehkä tässä olisi jo huomioitu hieman alalla käytyä keskustelua. Nitro ei kuitenkaan ole tällaiseen eipäs-juupas-väittelyyn lähtenyt, vaan ylistää headlessiä täysin kritiikittömästi: Miksi valita headless CMS? (Nitro, 23.3.2022)

”Headless CMS ja sivustogenerointi tarjoaa yrityksille (ja Nitron kaltaisille hybriditoimistoille) vapaat kädet suunnitella juuri sellaisen verkkopalvelun, jonka haluatte. Toteutusta ei rajoita teemat tai templatet, jotka on saneltu jostakin ylempää. Esimerkiksi verkkopalvelun käyttökokemus, saavutettavuus ja hakukoneoptimointi voidaan viedä aivan uudelle tasolle.”

Nitro on tässä omalla tavallaan suorastaan rehellinen. Headless todellakin tarjoaa vapaat kädet toimistoille suunnitella, toteuttaa, laskuttaa ja viedä moni asia aivan uudelle tasolle (ei välttämättä tosin paremmaksi).

Tietotalon artikkeli headless-arkkitehtuurista myös listaa pelkästään positiivisia asioita mallista, aivan kuin se olisi uudenlainen, täysin päästötön energiamuoto.

”Headless CMS -toteutustavan keskiössä on rajaton suunnittelu ja sujuva sisällönhallinta.

Headless CMS vapauttaa luomaan käyttäjäkokemukseltaan ainutlaatuisia palveluita, joissa voi yhdistellä niin sovellusmaisia toimintoja kuin eri datalähteitäkin. Tämä avaa lukemattomia mahdollisuuksia ja esimerkiksi sovelluksia tai verkkokauppaa voidaan rikastaa erilaisilla elämyksellisillä ja sitouttavilla sisällöillä.

Päättömissä järjestelmissä sisältörakenteita ja sisältötyyppejä voidaan luoda asiakkaan yksilöllisiin tarpeisiin rajattomasti. Samalla voidaan kehittää organisaation sisäisiä työnkulkuja ja yhteistyötä.”

Konkreettisuuden taso on sitä luokkaa, että kritiikkiä on oikeastaan vaikea edes esittää. On tietysti ymmärrettävää, että kun pohjimmiltaan kyse on siitä, että tehdään täysin räätälinä jotain, niin sehän voi sitten ollakin ihan mitä tahansa, joten kaipa sen hyödytkin voivat sitten olla mitä tahansa.

Pixelsin juttu parin vuoden takaa käsittelee aihetta perusteellisesti, mutta myös pääosin positiivisesti.

”Headless CMS vapauttaa suunnittelijoiden ja toteuttajien kädet luomaan ainutlaatuisia verkkopalveluita, joissa voi saumattomasti yhdistellä sovellusmaisia toimintoja, eri datan lähteitä ja interaktiivisia ominaisuuksia piittaamatta taustajärjestelmän rajoitteista.”

Tässä on hieman sama teema kuin edellisessä jutussa. Kaikki on paremmin, kun ei käytetä mitään tuotteita, eivätkä sisällöntuottajien vaatimukset pääse sotkemaan luovaa toteutusta.

Pixelsin jutun ansioksi voi kuitenkin sanoa sen, että juttu on kohtuullisen konkreettinen, sanoen aika tarkkaan sen, että mistä ne hyödyt oikein syntyvät.

”Verkkosivut voidaan esimerkiksi tarjoilla staattisen sivugeneraattorin luomina selaimelle. Toisin sanoen staattisia html-sivuja ja niiden sisältöjä, tyylejä ja kuvia ei tarvitse erikseen ladata palvelimelta. Ratkaisu mahdollistaa sen, että staattisella sivulla kaikki tieto on jo valmiina, mikä tekee sivuista äärettömän nopeita latautumaan. Tästä on hyötyä varsinkin käytettävyyden ja hakukoneoptimoinnin näkökulmasta, etenkin kun Googlen algoritmit nostavat nykyään sivuston latausnopeuden ja käytettävyyden entistä korkeampaan arvoon.

Headless-ratkaisussa kaikki data kulkee rajapinnan läpi, joka tarkoittaa että sisällönhallintajärjestelmään ei ole suoraa pääsyä käyttöliittymästä. Tämä tuo mukanaan merkittäviä tietoturvahyötyjä, kuten esimerkiksi vähentämällä taustahallinnan ylläpidon kirjautumisnäkymään kohdistuvia hyökkäyksiä.”

Staattisten sivujen hyötyjen korostaminen on monessa jutussa toistuva teema. Kovin moni ei kuitenkaan käytännössä käytä tätä mallia. Pixelsinkin artikkelissa todetaan myöhemmin, että heidän yleisin ratkaisu perustuu React-fronttiin. Tämäkin on yksi tämän aihepiirin kummallisuus. Asiakkaiden kannalta staattisten html-sivujen jakelu olisi yleensä malli, josta olisi enemmän käytännön hyötyjä, esimerkiksi hakukoneiden ja tietoturvan ja elinkaaren näkökulmasta.

Oma lukunsa ovat myös tietyn tuotteen ylivoimaisuudesta puhuvat toimistot, jotka yleensä kehuvat valittua tuotetta ylivertaisena ratkaisuna melkein mihin tahansa ongelmiin. Esimerkiksi Lamia on kirjoittanut useita juttuja Contentfulin ylivertaisuudesta ja soveltuvuudesta lähes mihin tahansa.

”Tiivistyksenä voidaan sanoa, että Contentful ja sen sisällönhallintajärjestelmän headless-lähestymistapa antaa mahdollisuuden viedä sisällön luominen ja hallinta pilvipohjaiseen prosessiin. Tämä puolestaan helpottaa kokonaisuutta poistaen teknisiä esteitä, jolloin voidaan keskittyä oleelliseen, eli tuoda käyttäjille parempaa sisältöä nopeammalla vauhdilla ja oikea-aikaisemmin.”

Suomessa etenkin Contentfulin ympärillä on jonkin verran tämäntyyppistä hypeä ollut viime vuosina. Osa näistä on myös lievän komiikan puolella olevaa tavaraa, kun huomioi että esimerkiksi verkkokauppamaailmassa Contentfulin käyttöönotto on yleensä hyvin pieni osa kokonaisprojektista, mutta toimittajan myyntipuheissa se voi näyttäytyä aivan mullistavana ja uudenlaisena ihmeratkaisuna.

Devisioonan artikkeli vuodelta 2021 aiheesta kuuluu ehdottomasti parhaimpiin juttuihin, joita toimittajapuolella on julkaistu. Juttu osaa käsitellä headless-arkkitehtuuria kriittisestikin, jopa pohtien sille sopivimpia käyttötapauksia.

”Moni toimittaja alalla puhuu headlessin puolesta lähes varauksettomasti. Devisioonan kokemukset viimeaikaisista asiakasprojekteista ja konsultointihankkeista kannustavat kuitenkin varovaisuuteen: Headlessin edut toteutuvat vain, jos niitä käytetään vastuullisesti ja niihin soveltuvissa hankkeissa. Valitettavasti IT-alalla on usein tapana lipsua kaidalta polulta.

Kehittäjäkokemuksen houkuttelevuus – mahdollisuus päästä tekemään töitä uusilla välineillä ja tavoilla – on ajoittain muuttunut itsetarkoitukseksi, ja lopputuloksena palveluiden kustannukset kasvavat, arkkitehtuuri monimutkaistuu ja toimintojoukko jää suppeammaksi kuin valmistuotteiden pohjalta.

Toisaalta rehellinen ja avoin tekninenkin analyysi on paikallaan: joissain tilanteissa voi olla, että esimerkiksi vanhakantainen verkkokaupan ulkoasukustomointi on niin hankalaa, että hyvin valmistautunut toimittaja tempaisee headless-ratkaisun pystyyn nopeammin kuin perinteisen täyden paketin toteutuksen. Tämä pitää paikkansa varsinkin, jos asiakkaan ulkoasu- ja toiminnallisuusvaatimukset eroavat tuotteen peruslinjoista. Näissäkin tapauksissa headlessin varjopuolena tulee mukana monimutkaisempi arkkitehtuuri, mutta tämä saattaa silti olla vaivan arvoista.”

Kovin kriittinen ei tosin Devisioonakaan ole, koska heidän näkökulmansa ovat hyvin toiminnalliset sovellukset, ja yleensähän headless-mallit toimivat aika hyvin silloin kun tehdään esimerkiksi jotain monimutkaista asiointipalvelua.

Valu Digital on myös toimisto, joka on kunnostautunut kirjoittamalla konkreettisia juttuja heidän käyttämästään headless-mallista. Valu kuuluu myös siihen hieman harvinaisempaan joukkoon, jonka headless-malli (Valu kutsuu malliaan Headup-malliksi) tuottaa nimenomaan staattisia sivuja lopputuloksena. Valun viimeisin artikkeli toteaa, että Valulla headless on nimenomaan tapa tarjota asiakkaalle korkeata tietoturvaa tilanteissa, joissa on todellisia riskejä siihen, että joku vihamielinen taho pyrkii estämään sivuston käytön tai pyrkii tekemään muuta haittaa sivustolle.

”Olemme pitäneet Headupin kohdalla tiukasti kiinni parista myyntiperiaatteista. Emme myy Headupia ”normaalina WordPressinä” asiakkaille, joilla ei oikeasti ole tarvetta huippukorkealle tietoturvalle ja kuormankestolle. Pystymme toteuttamaan erittäin korkean tietoturvan ja kuormankeston ratkaisut myös perinteisellä WordPressillä edistyneiden välimuistiratkaisujen avulla. ”

Tämä onkin hyvin sanottu, osaavat WordPress-toimittajat pystyvät pääsemään erittäin korkeatasoisiin toteutuksiin ihan ”tavallisilla” malleilla, eikä tällöin synny headless-toteutusten ongelmia sisällöntuotannon, kustannusten tai elinkaaren näkökulmasta.

Valun juttu tiivistää asiaa hyvin jutun lopussa:

”Lopuksi on hyvä korostaa, että Headup on erityisratkaisu poikkeuksellisiin tarpeisiin. Edelleen 95%:lle verkkosivustoista perinteinen WordPress-sivusto hyvin suojattuna ja välimuistitettuna on oikea ratkaisu. Headup puolestaan sopii, kun tarvitaan kustannustehokasta rajatonta skaalautumista ja korkeimman luokan tietoturvaa.”

Tämän näkökulman voi allekirjoittaa. Etenkin staattisina html-sivuina tehtävä sivusto skaalautuu mihin tahansa kuormapiikkeihin, oli sitten kyse Euroviisuista tai ydinräjähdyksestä tai pommi-iskusta tai mistä tahansa tapahtumasta, jonka seurauksena miljoonat ihmiset suuntaavat jonkun yksittäisen sivuston äärelle. Toinen näkökulma on juuri se äärimmäisen tietoturvan vaatimus. Jos halutaan käyttää kaikki keinot äärimmäisen tietoturvan toteuttamiseksi, on headless-tyyppinen malli, etenkin niillä staattisilla html-sivuilla tehtynä, varmasti vähemmän altis tietoturvaan liittyville virheille, joiden seurauksena jokin vihamielinen taho voisi kaapata sivuston tai sotkea paikkoja.

Kaikki tämä tietenkin myös maksaa, ja siksi Valukaan ei yritä tarjota heidän malliansa kaikille asiakkaille. Mallia tarjotaan niille asiakkaille, joiden vaatimukset ovat aidosti erityisiä ja joilla on varaa maksaa vaatimusten toteuttamisesta. Usein näiden asiakkaiden tarpeisiin ei myöskään kuulu joustavat vaatimukset digimarkkinoinnille sivuston optimointiin ja uusien laskeutumissivujen toteutukseen, joten kankeamman mallin haitat eivät tule silmille.

Ala on vaikeassa vaiheessa: vanha malli on osittain vanhanaikainen, uusi malli on vielä täysin epäkypsä

Täysin ei toimistoja voi syyttää käärmeöljyn myymisestä, koska Javascriptin merkitys on ilman muuta kasvussa, samoin esimerkiksi staattinen html-julkaisu on hyvä asia saada takaisin. Eikä julkaisujärjestelmien päälle kannata kaikkea mahdollista rakentaa, siitä on ihan hyvä ymmärrys alalla. Uudenlaisille malleille on siis tarvetta, mutta selvää on myös, että vielä ei olla siinä pisteessa, että nämä uudet mallit olisivat aina asiakkaidenkin kannalta järkeviä.

Esimerkiksi räätälöityjen sovellusten rakentaminen julkaisujärjestelmien päälle ei yleensä ole kovin järkevää, joten mitä monimutkaisempi oma verkkopalvelu on, sitä enemmän kannattaa harkita arkkitehtuurimalleja, joissa ei rakenneta kaikkea yhden kortin varaan. Joskus on myös aidosti tilanteita, joissa samat sisällöt pitää julkaista mobiilisovellukseen ja verkkopalveluihin, jolloin sisällönhallinta on ehkä syytä irrottaa yksittäisestä palvelusta omaksi saarekkeekseen.

Internet-palveluiden tekeminen siis monimutkaistuu ja moninaistuu koko ajan. Erilaiset tilanteet tarvitsevat erilaisia ratkaisuja, mutta tämä ei tarkoita sitä, että aiemmin toimivista ratkaisuista täytyisi luopua kokonaan. Eivät julkaisujärjestelmät esimerkiksi ole mihinkään häviämässä, vaikka moni kehittäjä saattaa näin toivoakin. Asiakkaiden kannalta katsottuna julkaisujärjestelmiä ja monia muita tuotteistettuja ratkaisuja tarvitaan jatkossakin, ehkä jopa enemmän kuin aiemmin. Rinnalle vain tulee paljon muutakin, ja näissä astetta monimutkaisemmissa tarpeissa saatetaan yhä useammin päätyä headless CMS -tuotteen asiakkaaksi.

On vain tunnistettava oikein ne hetket, kun näin kannattaa tehdä. Yhä useammin isot kokonaisuudet rakentuvat myös useista erilaisista palasista. Joku palanen voi tarvita headless CMS:n kaverikseen, ja joku toinen palanen viihtyy hyvin WordPressin päällä, esimerkiksi.

Asiakkailta vaaditaan paljon ymmärrystä, ehkä liikaakin

Täten nyt ollaan tilanteessa, jossa asiakkailla on ajoittain aika hankalia päätöksiä tehtävänään. Toisella puolella on vaihtoehto olla ”vanhanaikainen” ja tehdä sivusto WordPressillä tai Drupalilla tai jollain muulla alustalla. Toisella puolella taas on ”moderni” malli, jossa käytännössä tehdään räätälöity ratkaisu, josta maksetaan helposti 2-3 kertainen summa rahaa, ja lisäksi sitoudutaan räätälöidyn ratkaisun tuomaan kalliiseen ja haastavaan ylläpitovaiheeseen.

Ainakin toivoisi, että useampi asiakas ymmärtäisi, että alan toimistot eivät suinkaan ole puolueettomia neuvonantajia näiden ratkaisujen äärellä. Toimistojen kannalta on aina todella paljon parempaa liiketoimintaa puoltaa näitä ”moderneja” malleja, koska nämä tuovat aivan eri tavalla rahaa taloon. Se, että onko ratkaisusta asiakkaalle todellista hyötyä, on kuitenkin lopulta aina asiakkaan murhe, ei toteuttavan toimiston.

Lue lisää: Web-sovellukset ja näiden tekniikat – kaikki artikkelit Vierityspalkissa

—

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä mobiili- tai verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee web- ja mobiilikehityksen teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja erilaisten digipalveluiden jatkokehityksen suunnittelussa.