HeadlessvsmonolitisktCMS:WordPress,Sanityochverklighetenbakomarkitekturbeslut

WordPress driver ungefär 43 procent av alla webbplatser på internet. Det är inte ett debattbart påstående utan en mätbar siffra från W3Techs, och den har legat stabilt runt det spannet i flera år. Samtidigt har "headless CMS" blivit ett av de mest använda buzzwords i webbutvecklingsvärlden sedan ungefär 2019. Sanity, Contentful, Strapi och en handfull andra plattformar har tagit en allt större del av marknaden, framför allt bland utvecklarteam som bygger med moderna JavaScript-ramverk.

Men debatten har blivit onödigt polariserad. I ena hörnet står utvecklare som behandlar WordPress som ett kvarlämnat fossil. I andra hörnet står byråer som byggt hela sin affärsmodell på WordPress och avfärdar headless som onödig komplexitet. Verkligheten är, som vanligt, mer nyanserad.

Den här artikeln är ett försök att ge en ärlig bild. Inte en säljpitch åt något håll, utan en genomgång av vad de olika arkitekturerna faktiskt innebär i praktiken, för redaktörer, utvecklare och budgetar.

Vad headless egentligen betyder

Termen "headless" syftar på att man skiljer innehållslagret (backend) från presentationslagret (frontend). I ett traditionellt CMS som WordPress är dessa ihopkopplade: du skriver innehåll i wp-admin, och WordPress renderar HTML-sidor åt dig med hjälp av PHP-templates. Innehållet och presentationen lever i samma system.

I ett headless CMS lagras innehållet som strukturerad data och levereras via ett API, typiskt REST eller GraphQL. Frontenden byggs separat, med valfritt ramverk: Next.js, Nuxt, Astro, SvelteKit, eller vad som nu passar projektet. Innehållet blir alltså oberoende av hur det presenteras, vilket öppnar för att använda samma data på webben, i en mobilapp, på en digital skylt, eller i ett internt verktyg.

Det här kallas ibland "API-first" eller "content as data". Kärnan i idén är att innehåll inte är sidor, utan strukturerad information som kan konsumeras var som helst.

Monolitiskt CMS: vad det faktiskt gör bra

Det finns en anledning till att WordPress har 43 procent av webben, och den anledningen är inte att alla gjort ett dåligt val.

WordPress

WordPress mognade under nästan två decennier. Det har över 60 000 plugins i sin officiella katalog. Behöver du ett kontaktformulär? Det finns tio plugins för det. E-handel? WooCommerce driver miljontals butiker. Flerspråkighet? WPML och Polylang har funnits i över tio år. Bokningssystem, medlemsportaler, LMS-plattformar: det finns färdiga lösningar för nästan allt.

Redaktörsupplevelsen är välkänd. Gutenberg-editorn (blockbaserad sedan WordPress 5.0 i december 2018) ger WYSIWYG-redigering där redaktören ser ungefär hur sidan kommer att se ut medan den skrivs. Den är inte perfekt (många föredrar fortfarande Classic Editor-pluginet), men den är begriplig för personer utan teknisk bakgrund.

Hosting kostar lite. En delad server hos valfri hostingleverantör ger dig WordPress för 50-300 kronor i månaden. Managed hosting som Kinsta eller WP Engine kostar mer, men du får caching, staging-miljöer och automatiska backuper inkluderat.

WordPress har dessutom haft ett REST API sedan version 4.7, som släpptes i december 2016. Det innebär att WordPress tekniskt sett kan användas som ett headless CMS: du behåller wp-admin för redaktörerna och bygger frontenden separat. Det är ingen elegant lösning, men det fungerar och det finns team som kör det i produktion.

Webflow

Webflow tar en annan position. Det är en visuell webbplatsbyggare med ett inbyggt CMS, riktad mot designers som vill ha full kontroll över layout utan att skriva kod. Du bygger sidan genom att dra och manipulera element i ett visuellt gränssnitt, och Webflow genererar ren HTML/CSS.

