Headless frontend förklarat

En headless frontend är en fristående webbapplikation som renderar e-handelsstorefronten och hämtar all data via API:er. Den har ingen direkt koppling till commerce-backendkodbasen. Det här är arkitekturen som skiljer seriösa e-handelsstorefronts från plattformsteman, och det är lagret Frntkey produktifierar för Norce- och Shopware-handlare.

Frikopplad från commerce-backend
Driftsätts oberoende
Högre prestandatak
Fungerar med vilket commerce-API som helst

Fördelar

Högre prestandabaslinje

Storefronten driftsätts till ett CDN edge runtime och serverar cachad HTML för produkt- och kategorisidor. Time-to-first-byte sjunker avsevärt jämfört med en server-renderad monolitisk plattform. Core Web Vitals-mål nås som standard, inte som en finputsning i slutet.

Frontend-teamet jobbar oberoende

Att designa om storefronten, lägga till en ny sidtyp eller uppdatera checkout-flödet kräver inte att commerce-backenden rörs. Frontend och backend driftsätts på separata kadenser. Teamet som äger storefronten blockeras inte av teamet som äger backenden.

En backend, flera kanaler

Samma commerce-API:er som driver webbutiken kan driva en mobilapp, en kiosk, en butiksskärm eller ett kundtjänstverktyg. Varje kanal är ett separat huvud mot samma backenddata. Att lägga till en kanal innebär inte att commerce-logiken behöver byggas om.

Best-of-breed-stack på varje lager

Sök, CMS, betalning, CRM, recensioner och frakt väljs oberoende av varandra. Headless-frontenden ansluter till vilka leverantörer som passar projektet. Att byta sökleverantör eller lägga till en ny betalmetod kräver inte ändringar i commerce-backenden.

Vad en headless frontend är

En headless frontend är storefront-lagret i ett headless commerce-system. Det är en fristående webbapplikation, typiskt byggd i ett modernt JavaScript-ramverk som Vue, Nuxt, React eller Next.js, som renderar köpupplevelsen och kommunicerar med commerce-backenden uteslutande via API:er.

"Headless" i headless frontend syftar på att commerce-backenden inte har något eget huvud. Den renderar ingen HTML. Den exponerar API-endpoints för produkter, priser, varukorg, checkout och ordrar, och frontend-applikationen anropar dessa endpoints och bestämmer hur data ska presenteras. Frontend och backend är två oberoende system som råkar prata med varandra.

Det här skiljer sig från ett traditionellt e-handelstema. Ett Shopify Liquid-tema, en Shopware Storefront-mall eller ett Magento Luma-tema renderar alla inuti själva e-handelsplattformen. Frontend och backend delar samma kodbas. För att ändra checkout-layouten redigerar du samma applikation som behandlar ordrar. En headless frontend lever helt utanför commerce-motorn.

Hur en headless frontend fungerar

En headless frontend i produktion består av tre komponenter som samverkar.

Frontend-applikationen

En Vue, Nuxt, React, Next.js eller liknande applikation som äger routing, rendering, SEO och användargränssnittet. Den håller ingen commerce-data själv. Varje produkt, pris, varukorgsobjekt och orderpost hämtas från API:erna under den. På Vue- och Nuxt-stacken hanterar Nuxt server-side rendering som standard, vilket innebär att produktsidor och kategorilister returnerar full HTML på första begäran — avgörande för SEO och Core Web Vitals.

Backend-for-frontend (BFF)

Ett server-orkestreringslager som sitter mellan frontend-applikationen och commerce-API:erna. Det komponerar data från flera backend-tjänster till ett enda, optimerat svar för storefronten. En produktdetaljsida behöver produktdata, priser, lager och relaterat innehåll — BFF:en hämtar dessa från respektive källor och returnerar ett svar. Den hanterar även cachning, autentisering och logik som inte bör köras i webbläsaren. BFF:en är det som gör en headless frontend snabb.

Commerce-API:erna

E-handelsmotorn — Norce, Shopware, commercetools, Shopify, Magento eller en annan plattform — exponerar REST- eller GraphQL-endpoints som BFF:en anropar. Commerce-motorn äger produkter, priser, lager, varukorg, checkout, ordrar och kundkonton. Den bryr sig inte om hur data visas. Det är frontendens jobb.

Headless frontend vs plattformstema

De praktiska skillnaderna mellan en headless frontend och ett plattformstema spelar större roll i leverans än i teori.

