Headless bliver som regel solgt som det moderne valg – hurtigere, mere fleksibelt, klar til fremtiden. Det er sjældent forkert i sig selv. Det er bare ikke svaret på det, de fleste spørgsmål om headless egentlig handler om.
Det interessante er ikke, om noget kan lade sig gøre. Det er, hvad det koster at få det til at fungere ordentligt.
Hvad betyder headless egentlig?
I almindelig WordPress er redaktion og fremvisning ét system. Redaktøren skriver i wp-admin, temaet ved, hvordan det skal se ud, og WordPress selv genererer siden, browseren får at se.
Headless skiller de to ad. WordPress bliver kun det sted, indholdet bliver til – et API, ikke en hjemmeside. En separat frontend, ofte bygget i noget som Next.js eller Nuxt, henter indholdet og bestemmer selv, hvordan det vises.
Hvad får man allerede med almindelig WordPress?
Det er let at gøre traditionelt WordPress til den gammeldags modstander, headless skal besejre. Det er en dårlig start på samtalen, for WordPress har én arkitektonisk fordel, der er større end de fleste diskussioner giver den kredit for: det hænger sammen.
Redaktøren skriver indhold. Temaet ved, hvordan det skal vises. WordPress genererer siden. Preview virker, fordi det er den samme kode, der bygger preview og den offentlige side. Plugins kan koble sig på hele kæden – fra et felt i redigeringen til noget, der rent faktisk vises på siden.
Det er ikke bare nemmere. Det er mindre integration. Der er færre steder, noget kan holde op med at stemme overens med noget andet.
Headless fjerner ikke den forbindelse. Det gør forbindelsen til noget, man selv skal definere og vedligeholde.
Hvad er det, headless skiller ad?
Tre mønstre går igen, når adskillelsen rent faktisk giver mening.
- Samme indhold i flere kanaler. En artikel, et produkt eller en kampagne skal vises på hjemmesiden, i en app og måske på et skærmsystem i en butik – hver med sit eget udseende. WordPress skal levere indholdet til alle tre, uden selv at bestemme, hvordan det ser ud noget af stederne.
- Frontend skal udvikles og deployes uafhængigt af CMS'et. Frontend-teamet arbejder i en helt anden stak end PHP og WordPress-temaer, med sin egen release-rytme, og vil ikke være bundet af, hvordan WordPress bygger sider.
- CMS'et er én datakilde blandt flere. Frontenden henter ikke kun WordPress-indhold – den sammensætter produktdata, brugerdata, søgeresultater og CMS-tekst fra forskellige systemer. Så er det ikke naturligt, at WordPress samtidig skal eje selve præsentationslaget.
Det er headless som arkitektur, ikke som "WordPress med en moderne frontend."
Hvornår er det en fordel?
Performance nævnes ofte som argumentet for headless, og det er værd at være præcis her, fordi påstanden sjældent holder, som den bliver fremført.
Et velkonfigureret WordPress-site er ikke langsomt, fordi det er WordPress. Full-page cache, en reverse proxy og et CDN betyder, at PHP og databasen slet ikke bliver ramt for størstedelen af trafikken. Og en tung frontend bygget i React kan sagtens være langsommere for den besøgende end et simpelt, godt cachet WordPress-tema. Arkitekturen er ikke en performance-score i sig selv.
Det reelle argument er et andet: adskillelsen giver andre muligheder for deployment, caching og skalering – ikke fordi headless automatisk er hurtigere, men fordi frontend og backend kan bygges, caches og skaleres hver for sig, uafhængigt af hinanden.
Hvad koster adskillelsen?
Frontenden bliver et selvstændigt softwareprojekt. Ikke nødvendigvis bygget fra bunden – der er frameworks, komponentbiblioteker og designsystemer at bygge på – men det skal bygges, deployes og vedligeholdes som sit eget projekt, med sin egen infrastruktur omkring sig.
WordPress' plugin-økosystem holder heller ikke nødvendigvis. Et almindeligt plugin tilføjer ofte funktionalitet både i backend og på selve siden. I en headless opsætning kan backend-delen fungere fint, mens frontend-delen bliver ubrugelig, fordi der ikke er noget WordPress-tema til den at hægte sig på. Man kan ikke uden videre regne med, at det økosystem, der gør WordPress hurtigt at bygge med, fungerer på samme måde.
Og noget af det, redaktøren tidligere oplevede som ét system, bliver til flere ting, der hver skal fungere for sig og sammen: preview, navigation, formularer, søgning, redirects, SEO-felter. Ingen af delene forsvinder. Men nogen skal nu sørge for, at de fungerer på tværs af grænsen mellem CMS og frontend, i stedet for at det bare var sådan, systemet virkede.
Det behøver ikke være alt eller intet
WordPress kan levere indhold gennem sit eget API til én kanal – en app, et widget, en anden kanal – mens resten af sitet stadig kører som et almindeligt WordPress-tema. Det er en hybrid løsning: det meste forbliver, som det var, og kun det, der reelt har brug for adskillelsen, får den.
Hvornår ville jeg vælge hvad?
Tre spørgsmål er mere brugbare end ét.
Skal det samme indhold bruges i flere forskellige produkter eller kanaler? Har frontenden behov for at kunne udvikles og deployes uafhængigt af WordPress? Har organisationen udviklingskapaciteten til at eje to adskilte dele bagefter – ikke kun til at bygge dem, men til at drive dem?
Er svaret på alle tre nej, er der sjældent en god grund til at skille tingene ad. Hvis svaret er "vi vil gerne have Next.js, fordi det er mere moderne", har man ikke identificeret et forretningsproblem. Man har identificeret en teknologipræference.
Headless giver frihed ved at skille tingene ad. Men det, man skiller ad, skal bagefter forbindes igen – og det er det arbejde, der er let at overse, når beslutningen bliver truffet. Det er også den del af opgaven, jeg oftest bliver kaldt ind til i arbejdet med CMS-løsninger: at forstå, hvad der reelt binder et system sammen, før man skiller det ad.