CMS:et i Webflow är enklare än WordPress (det har en gräns på 10 000 objekt i Business-planen), men för mindre sajter fungerar det väl. Det som Webflow gör riktigt bra är att eliminera behovet av en utvecklare för enklare webbplatser. En duktig designer kan bygga en responsiv sajt med animationer, CMS-drivna bloggsidor och formulär utan att röra en rad kod.

Nackdelen är vendor lock-in. Din sajt lever i Webflows infrastruktur. Du kan exportera HTML/CSS, men inte CMS-datan på ett smidigt sätt. Du är bunden till deras hosting och deras prismodell.

Headless CMS: var det faktiskt lyser

Sanity

Sanity grundades i Oslo 2017 och har sedan dess byggt en plattform som sticker ut på flera sätt. Det mest uppenbara är Sanity Studio, ett open source-verktyg för att bygga anpassade redigeringsgränssnitt. Till skillnad från Contentfuls eller Strapas admin-paneler, där du jobbar inom ramarna för deras UI-beslut, kan du i Sanity Studio bygga exakt det gränssnitt dina redaktörer behöver. Vill du ha en förhandsvisning av en artikel bredvid redigeringsfältet? Bygg det. Vill du ha ett arbetsflöde med utkast, granskning och publicering? Konfigurera det.

Sanity använder sitt eget frågespråk, GROQ (Graph-Relational Object Queries), som är designat specifikt för att fråga mot dokumentbaserad data. Det är kompaktare än GraphQL för de flesta CMS-frågor och har en lägre inlärningströskel. Stöd för GraphQL finns också om man föredrar det.

Real-time collaborative editing är inbyggt: flera personer kan redigera samma dokument samtidigt, ungefär som i Google Docs. Det låter som en liten detalj, men i team med flera redaktörer gör det märkbar skillnad i vardagen.

Prismodellen börjar med en generös gratisplan. Growth-planen kostar 15 dollar per användare och månad, vilket innebär att ett litet team på fem personer betalar runt 75 dollar i månaden. Planen inkluderar mer lagring, fler API-anrop och tillgång till fler teamfunktioner.

Contentful

Contentful grundades i Berlin 2013 och var ett av de första headless CMS:en som fick bred adoption. Det är byggt med enterprise i åtanke, vilket syns på flera sätt: robust lokalisering (hantera innehåll på tio språk parallellt utan plugins), granulär rollhantering, och API:er som är stabila och väldokumenterade.

Contentful erbjuder både REST och GraphQL API:er. Datamodellen bygger på content types och entries, där du definierar strukturen för ditt innehåll och sedan skapar instanser av den. Det är rent och förutsägbart, men också ganska strikt. Du kan inte göra fritt strukturerat innehåll lika enkelt som i Sanity.

Gränssnittet är polerat men lite stelt. Redaktörer som är vana vid WordPress WYSIWYG-upplevelse kan tycka att det känns abstrakt att fylla i fält i ett formulär istället för att se hur sidan ser ut. Rich text-editorn fungerar, men den är inte lika flexibel som Gutenberg.

Prismässigt är Contentful bland de dyrare alternativen. Gratisplanen är begränsad (10 användare, 1 miljon API-anrop per månad). Teamplanen kostar runt 300 dollar per månad, och Enterprise-prissättning är anpassad och ligger betydligt högre.

Strapi

Strapi tar ett helt annat grepp: det är open source och self-hosted. Du installerar det som ett Node.js-projekt, definierar dina content types, och kör det på din egen server. Ingen tredjepartsinfrastruktur, inga API-anropsgränser, full kontroll.

Version 4 är stabil och väl beprövad, och version 5 lanserades under 2024 med förbättringar av admin-panelet och plugin-systemet. Strapi genererar automatiskt REST och GraphQL API:er baserat på dina content types, och det har ett växande ekosystem av community-plugins.

Kostnaden i ren licensavgift är noll, det är MIT-licensierat. Men du betalar för hosting. En VPS som klarar Strapi med en Postgres-databas kostar typiskt 100-500 kronor i månaden beroende på trafikvolym. Och du betalar i utvecklartid: det finns ingen managed hosting som tar hand om uppdateringar, backuper och skalning åt dig på samma sätt som WordPress managed hosting gör.

Gemensamma headless-styrkor

Oavsett vilken headless-plattform du väljer får du vissa fördelar som följer av arkitekturen:

