Vad är Headless CMS?

Innehållet är bara innehåll

Ett Headless CMS tar bara hand om innehåll - det är helt skiljt från design, funktioner och mallar. Innehållet blir därmed plattformsobereonde och via ett API kan man presentera det genom vilket gränssnitt som helst.

Vanliga CMS-verktyg som Umbraco, Optimizely och Wordpress består av bägge delar; dvs innehåll samt utseende, funktioner och mallar.

---

Vi får ofta frågor från våra kunder om headless som “Vad är ett headless CMS?” och “Behöver vi ett headless CMS i vårt kommande projekt?” Vi älskar bra frågor och vi kan mycket om både headless och traditionella CMS och ska försöka besvara de sju vanligaste frågorna här.

1. Varför heter det headless? 

Ordet Headless syftar på att CMS:et levererar information till ett annat system som presenterar informationen för besökaren. Analogin är alltså att det är huvudet som kommunicerar informationen till användaren och i ett headless-CMS har man alltså kapat bort huvudet.

Tänk dig att det tekniska system som du använder för att publicera innehåll på webben är en person:

• I benen har vi själva administratörsdelen, dvs. det ställe där du som redaktör loggar in, skapar sidor, skriver texter och laddar upp bilder.
• I kroppen sparas allt innehåll, i en databas eller som filer.
• Huvudet är det som kommunicerar, dvs. webbplatsen där ditt innehåll visas för besökarna.

Om vi plockar bort huvudet på vår CMS-person så har vi kvar benen för administration och kroppen för datalagring. Vi behöver fortfarande ett huvud för att kunna kommunicera, det är bara det att det inte finns inbyggt i CMS:et.

Istället exponerar ett headless-CMS data via ett API som en annan applikation (ett annat huvud) kan använda för att kommunicera.

Eftersom innehållet bara är data så kan man kommunicera denna data på vilket sätt man vill - som en webbplats, en chattbot, en butiksskärm eller en mobilapp. Man är inte begränsad till ett huvud - kroppen kan alltså ha flera huvuden samtidigt.

Det heter alltså headless för att man plockat bort den del i CMS:et som genererar sidor (huvudet).

 

2. Är ett headless-CMS bättre än ett traditionellt CMS?

Nej. Det går inte att jämföra på det sättet.

Headless är ett svar på ett behov som uppstått under senare år - att kunna skilja mellan administration av information och hur den presenteras. Anledningarna är flera:

• Det ger stor flexibilitet i samband med utveckling av nya tjänster. Med ett headless-CMS är du inte bunden till CMS:ets tekniska bas utan kan bygga nya tjänster i vilken teknisk plattform du vill, så länge den kan kommunicera med ett API. Tjänsterna kan ändras och byggas ut utan att behöva ändra i CMS:et eftersom de är åtskilda.
• Att snabbt kunna administrera och kommunicera samma information via flera parallella kanaler. Besökare möts av samma budskap oavsett om det är på en webbsida, en app, en chatbot eller på en smartklocka. Ändra på ett ställe och det går det ut i alla kanaler samtidigt.
• Moderna tjänsteorienterade webbplatser är ofta interaktiva och applikationslika. Interaktivitet kan skapas med JavaScript - ju mer interaktivitet, desto mer JavaScript. När gränsen är nådd då mängden JavaScript överstiger vanlig HTML är det mer effektivt att bygga allt i JavaScript och då kan ett traditionellt CMS kännas mest som det är i vägen.

 

3. Vad innebär headless för en redaktör?

Medan det finns givna fördelar skapar samtidigt headless-arkitekturen nya problem. Redaktörer som är vana vid att arbeta parallellt med både informationen och hur den presenteras, direkt i CMS:et, kan känna sig lite bakbundna av headless-arkitekturen. Redaktören kan fortfarande ange vad som är rubrik, ingress och brödtext på en sida även med ett headless-CMS. Däremot kan det bli problematiskt om redaktören vill kunna bygga upp egna sidlayouter baserade på moduler eller styra över spaltindelning, positionering etc.

Ur ett principiellt perspektiv är det problematiskt att koppla ihop information med instruktioner för hur den ska presenteras eftersom man då börjar "smutsa ner" den datamodell som ska bestå av presentationsneutral information med information som styr hur informationen ska presenteras i en specifik kontext. Ger man sig in på den banan så har man börjat skapa hinder för att kunna återanvända samma information i helt nya kontexter.