Anpassningstak. Ett tema begränsas av vad plattformens frontend-motor tillåter. CSS-överskrivningar, mallmodifieringar och plugin-hooks tar dig så långt. En headless frontend är en förstaklassig applikation. Vilket UX-mönster, animation, checkout-flöde eller innehållslayout som helst som kan byggas i ett modernt JavaScript-ramverk är möjligt.
Driftsättningsoberoende. Ett tema driftsätts som en del av plattformen. Varje temaforändring kan kräva en plattformsdriftsättning. En headless frontend driftsätts oberoende, vanligtvis till ett edge runtime som Vercel. Frontend-ändringar når produktion utan att commerce-backenden rörs.
Prestandaprofil. Plattformsteman renderar på plattformens server. Svarstider beror på plattformens infrastruktur. En headless frontend serverad från Vercels edge CDN kan returnera cachad HTML på millisekunder, oberoende av commerce-backendns svarstid.
Ingenjörskrav. Ett tema kan hanteras av en utvecklare bekant med plattformens mallspråk. En headless frontend kräver frontend-utvecklare med JavaScript-ramverkserfarenhet. Ingenjörstörskeln är högre och teamkostnaden är högre.
CMS-flexibilitet. De flesta plattformsteman förlitar sig på plattformens inbyggda innehållsverktyg. En headless frontend använder ett dedikerat headless CMS — Storyblok, Contentful, Sanity — med en proper redaktörsupplevelse.

Vad en headless frontend levererar för SEO

SEO är området där headless frontend får mest granskning, och med rätta skäl. En klientrenderad React- eller Vue-applikation utan server-side rendering returnerar ett tomt HTML-skal till Googles crawlbot. Det är dåligt. En välbyggd headless frontend med server-side rendering returnerar full HTML, strukturerad data och Open Graph-metadata på varje begäran. Det är minst lika bra som en monolitisk plattform, ofta bättre.

Server-side rendering på alla indexerbara sidor. Produktdetalj, kategorilisting, landningssidor, blogg — alla behöver full HTML på första svar.
Kanoniska länkar och hreflang. Flermarknadsstorefronts behöver korrekta kanoniska URL:er och hreflang-attribut på varje sida.
Strukturerad data. Produktschema, brödsmuleschema och organisationsschema bör server-renderas som JSON-LD. Det här är där headless frontends ofta överträffar monolitiska teman.
Core Web Vitals. LCP, INP och CLS är nåbara på gröna nivåer med en välbyggd headless frontend.

Leveransmodeller för headless frontend

Det finns tre sätt att få en headless frontend i produktion, var och en med olika kostnads- och tidsprofil.

Fullt custom-bygge

En byrå eller internt team bygger storefronten från grunden på ett ramverk som Nuxt eller Next.js, eller på ett headless commerce-ramverk som Alokai eller Hydrogen. Full kontroll över varje lager. Tar 4 till 9 månader för en icke-trivial storefront. Kräver löpande frontend-ingenjörsarbete för underhåll.

Frontend-as-a-service

En produktifierad headless frontend — som Frntkey — levererar en produktionsklar storefront med färdiga integrationer. Handlaren licensierar storefronten istället för att bygga den. Implementation tar 6 till 12 veckor. FaaS-leverantören underhåller kodbasen. Bäst för seriösa headless-projekt på Norce eller Shopware där storefront-kraven är standard snarare än radikalt anpassade.

Plattformsnativ headless

Shopify Hydrogen, Magento PWA Studio och liknande verktyg tillhandahåller ett headless-ramverk bundet till en specifik plattform. BFF-lagret ingår. Storefront-ramverket är föreskrivet. Mindre flexibelt än ett fullt custom-bygge, snabbare att starta. Bundet till plattformsleverantören.

När en headless frontend är rätt val

En headless frontend är rätt leveransmodell när:

Storefront-upplevelsen är en verklig konkurrensfördel. UX, checkout-flödet, innehållsintegrationen eller flerkanalsräckvidden behöver gå längre än vad ett plattformstema tillåter.
Teamet kan bära komplexiteten. Antingen finns ingenjörskapaciteten internt, eller så har leveranspartnern djup headless-erfarenhet och stannar involverad efter lansering.
Commerce-backenden är API-first och exponerar ett rent API. Norce, Shopware 6, commercetools, Shopify och Magento 2 med GraphQL kvalificerar alla.
Prestanda, flermarknadssöd eller flerkanalspublicering är verkliga krav, inte aspirationer.

En headless frontend är inte rätt val för en liten enmarknadsstorefront med standardkrav och ett litet team. Monolitisk är inte alltid fel svar.

Vanliga frågor

Vill du prata?

Se hur Frntkey passar din stack. Boka 30 minuter.

Boka demo