Frontend-frihet. Du väljer ramverk. React, Vue, Svelte, Astro, eller rent HTML om du vill. Du är inte bunden till ett specifikt templating-system.

Omnichannel-leverans. Samma innehåll kan drivas ut till webb, app, kiosk och e-postutskick via samma API.

TypeScript-stöd. Headless CMS:er genererar typiskt typade schemas, vilket ger autokomplettering och typkontroll i din frontend-kod.

Git-baserade arbetsflöden. Frontend-koden versionshanteras som alla andra kodprojekt. Du kan ha pull requests, code reviews och CI/CD-pipelines.

Jämförelsetabell

Redaktörsperspektivet

Det här är där diskussionen ofta spårar ur. Utvecklare som förespråkar headless fokuserar gärna på teknisk elegans: typad data, rena API:er, moderna ramverk. Men det är sällan utvecklare som sitter och skriver artiklar, uppdaterar produktsidor eller lägger in nya medarbetarprofiler varje vecka.

En redaktör som har jobbat med WordPress i fem år vet exakt hur det fungerar. De öppnar wp-admin, klickar "Ny sida", skriver text, drar in en bild, klickar "Förhandsgranska", ser att det ser okej ut, och trycker "Publicera". Hela flödet tar några minuter och kräver ingen teknisk kunskap.

Flytta samma redaktör till ett headless CMS och upplevelsen förändras. Istället för en visuell editor möts de ofta av ett formulär med fält: "Rubrik", "Brödtext" (en rich text-editor som inte ser ut som sidan), "Featured image" (en filuppladdarknapp), "SEO-beskrivning". De ser aldrig hur sidan kommer att se ut medan de redigerar, om inte utvecklarteamet har byggt en förhandsvisningslösning.

Sanity Studio är det bästa headless-alternativet ur redaktörsperspektiv, men det kräver att någon faktiskt bygger studion. Out of the box får du ett genererat formulärgränssnitt baserat på ditt schema. Det är funktionellt men inte magiskt. Den verkliga styrkan i Sanity Studio kommer först när en utvecklare har lagt tid på att skapa custom components, förhandsvisningar och arbetsflöden anpassade för just det teamets behov.

Contentfuls editor är ren och konsekvent. Du vet alltid var saker finns, och gränssnittet känns professionellt. Men det är också oflexibelt. Du jobbar inom Contentfuls ramar, och de ramarna passar inte alla typer av innehåll lika bra. Speciellt landningssidor med rik layout är svåra att redigera i ett strikt fältbaserat gränssnitt.

Strapas admin-panel är den mest basala av de tre. Den fungerar, men den känns inte lika genomtänkt som Sanity Studio eller Contentful. För enkla innehållstyper räcker den, men för komplexa redaktörsflöden vill man troligen bygga ett eget gränssnitt ovanpå Strapas API.

Förhandsvisning är en specifik smärtpunkt. I WordPress klickar du på "Förhandsgranska" och ser sidan. I ett headless setup behöver du en preview mode i din frontend som hämtar opublicerat innehåll via API:et och renderar det. Next.js har draft mode, och det fungerar, men det kräver implementation och underhåll. Det är inte svårt att bygga, men det är ett steg som inte behövs i WordPress.

Det finns alltså en reell kostnad i redaktörsupplevelse när man går headless. Den kostnaden kan motiveras om man behöver det som headless erbjuder, men den bör inte ignoreras.

Utvecklarperspektivet

Från andra sidan av bordet ser kalkylen annorlunda ut.

En utvecklare som jobbar med WordPress möter PHP, ett språk som fungerar men som de flesta moderna webbutvecklare inte väljer frivilligt. WordPress tema-system bygger på en hierarki av PHP-filer (header.php, single.php, archive.php) med en blandning av HTML och PHP-logik som kan bli svårunderhållen i större projekt. Hooks och filters är kraftfulla men har en brant inlärningskurva, och den globala naturen av WordPress-ekosystemet gör att plugins kan krocka med varandra på oförutsägbara sätt.

Gutenberg-blocken är tekniskt sett React-komponenter, men de lever i WordPress-ekosystemet med dess egna build-verktyg och konventioner. Det är inte riktigt samma sak som att jobba i ett modernt React-projekt.

