Vad är headless CMS? Skillnaden mot klassiskt CMS

01Vad är ett innehållshanteringssystem?

Ett innehållshanteringssystem (CMS) är mjukvara som gör att även den som saknar teknisk kunskap kan lägga till och redigera sidor, nyheter, produkter eller blogginlägg. Du skriver in rubrik, text och bild i panelen, och systemet publicerar dem på sajten.

I klassiska CMS är innehållspanelen, databasen och sajtens utseende delar av ett enda paket. Panelen sparar innehållet, och samma programvara sätter ihop det med mallar och levererar det som HTML-sidor till besökaren. Den strukturen kallas monolitisk eller integrerad arkitektur.

Headless-sättet delar upp paketet i två. Ordet “headless” (huvudlöst) betyder att systemet saknar ett “huvud”, alltså ett fast presentationslager. Presentationslagret är ett separat projekt som hämtar innehållet via API.

02Så fungerar headless-arkitektur

En headless-arkitektur består oftast av tre delar: adminpanelen där innehållet skrivs in, API:et som lämnar ut innehållet och ett eller flera gränssnitt som visar det.

1. Redaktören skriver in innehåll: fyller i rubrik, text, bild och fält i panelen.
2. Innehållet lagras som strukturerad data: det är fälten som sparas, inte sidlayouten (rubrik, sammanfattning, brödtext, författare, datum).
3. Gränssnittet skickar en förfrågan till API:et: webbplatsen, mobilappen eller en annan kanal får innehållet som JSON.
4. Gränssnittet visar innehållet i sin egen design: samma innehåll presenteras i varje kanal på det sätt som passar den kanalen.
5. Ändringen publiceras: sidorna byggs antingen om eller så hämtas aktuell data vid nästa förfrågan.

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));

03Skillnaden mellan headless och klassiskt CMS

Som tabellen visar ger headless flexibilitet och skalbarhet, men kräver mer utvecklingsarbete i början. Därför är det inte rätt val för alla projekt och bör bedömas utifrån behovet.

04Fördelar med headless CMS

Hastighet och prestanda

I en headless-struktur kan gränssnittet bygga sidorna i förväg och leverera dem via ett CDN. Besökaren behöver inte vänta på en databasfråga vid varje förfrågan; sidan är redan klar. Det gör det lättare att nå målen för Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1). Vi går igenom hastighet i detalj på sidan om hastighet och prestanda.

Säkerhet

Adminpanelen kan ligga på en annan adress än den sajt som besökarna når. Om sajten består av statiska filer finns det mindre serverkod som en angripare kan ge sig på. Det minskar angreppsytan, men glöm inte att panelen och API:et också måste skyddas.

Publicering i flera kanaler

Samma produktbeskrivning kan användas på webbplatsen, i mobilappen, på en skärm i butiken och i ett flöde till en marknadsplats. Innehållet uppdateras en gång och ändras överallt. Det kallas publicering i flera kanaler (omnichannel).

Frihet i teknikvalet

Gränssnittsteamet kan välja den teknik de vill utan att vara bundna till CMS:ets mallspråk. När du vill förnya gränssnittet blir innehållet kvar där det är; bara presentationslagret skrivs om.

05Nackdelar och saker att tänka på

Flexibiliteten i en headless-struktur är inte gratis. Många funktioner som följer med färdiga i ett klassiskt system byggs och underhålls här av teamet. Bedöm punkterna nedan en och en utifrån ditt eget projekt innan du bestämmer dig; ofta är det inte tekniken som avgör, utan om teamet och budgeten orkar bära det extra ansvaret.

• Beroendet av utvecklare ökar: en ny sidmall eller komponent kräver kod.
• Förhandsgranskningen byggs separat: det krävs extra arbete för att redaktören ska kunna se sidan innan den publiceras.
• Fler delar: CMS, API, gränssnitt och hosting förvaltas var för sig.
• SEO-arbetet hamnar i gränssnittet: titeltaggar, strukturerad data och sajtkarta måste byggas rätt i gränssnittsprojektet.
• Annan kostnadsmodell: vissa CMS-tjänster i molnet tar betalt efter antalet innehållsposter, användare eller API-anrop.

06Vad är Jamstack?

Jamstack är ett sätt att bygga webbplatser som ofta nämns tillsammans med headless CMS. Sidorna byggs i förväg vid kompileringen och levereras som statiska filer via ett CDN, medan det dynamiska sköts med API:er och JavaScript.

I det här upplägget kommer innehållet från ett headless CMS, och sidorna byggs av en statisk sajtgenerator eller ett ramverk som Next.js. Hur Next.js kombinerar statisk rendering och rendering på serversidan har vi gått igenom i inlägget Vad är Next.js.

Jamstack passar inte alla projekt. För innehåll som ändras mycket ofta eller personaliseras per användare kan rendering på serversidan eller hybridmetoder passa bättre. Det viktiga är att välja rätt byggsätt utifrån hur ofta varje sida ändras.

07När passar det?

Titta på ditt innehåll före tekniken när du väljer: hur många kanaler finns det, hur ofta uppdateras det, hur många personer redigerar och hur kritisk är hastigheten? Kan du svara ett tydligt ja på minst två av de frågorna är en headless-struktur en seriös kandidat; annars ger en enklare arkitektur oftast ett både snabbare och billigare resultat.

• Varumärken med flera kanaler: företag som använder samma innehåll på webben, i mobilappen och på fysiska skärmar.
• Flerspråkiga sajter och sajter för flera regioner: strukturerat innehåll gör det lättare att hantera översättningar.
• Innehållssajter med mycket trafik: förbyggda sidor står emot belastning bättre.
• App och sajt tillsammans: en e-handels- eller bokningsplattform med en mobilapp.
• Varumärken som ofta förnyar designen: de som vill skriva om gränssnittet från grunden utan att flytta innehållet.

08Att tänka på vid övergången

När du går över från en befintlig sajt till en headless-struktur är det viktigaste steget att bygga upp den rätta innehållsmodellen. I stället för att flytta sidorna som de är måste innehållet delas upp i meningsfulla fält: produktnamn, kort beskrivning, lång beskrivning, bild, kategori och så vidare.

Det andra steget är att behålla URL-strukturen. Om adresserna ändras måste du planera en 301-omdirigering för varje gammal adress; annars kan synligheten i sökmotorer ta skada. Här är principerna för SEO-anpassad webbdesign en vägledning.

Vilken teknik som ska visa innehållet i gränssnittet bör också diskuteras från början. Arbetsfördelningen mellan gränssnitt och server går vi igenom i inlägget om skillnaden mellan frontend och backend, och ett av de språk som fortfarande är vanliga på serversidan i inlägget Vad är PHP. I webbdesignprojekt hos Aurora Yazılım planeras innehållsstruktur, hastighetsmål och användarvänlig administration tillsammans.