Hodeløst / Headless CMS. Kanskje du ikke trenger det?
"Headless CMS", eller "hodeløst" publiseringssystem er en populær trend innen nettsideutvikling. Men hva betyr det egentlig, og er det noe din bedrift trenger? I denne artikkelen ser vi på fordeler og ulemper med headless CMS, og hvorfor det kanskje ikke alltid er den beste løsningen.
Hva er et Headless CMS?
Et headless CMS, eller “hodeløst” publiseringssystem, er et system som lagrer og organiserer innholdet ditt på en måte som skiller dataen fra selve utseendet, eller “hodet”, til nettsiden. I et tradisjonelt CMS, som WordPress eller Craft CMS, er data (som tekst, bilder og videoer) og det visuelle (hvordan nettsiden ser ut for brukeren) samlet i én løsning.
Med et headless CMS lagres innholdet uavhengig av hvordan det vises, slik at det samme innholdet kan brukes på flere ulike plattformer og enheter – for eksempel en nettside, en mobilapp, eller til og med en informasjonsskjerm på en flyplass. Alt dette kan hentes fra samme kilde, og hver enhet får det spesifikke innholdet den trenger.
Fordelene ved et headless CMS er altså først og fremst aktuelle for virksomheter som faktisk har behov for å publisere innhold på mange ulike plattformer. Har man kun en nettside som hovedplattform, vil et tradisjonelt CMS kunne dekke behovene på en enklere og mer kostnadseffektiv måte.
Headless, Fleksibilitet, Skalerbarhet
Det har aldri vært vanskelig å finne buzzwords i teknologibransjen. Headless er inget unntak, og la oss først og fremst ta for oss hva begrepet betyr.
Klassisk oppbygging av nettsider består av én server. Denne serveren hadde både data, datastruktur og det visuelle skallet (front-end) av nettsiden samlet. Noen kom opp med idéen om at kroppen metaforisk kunne ses på som data, og hodet som front-end (det visuelle). Grunnen til at hodet skulle kunne separeres fra resten, var at hodet i noen tilfeller kunne vise seg å være en nettside, men andre ganger være en App, eller kanskje en TV-skjerm på en flyplass.
So far so good. Tanken var altså at man begrenser server nr. 1 til kun struktur og data, så løses alt av visuell innpakning på annet vis (dersom vi fortsetter med tanken om nettside trenger man da altså en ekstra webserver for denne).
Fordeler uten nytteverdi
Selv om teorien om å separere data og visuell innpakning kan høres logisk ut, resulterer det i realiteten ofte i mer teknologi for samme resultat.
La oss f.eks si at Kunde AS har en nettside og publiseringssystem i dag, og ønsker ny nettside. Et byrå løfter frem headless system som beste valg fordi da har man også mulighet for utvidelser i alle retninger i fremtiden. Høres forsåvidt fint ut med mange muligheter, men i realiteten er det ikke basert på faktiske behov, og man kompliserer teknologien tidlig.
Tørr å stille spørsmålet; Hvilke konkrete fordeler får vi ved å gå over til et hodeløst CMS? Ikke i en potensiell fremtid, men her og nå.
Dårlige sammenlikninger
Artikler om fordeler med headless systemer sammenliknes ofte med Wordpress, eller liknende systemer som har begrensede muligheter for strukturert innhold. Noen ganger sammenliknes det også med Squarespace, Wix eller andre systemer som opererer i et annet prissegment.
I vår mening er no-code løsninger som Squarespace, Wix og Webflow ikke sammenliknbare. Disse er som regel i et mye lavere prissegment (Ofte under 100.000), mens nettsider med Headless systemer som Sanity, Contentful, Prismic, Payload eller liknende som regel er godt over dette prissjiktet.
Når det gjelder Wordpress, gjelder mye av samme argumentasjon, men de kan oftere være i liknende prissjikte. I disse tilfellene er det stor forskjell på hvor godt strukturert dataen kan være i en Wordpress side sett opp mot eksempelvis Sanity. Her er det ingen tvil om at Sanity har store fordeler. Allikevel må det ikke skyves under en stol at mange tradisjonelle CMS er vesentlig bedre på strukturert innhold enn Wordpress.
Dersom man eksempelvis sammenlikner Sanity med Craft CMS begynner mange av fordelene rundt strukturert data å falle gjennom. Og dersom man i tillegg ser at en del tradisjonelle CMS (som eksempelvis Craft CMS igjen) ikke bare kan brukes som monolittisk CMS (inkludert "hode"), så har de faktisk også muligheten til å brukes hodeløst dersom ønskelig.
Kort oppsummert: Vær varsom for sammenlikninger. Selv om et moderne hodeløst system ser mye bedre ut enn et utdatert "tradisjonelt" CMS, betyr det ikke at argumentet for et hodeløst system holder vann. Det finnes nemlig flere moderne CMS som ikke er headless-first.
Flere hoder krever ikke hodeløst system
Fordelen av hodeløse system illustreres ofte med at en kropp har mange hoder, hvorav hvert hode er egen kanal. Eksempelvis 1. nettside, 2. tv-skjermer i et bygg og 3. native app.
Det som ikke blir nevnt er at dette også er fullt mulig å gjøre uten bruk av hodeløst system. Igjen ref. forrige punkt har man i mange moderne CMS muligheten til å dele data via API punkter til alle mulige endepunkter, på akkurat samme vis som et hodeløst system kan. Den største forskjellen er bare at nettsiden allerede er inkludert i pakka ut av boksen. Et moderne, men tradisjonelt CMS (som Craft CMS) kan ses på som et hodeløst system som inkluderer et hode fra start, men fortsatt med mulighet for fler dersom ønskelig.
Buzz, trender, AI, Lindy effekt
Sanity er en naturlig snakkepunkt når det gjelder hodeløse systemer i Norge. Både fordi det er et norsk selskap, men også fordi de er bransjeledende innenfor området og utbredt i bruk på markedet. Sanity ble startet i 2018, og er med det et veldig ungt selskap. Dette trenger ikke nødvendigvis være negativt, men det er viktig å være klar over at Sanity har vokst i et enormt tempo, og har store internasjonale investorer involvert. De har hatt mye buzz, bruker penger på markedsføring og har etterhvert blitt et stort selskap med mange ansatte.
Det store spørsmålet er langsiktigheten i et slikt tilfelle. Hvor realistisk er det at et hodeløst CMS system skal kunne fortsette en slik vekstkurve? Og med investorer og kapitalismens krefter kombinert med at selskapet er ungt og fremadstormende, men samtidig i stor konkurranse – føles risikoen stor nok til at det bør vurderes som en faktor i vurderingsbildet.
Hva er "Lindy Effect" spør du?
Lindy-effekten er en teori om at ting som har eksistert lenge har større sannsynlighet for å vare enda lenger. Det betyr at systemer som har stått tidens test ofte er mer pålitelige.
AI og eierskap til data
I et headless CMS som Sanity blir dataen din lagret i det de kaller et 'Content Lake' på deres servere. Dette betyr at bedriften din ikke har full kontroll over hvor dataen lagres, noe som kan være en risiko om man ønsker full eierskap over sin informasjon.
Vi mener dette er problematisk. Du fortjener full kontroll og eierskap til din egen data. Ønsker du å ha full kontroll på din data, og ha det på en server av ditt eget valg, burde dette være mulig. Dessverre er ikke det mulig via Sanity. Som de sier selv: "The Sanity Content Lake is where your content is stored and accessed. It runs in the cloud and is fully managed by us".
Trekker man dette videre til AI (KI) debattene som foregår for tiden, og eierskap til data, så øker viktigheten av full kontroll på egen data. Mengdene data Sanity etterhvert vil sitte på i sine systemer blir stor, og hva de potensielt velger å gjøre med denne dataen er en faktor man har for lite kontroll over.
Bruker ikke Vasser hodeløse systemer?
Vasser er ikke prinsipielt imot hodeløse systemer, vi bare stiller oss kritisk til måten det fremstilles på i bransjen. Vi er opptatt av å få frem et mer nyansert bilde på saken, og noe av det verste vi vet er unødvendig kompleksitet. Vi har både jobbet med hodeløse prosjekter i Sanity, og i prosjekter hvor Craft CMS blir brukt hodeløst.
Vi mener allikevel at det ytterst sjeldent er en nødvendighet for et prosjekt, og at det nesten alltid gjør prosjekter både mer komplisert og dyrere, både på kort og lang sikt.
Oppsummering
Et headless CMS kan være et godt valg for større bedrifter med komplekse behov og mange kanaler. Men for mindre bedrifter eller enklere prosjekter kan et tradisjonelt CMS være mer enn tilstrekkelig – og langt enklere å bruke.