I ett headless setup väljer utvecklaren sina egna verktyg. TypeScript, ESLint, Prettier, Git-baserade code reviews, CI/CD-pipelines som kör tester automatiskt. Alla de verktyg och arbetsflöden som moderna utvecklarteam redan använder. Frontenden är ett vanligt JavaScript-projekt som deployar till Vercel, Netlify eller valfri plattform.

Med Sanity får du GROQ eller GraphQL för att fråga efter data, och TypeScript-typer kan genereras automatiskt från ditt schema. Det innebär att om du byter namn på ett fält i CMS:et och glömmer uppdatera frontenden, får du ett kompileringsfel istället för en bugg i produktion.

Contentful har generatorer för TypeScript-typer baserat på dina content types, och deras SDK:er för JavaScript är väldokumenterade.

Strapi ger dig full kontroll eftersom det är ditt eget Node.js-projekt. Du kan skriva custom controllers, middleware och hooks. Det är flexibelt men innebär också att du ansvarar för allt: säkerhetsuppdateringar, databasmigrering och skalning.

Men: teknisk elegans har ett pris. I ett headless setup måste du bygga och underhålla mer själv. Routing, bildoptimering, SEO-metadata, sitemaps, förhandsvisning, omdirigeringar. Saker som WordPress hanterar med plugins eller inbyggd funktionalitet behöver du lösa i din frontend-kod. Ramverk som Next.js och Astro har bra stöd för mycket av detta, men det är fortfarande arbete som behöver göras.

Det är också värt att nämna att komplexiteten i systemarkitekturen ökar. Istället för ett system (WordPress) har du minst två (CMS + frontend), ofta med en CDN framför och kanske en webhook-pipeline som triggar rebuilds. Fler rörliga delar innebär fler saker som kan gå sönder.

Kostnad: den fulla bilden

Direkt hostingkostnad är den enklaste biten att jämföra, men den ger en ofullständig bild.

WordPress: En delad server kostar 50-300 kronor i månaden. Managed hosting (Kinsta, WP Engine) kostar 300-1500 kronor. Ovanpå det kommer eventuella premium-plugins: WPML för flerspråkighet kostar runt 400 kronor per år, ett bra SEO-plugin kanske 500-1000 kronor per år. Totalt landar en typisk WordPress-sajt på 2000-15000 kronor per år i driftskostnader.

Sanity: Gratisplanen räcker ofta för mindre projekt. Growth-planen kostar 15 dollar per användare och månad, så ett team på fem personer landar på runt 75 dollar (ungefär 800 kronor) i månaden. Men du behöver också hosta din frontend, exempelvis Vercel, Netlify eller liknande, där gratisplaner ofta räcker för mindre sajter men Pro-planer kostar runt 200 dollar per månad för kommersiella projekt. Total driftskostnad: 0-3000 kronor per månad.

Contentful: Gratisplanen har tydliga begränsningar. Teamplanen börjar runt 300 dollar per månad och Enterprise-planer ligger betydligt högre. Plus frontend-hosting. Total: 0-5000+ kronor per månad.

Strapi: Ingen licensavgift. En VPS med tillräcklig kapacitet kostar 100-500 kronor per månad. Plus frontend-hosting. Total: 200-1500 kronor per månad, men du bär ansvaret för drift och underhåll.

Webflow: CMS-planer börjar runt 160 kronor per månad. Business-planen med utökat CMS kostar runt 400 kronor per månad. All hosting är inkluderad. Total: 2000-5000 kronor per år.

Men den verkliga kostnaden sitter i utvecklingstid. Att bygga en företagssajt i WordPress med ett färdigt tema och WooCommerce tar kanske 40-80 utvecklartimmar. Samma sajt med Sanity och Next.js tar kanske 80-160 timmar, eftersom du bygger mer från grunden: förhandsvisning, bildhantering, sökfunktion och allt annat som WordPress-plugins löser åt dig.

Om teamets timkostnad är 1000 kronor i timmen innebär det en skillnad på 40 000-80 000 kronor bara i initialutveckling. Det är ofta en större siffra än flera års driftskostnader.