Ur ett praktiskt perspektiv är det problematiskt eftersom man förmodligen har valt fel CMS. Om man som redaktör vill kunna ha stor dynamisk kontroll över inte bara informationen utan även presentation och layout direkt i CMS:et så bör man välja ett CMS som möjliggör detta från början. Sannolikheten är då att det är ett traditionellt CMS snarare än ett headless-CMS man vill ha.

Puffar, block, spalter och layouter är inte alls lika självklara begrepp i ett headless-CMS som de är i ett traditionellt CMS eftersom de primärt handlar om hur information presenteras. En webbplats byggd med ett headless-CMS kan definitivt ha allt detta, men det är inte i CMS:et som utseende och layout styrs. Det görs i den tekniska lösning som hämtar data från headless-CMS:et. Vill man göra designändringar där behöver man koppla in utvecklare.

 

4. Måste man ha ett headless-CMS för att ligga i framkant tekniskt?

Nej.

Både traditionella- och headless-CMS följer med i den tekniska utvecklingen. Den ena lösningen är inte mer tekniskt avancerad än den andra och det är inte så att all nyutveckling och teknisk brilljans automatiskt kanaliseras till headless-CMS:en. Däremot är marknaden för traditionella CMS mogen och etablerad sedan länge medan fenomenet headless och det tekniska ekosystem som uppstått kring det bör anses som relativt nytt. Därmed pratas det mer om headless vilket gör att man kan få uppfattningen att det är där (och bara där) det skapas nya spännande möjligheter.

Man väljer alltså inte gammal teknik bara för att man väljer ett traditionellt CMS. Man ska välja CMS baserat på nuvarande och framtida behov.

 

5. Kommer headless-CMS att ersätta traditionella CMS på sikt?

Nej. Vi tror att frågan är fel ställd.

Tekniska lösningar tenderar att forma sig efter behov. Vi vet att det finns ett starkt behov av att kunna administrera digital information både nu och i framtiden. Både headless-CMS och traditionella CMS är lösningar framtagna som ett svar på det behovet. Likheterna mellan headless-CMS och traditionella CMS är alltså fler än skillnaderna just för att de har sin utgångspunkt i samma behov. Att då ställa dem mot varandra och försöka kora en framtida vinnare blir för kategoriskt.

Om vi ska försöka oss på en gissning så är det mest sannolika att de olika varianterna av CMS flyter ihop med tiden så att man i samma CMS kan välja om man vill bygga sin lösning med ett renodlat data-API eller generera sidor utifrån sidmallar, eller ha en hybridlösning. Denna typ av flexibilitet tror vi kommer att efterfrågas av både kunder och utvecklare. För ett företag som utvecklar ett CMS borde det vara attraktivt att ha en bred marknad där en kund kan välja deras CMS oavsett om de vill ha ett API eller generera sidor.

 

6. Är det dyrare att bygga en webb med ett headless-CMS jämfört med ett traditionellt CMS?

Det korta svaret är ja eftersom man i praktiken bygger två olika lösningar: ett administrationssystem i form ett headless-CMS och så själva webblösningen som presenterar informationen och tillhandahåller interaktivitet, t.ex. en javascriptdriven webbapplikation. Att skilja mellan administration av data och hur den presenteras kommer alltså med ett pris i form av längre utvecklingstid. Funktioner som vanligtvis följer med på köpet i vanliga CMS-verktyg saknas, t ex förhandsvisning av opublicerade sidor.

Samtidigt får du fördelar. Om du längre fram upptäcker att du vill presentera informationen på ett helt annat sätt eller behöver bygga på med ytterligare kanaler så kan man göra det utan att behöva göra ändringar i CMS:et och spar på så sätt mängder av tid.

Sammanfattningsvis bör du tänka att du bygger två "saker": en administrationsdel och en presentationsdel. De kommer att vara två helt skilda produkter och möts enbart via API:t.

 

7. Vilka headless finns det?

Det finns mängder av olika headless-CMS

• Contentful
• Headless WordPress
• Headless Drupal
• Kontent by Kentico
• Magnolia
• Agility CMS
• Butter CMS
• Contentstack
• Bloomreach
• Netlify

De flesta renodlade headless-CMS bygger på JavaScript och Node (JavaScript på serversidan), men det finns även alternativ utvecklade i andra miljöer, t.ex. Microsoft .NET.

Sammanfattningsvis

Ett Headless CMS tar hand om innehållet och är helt skiljt från design, funktioner och presentationen. Valet av CMS bör fattas utifrån de behov som finns - både nuvarande och framtida.

Vill du ha hjälp med att kartlägga dina behov och vilket typ av CMS som kan passa – hör av dig till oss så hjälper vi dig!

---

Läs även