Hva er headless CMS? Forskjellen fra klassisk CMS

01Hva er et publiseringssystem (CMS)?

Et publiseringssystem (CMS) er programvare som gjør at også en person uten tekniske kunnskaper kan legge til og redigere sider, nyheter, produkter eller blogginnlegg. I panelet skriver du inn tittel, tekst og bilde, og systemet publiserer dem på nettsiden.

I klassiske CMS-er er innholdspanelet, databasen og nettsidens utseende deler av én enkelt pakke. Panelet lagrer innholdet, og den samme programvaren setter det sammen med maler og leverer det til den besøkende som HTML-sider. Denne strukturen kalles monolittisk eller integrert arkitektur.

Headless-tilnærmingen deler denne pakken i to. Ordet «headless» (hodeløs) sier at systemet ikke har noe «hode», altså ikke noe fast visningslag. Visningslaget er et eget prosjekt og ber om innholdet via API.

02Slik fungerer headless-arkitektur

En headless-arkitektur består vanligvis av tre deler: administrasjonspanelet der innholdet legges inn, API-et som gir innholdet ut, og ett eller flere grensesnitt som viser det.

1. Redaktøren legger inn innhold: Hen fyller ut tittel, tekst, bilde og felter i panelet.
2. Innholdet lagres som strukturerte data: Det er feltene som lagres, ikke sidelayouten (tittel, ingress, brødtekst, forfatter, dato).
3. Grensesnittet sender en forespørsel til API-et: Nettsiden, mobilappen eller en annen kanal henter innholdet som JSON.
4. Grensesnittet viser innholdet med sitt eget design: Det samme innholdet presenteres i hver kanal på en måte som passer kanalen.
5. Endringen publiseres: Sidene bygges enten på nytt, eller så hentes oppdaterte data ved neste forespørsel.

const yanit = await fetch('https://cms.ornek.com/api/yazilar?limit=3');
const { veriler } = await yanit.json();
veriler.forEach(y => console.log(y.baslik, y.yayinTarihi));

03Forskjellen mellom headless og klassisk CMS

Som tabellen viser, gir headless fleksibilitet og skalerbarhet, men krever mer utviklingsarbeid i starten. Derfor er det ikke det rette valget for alle prosjekter. Det bør vurderes sammen med behovet.

04Fordelene med headless CMS

Hastighet og ytelse

I en headless-struktur kan grensesnittet bygge sidene på forhånd og levere dem via et CDN. Den besøkende venter ikke på en databaseforespørsel ved hver forespørsel. Siden er klar. Det gjør det lettere å nå målene for Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1). Hastighet har vi forklart nærmere på siden vår om hastighet og ytelse.

Sikkerhet

Administrasjonspanelet kan ligge på en annen adresse enn nettsiden besøkende bruker. Hvis nettsiden består av statiske filer, er det mindre kode på serversiden en angriper kan ta sikte på. Det gjør angrepsflaten mindre. Husk likevel at panelet og API-et også må beskyttes.

Publisering i flere kanaler

Den samme produktbeskrivelsen kan brukes på nettsiden, i mobilappen, på skjermer i butikken og i en feed til en markedsplass. Innholdet oppdateres én gang og endres overalt. Dette kalles flerkanalspublisering (omnichannel).

Frihet i teknologivalg

Grensesnittteamet kan velge den teknologien det vil, uten å være bundet til CMS-ets malspråk. Når du vil fornye grensesnittet, blir innholdet værende. Bare visningslaget skrives på nytt.

05Ulemper og ting å passe på

Fleksibiliteten i headless-strukturen er ikke gratis. Mange funksjoner som følger med ferdig i et klassisk system, må her settes opp og vedlikeholdes av teamet. Vurder punktene under ett for ett for ditt eget prosjekt før du bestemmer deg. Ofte er det ikke teknologien som avgjør, men om teamet og budsjettet kan bære dette ekstra ansvaret.

• Avhengigheten av utviklere øker: Å legge til en ny sidemal eller komponent krever kode.
• Forhåndsvisning settes opp separat: Det kreves ekstra arbeid for at redaktøren skal se siden før publisering.
• Antall deler øker: CMS, API, grensesnitt og hosting styres hver for seg.
• SEO-arbeidet ligger hos grensesnittet: Tittelkoder, strukturerte data og områdekart må settes opp riktig i grensesnittprosjektet.
• Kostnadsmodellen er annerledes: Noen skybaserte CMS-tjenester tar betalt etter innhold, brukere eller antall API-forespørsler.

06Hva er Jamstack?

Jamstack er en arkitekturtilnærming for nettet som ofte nevnes sammen med headless CMS. Sidene bygges på forhånd under byggingen og leveres som statiske filer via et CDN, mens dynamiske oppgaver løses med API-er og JavaScript.

I denne tilnærmingen kommer innholdet fra headless CMS-et, og sidene bygges av en statisk nettstedsgenerator eller et rammeverk som Next.js. Hvordan Next.js kombinerer statisk generering og generering på serversiden, har vi forklart i artikkelen hva er Next.js.

Jamstack passer ikke for alle prosjekter. For innhold som endres svært ofte eller personaliseres per bruker, kan generering på serversiden eller hybride metoder være bedre. Det viktige er å velge riktig byggemåte ut fra hvor ofte hver side endres.

07Hvilke prosjekter passer det for?

Når du bestemmer deg, bør du se på innholdet ditt før teknologien: Hvor mange kanaler finnes, hvor ofte oppdateres det, hvor mange redigerer, og hvor kritisk er hastighet? Kan du svare et klart ja på minst to av disse spørsmålene, er en headless-struktur en seriøs kandidat. Ellers gir en enklere arkitektur vanligvis et resultat som både er raskere og rimeligere.

• Merkevarer i flere kanaler: virksomheter som bruker det samme innholdet på nett, i mobilapp og på fysiske skjermer.
• Flerspråklige nettsider og nettsider for flere regioner: Strukturert innhold gjør det enklere å styre oversettelser.
• Innholdssider med mye trafikk: Forhåndsbygde sider tåler belastning bedre.
• App og nettside sammen: en nettbutikk eller bestillingsplattform med mobilapp.
• Merkevarer som ofte fornyer designet: de som vil skrive grensesnittet på nytt uten å flytte innholdet.

08Hva bør du passe på ved overgangen?

Når du går fra en eksisterende nettside til headless-struktur, er det viktigste steget å sette opp innholdsmodellen riktig. I stedet for å flytte sidene som de er, må innholdet deles opp i meningsfulle felter: produktnavn, kort beskrivelse, lang beskrivelse, bilde, kategori og lignende.

Det andre steget er å beholde URL-strukturen. Hvis adressene skal endres, må det planlegges en 301-omdirigering for hver gamle adresse, ellers kan synligheten i søkemotorer lide. Her er prinsippene for SEO-vennlig webdesign en veiviser.

På grensesnittsiden bør du også snakke om hvilken teknologi innholdet skal vises med fra begynnelsen. Arbeidsdelingen mellom grensesnitt og server har vi tatt for oss i artikkelen om forskjellen mellom frontend og backend, og ett av språkene som fortsatt er utbredt på serversiden i artikkelen hva er PHP. Hos Aurora Yazılım planlegges innholdsstruktur, hastighetsmål og enkel administrasjon sammen i prosjekter innen webdesign.