Å andra sidan: om du behöver en sajt med en custom design, avancerade animationer, server-side rendering och integrationer mot andra system, kan WordPress-vägen kräva så mycket custom-utveckling att kostnadsskillnaden krymper eller försvinner. WordPress briljerar när du håller dig nära standardlösningar. Ju mer custom-arbete som behövs, desto mindre fördel har det.

Underhåll och långsiktig kostnad

WordPress kräver löpande underhåll. Core-uppdateringar, plugin-uppdateringar och PHP-versionsuppgraderingar behöver göras regelbundet, och varje uppdatering kan potentiellt bryta något, särskilt om du kör många plugins. Säkerheten är en ständig fråga: WordPress är det överlägset mest angripna CMS:et, inte för att det är osäkert i sig, utan för att dess popularitet gör det till ett attraktivt mål.

Headless CMS:er har generellt mindre underhållsbörda på backend-sidan, eftersom Sanity och Contentful hanterar sin egen infrastruktur. Men frontend-koden behöver underhållas: ramverksuppdateringar, beroendeuppgraderingar, säkerhetspatchar i npm-paket.

Strapi faller någonstans mittemellan. Du ansvarar för uppdateringar av Strapi själv plus din server, men du slipper WordPress plugin-karusellen.

Beslutsstöd: när ska du välja vad

Arkitekturbeslut bör baseras på projektets faktiska behov, inte på vad som känns mest modernt. Här är konkreta riktlinjer:

Välj WordPress om:

• Teamet inte har en dedikerad utvecklare och behöver kunna hantera sajten själva
• Budgeten är begränsad och standardlösningar räcker (blogg, företagssajt, enklare e-handel)
• Redaktörerna redan kan WordPress och det inte finns skäl att byta
• Du behöver snabbt komma igång och time-to-market är prioriterat
• Du behöver funktionalitet som redan finns som plugin (bokningssystem, LMS, medlemsportaler)

Välj Webflow om:

• En designer ska bygga och underhålla sajten utan utvecklarstöd
• Sajten är primärt presentationssida med begränsat dynamiskt innehåll
• Visuell kontroll över design är viktigare än teknisk flexibilitet

Välj Sanity om:

• Du har ett utvecklarteam som jobbar med moderna JavaScript-ramverk
• Redaktörsupplevelsen behöver skräddarsys för ett specifikt arbetsflöde
• Innehållet ska levereras till flera kanaler (webb + app + annat)
• Real-time collaboration mellan redaktörer är viktigt
• Du vill ha flexibilitet i hur data struktureras och frågas

Välj Contentful om:

• Organisationen är enterprise-storlek med komplexa behov kring roller, lokalisering och arbetsflöden
• Stabil, väldokumenterad API-yta är viktigare än flexibilitet
• Du har budget för det. Contentful är inte billigt, men för rätt organisation är det värt priset

Välj Strapi om:

• Du vill ha full kontroll och äga hela stacken
• Budget för plattformsavgifter är noll, men du har utvecklarkompetens att underhålla infrastrukturen
• Du behöver ett headless CMS men vill inte vara beroende av en tredjepartstjänst
• Datakänslighet kräver att allt körs on-premises

Hybridapproach: WordPress som headless CMS:

• Om du redan har en WordPress-sajt med mycket innehåll och vill modernisera frontenden utan att migrera all data
• Om redaktörerna är vana vid WordPress men utvecklarna vill jobba med React/Next.js
• Var medveten om att det är en kompromiss: du får WordPress nackdelar (underhåll, plugins) plus headless-nackdelar (komplexare arkitektur) samtidigt

Avslutande tanke

Det finns inget universellt rätt svar i den här frågan. WordPress är inte dött, headless är inte automatiskt bättre, och det dyraste alternativet är inte nödvändigtvis det mest lämpliga.

Det smartaste du kan göra är att börja med frågorna: Vem ska redigera innehållet, och vad är de vana vid? Vart ska innehållet levereras? Vilken teknisk kompetens finns i teamet? Hur stor är budgeten, inklusive utvecklingstid?

Svaren på de frågorna pekar nästan alltid mot rätt arkitektur, oavsett vad som råkar vara populärt just nu.