North Patrolin Perttu Tolvanen kritisoi Twitterissä edellistä Päätöntä menoa-kirjoitustani liiallisesta kehittäjävetoisuudesta ja asiakashyötyjen unohtamisesta, joten ajattelin avata Headless-innostuksemme taustoja hieman tarkemmin.

WordPress-kentässäkin on nyt headless-huumaa. Asiakaslähtöiseltä ei tosin kuulosta, koska tässäkin jutussa ainut asiakkaalle syntyvä hyöty on "parempi tietoturva". Suurin osa jutusta keskittyy siihen, että koodarit saa tehdä modernimmilla välineillä. https://t.co/wSXGl8uYQT

— Perttu Tolvanen (@perttutolvanen) August 19, 2019

Mitä tulee itse kirjoitukseen, myönnettäköön, että kyse oli ensimmäisen vaiheen kirjoituksesta, jonka tarkoituksena oli herättää kiinnostusta potentiaalisissa rekrytoitavissa, mutta myös muissa WP-taloissa, jotta tulevasta alustasta saadaan uskottava koko yhteisön juttu ja toivottavasti WP-innostusta laajennettua myös muihin teknologiataloihin.

Mutta. Henkilökohtaisesti innostus Headless-toteutuksiin syntyi kirjaimellisesti asiakaslähtöisesti. Ajauduimme tilanteeseen, jossa jouduimme kilpailutuksen kautta luopumaan asiakkaasta, joka halusi uudistaa sivuston alustalle, jossa sisällöntuotanto on rajattu organisaation sisäverkkoon ja sivuston julkinen osa julkaistaan toisaalle staattisena versiona, eikä meillä ollut tarjota ratkaisua asiakkaan tarpeeseen.

Tämän ja muutaman muun käytännön kokemuksen perusteella huomasimme, että on olemassa kokonainen asiakassegmentti, joka haluaa tuottaa sisältönsä maailman suosituimmalla julkaisujärjestelmällä, mutta pitää julkisen sivuston täysin erillään sisällöntuotantoympäristöstä.

Toisin sanoen huomasimme, että tietyissä erityistapauksissa Headless-teknologia on ratkaisu, joka ratkaisee asiakkaan oikean ongelman ja tuo WordPressin myös sellaisten asiakkaiden saataville, jotka eivät WordPressiä ikinä julkiverkkoon laittaisi.

Tietoturva on ehkä ilmeisin asiakashyöty, mutta lisäksi on tunnistettavissa myös muita hyötyjä, jotka hyödyttävät sekä asiakasta että loppukäyttäjää.

• Staattinen sivusto on nopeampi: parempi käyttökokemus käyttäjille, pienempi poistumisprosentti ja hyvä kasvualusta SEO:lle **
• Staattinen sivusto on paremmin saatavilla ylläpitäjille: ylläpitoon pääsee myös hyökkäyksen tai kovien kuormituspiikkinen aikana, koska se on erotettu loppukäyttäjille näkyvästä julkisesta versiosta. Esimerkiksi kriisiviestinnän kannalta tämä on elintärkeää.
• Staattinen sivusto on paremmin saatavilla loppukäyttäjälle: se voidaan julkaista ja hajauttaa globaaliin CDN:ään, jolloin se on käyttäjien saatavilla käytännössä 100%:n varmuudella.

** SEO-asioihin liittyy ennakkoluuloja, koska huonoista toteutuksista on varoittavia esimerkkejä. Toteuttamamme ratkaisu hyödyntää pre-renderingiä, mikä tarkoittaa sitä, että kaikille käyttäjille (ml. hakukoneet) tarjotaan palvelimelle tallennettu staattinen HTML-versio sivuista. Sivusto toimii siis myös ilman Javascriptiä. Jos jotain teknologiaa voidaan pitää hakukoneystävällisenä, niin nopeasti latautuva HTML-sivu on varmasti sitä.

Sisällöntuottajan kannalta ilmeisin hyöty hukkuu helposti: se, ettei sisällöntuottajan tarvitse opetella mitään uutta. Sisällöntuotantoon on käytössä samat tutut työkalut kuin ennenkin.

Uutta sen sijaan on, että sisällöntuottajalla on jatkuvasti käytössä ”esikatseluversio” sivustosta, mikä helpottaa laajempien sisältömuutosten tekemistä kerralla, kun muutokset voi tehdä rauhassa useampaan sisältöön ja julkaista ne kaikki yhtä aikaa. Kun tätä vertaa ns. normaalitilanteeseen, jossa sisältömuutokset tehdään sisältö kerrallaan ja julkaistaan välittömästi julkiseksi, sisällöntuottajan työrauha paranee merkittävästi.

Kuten Twitter-kommenteissa tuli ilmi, myöskin hyvät kehittäjätyökalut lopulta satavat loppuasiakkaan laariin parempana tuottavuutena, mutta olen Pertun kanssa (edelleen) samaa mieltä, että ne eivät saa ohjata teknologiavalintoja.

Headless-huumassa on siis hyvä muistaa, että kyse on erityisratkaisusta, joka ratkaisee erityisen asiakassegmentin erityisen tarpeen ja tekeekin sen erittäin hyvin.