DTC-merk migreerde Shopify naar Headless Next.js: 249% ROAS-stijging
Een DTC-huidverzorgingsmerk migreren naar Headless Next.js: 249% ROAS-stijging
In maart 2024 kwam een DTC-huidverzorgingsmerk naar ons toe met een probleem dat pijnlijk veel voorkomt: hun Shopify-theme was traag, hun advertentiebudget werd verspild, en hun Core Web Vitals waren zo slecht dat Google hen in feite deprioriteerde in zoekresultaten. Acht maanden later was hun return on ad spend met 249% gestegen, hun LCP gedaald van 8,2s naar 1,4s, en elke Core Web Vitals-metriek was glanzend groen. Dit is het volledige verhaal van hoe we daar zijn gekomen — de architectuurbeslissingen, de afwegingen, de fouten, en de werkelijke cijfers.
Inhoudsopgave
- Het startpunt: Een Shopify-winkel in nood
- Waarom headless en waarom nu
- De stack kiezen: Next.js, Hydrogen, en de Storefront API
- De migratiearchitectuur
- Core Web Vitals repareren: Wat maakte echt het verschil
- Het ROAS-verhaal: Hoe performance winst werd
- Tijdlijn, budget en werkelijke kosten
- Lessen geleerd en wat we anders zouden doen
- Veelgestelde vragen
Het startpunt: Een Shopify-winkel in nood
Laten we ze GlowCo noemen (NDA, je kent het). Ze zijn een DTC-huidverzorgingsmerk met een jaarlijkse omzet van ongeveer $3,2 miljoen via hun Shopify Plus-winkel. Ze hadden 47 SKU's, een abonnementsmodel via Recharge, en gaven ongeveer $85.000 per maand uit aan Meta- en Google Ads.
Het probleem was niet hun product of hun marketingteam. Het probleem was hun website.
Dit zagen hun metreken eruit toen ze contact met ons opnamen:
| Metriek | Waarde (maart 2024) | Status |
|---|---|---|
| Largest Contentful Paint (LCP) | 8,2s | 🔴 Slecht |
| First Input Delay (FID) | 340ms | 🔴 Slecht |
| Cumulative Layout Shift (CLS) | 0,42 | 🔴 Slecht |
| Interaction to Next Paint (INP) | 510ms | 🔴 Slecht |
| Mobile PageSpeed Score | 18/100 | 🔴 |
| Desktop PageSpeed Score | 42/100 | 🟡 |
| Bounce Rate (Mobile) | 71% | — |
| Conversion Rate | 1,2% | — |
| Meta Ads ROAS | 1,8x | — |
| Google Ads ROAS | 2,1x | — |
Een PageSpeed-score van 18 op mobiel. Ik heb slechte Shopify-winkels gezien, maar deze had een theme met 2,4MB ongeoptimaliseerde JavaScript, 14 renderblokkerend derde-partij scripts (Klaviyo, Yotpo, een loyaliteitsapp, twee verschillende popup-tools, en een handvol analyticscripts), en hero-afbeeldingen die 3MB PNG's waren zonder responsieve schaling.
Hun Shopify-theme was een zwaar aangepaste versie van een populair premium-theme, gedurende drie jaar aangepast door minstens vier verschillende freelancers. De Liquid-templatecode was een chaotische verzameling voorwaardelijke logica die niemand volledig begreep.
Maar hier is wat echt mijn aandacht trok: hun marketingteam toonde ons dat hun Meta Ads-kwaliteitsscores maanden achtereen waren gedaald. Meta's algoritme bestraft landingspagina's die langzaam laden. Google Shopping was hetzelfde verhaal — hun ads kregen minder indrukken tegen hogere CPC's omdat de landingspagina-ervaringsscore inzakte.
Ze verloren niet alleen organisch verkeer. Ze betaalden letterlijk meer voor elke klik omdat hun site traag was.
Waarom headless en waarom nu
GlowCo had al de voor de hand liggende opties onderzocht. Ze hadden geprobeerd hun bestaande Shopify-theme te optimaliseren — sommige apps verwijderd, afbeeldingen gecomprimeerd, overgegaan naar een iets lichter theme. Het hielp, maar nauwelijks. LCP ging van 8,2s naar ongeveer 6,8s. Nog steeds diep rood.
Het fundamentele probleem is iets wat we regelmatig zien met Shopify's monolithische architectuur: je controleert de renderingpipeline niet. Shopify's servers renderen Liquid-templates, injecteren hun eigen JavaScript (Shopify's core JS alleen is ~200KB), en je bent afhankelijk van wat het theme en apps doen.
Headless gaan betekende het decoupling van de frontend volledig van Shopify's renderinglaag. Shopify zou nog steeds de commerce-backend afhandelen — producten, inventaris, checkout, betalingen — maar we zouden de hele klantenervaring helemaal opnieuw bouwen.
De timing maakte sense om drie redenen:
Shopify's Storefront API was aanzienlijk volwassener geworden. Begin 2024 dekte de Storefront API vrijwel alles af wat je nodig had voor een volledige winkelervaring, inclusief winkelmand, klantenaccounts en metaveld-toegang.
Shopify Checkout Extensibility was nu beschikbaar op Plus. Dit betekende dat we checkout niet hoefden opnieuw te bouwen (wat, eerlijk gezegd, waar headless vroeger strandde).
De business case was duidelijk. Als het verbeteren van de sitesnelheid hun CPC met slechts 15-20% kon verlagen en tegelijkertijd de omzettingspercentages kon verbeteren, zou het project binnen 3-4 maanden terugbetaald zijn.
De stack kiezen: Next.js, Hydrogen, en de Storefront API
Dit is waar het interessant wordt, omdat we een echt debat over de stack hadden.
De kandidaten
Shopify's officiële antwoord voor headless is Hydrogen — hun React-gebaseerde framework gebouwd op Remix. Het is nauw geïntegreerd met Shopify's API's en gedeployed op Oxygen (Shopify's hostingplatform).
Maar we kozen uiteindelijk voor Next.js 14 (App Router) met gebruik van Shopify's Hydrogen React-bibliotheek — niet het volledige Hydrogen/Remix-framework.
Hier is waarom:
| Factor | Hydrogen (Remix/Oxygen) | Next.js + Hydrogen React | Astro + Storefront API |
|---|---|---|---|
| SSR/SSG flexibiliteit | Goed (Remix streaming) | Uitstekend (ISR, SSG, SSR, RSC) | Uitstekend (Islands, SSG) |
| React-ecosysteem | Volledig | Volledig | Gedeeltelijk (Islands) |
| Hostingopties | Oxygen alleen (of zelf hosten) | Vercel, Netlify, AWS, zelf hosten | Elke statische host + SSR |
| Shopify-integratiediepte | Inheems | Via @shopify/hydrogen-react | Handmatige API-aanroepen |
| Teamvertrouwdheid | Laag | Hoog | Gemiddeld |
| Edge-rendering | Oxygen Workers | Vercel Edge, Cloudflare | Cloudflare, Netlify |
| Community/ecosysteem | Groeiend | Massaal | Groeit snel |
We hebben Astro serieus overwogen. Voor een inhoudsrijke site met minder interactiviteit zou Astro's partial hydration-model ideaal zijn geweest. Maar GlowCo's site had veel client-side interactiviteit nodig — een productquiz, een skincareroutinabuilder, snelle toevoegen aan winkelmandlade, realtimebeheer van abonnementen. React Server Components van Next.js gaven ons de beste balans tussen server-gerendereerde performance en client-side rijkheid.
We kozen er ook voor op Vercel te implementeren in plaats van Oxygen. Vercel's edge-netwerk en ISR-mogelijkheden (Incremental Static Regeneration) gaven ons fijngranulaire cachebeheer dat we op dat moment niet gemakkelijk op Oxygen konden repliceren.
Onze uiteindelijke stack:
- Next.js 14 (App Router met React Server Components)
- @shopify/hydrogen-react voor winkelmand, Storefront API-hulpprogramma's
- Shopify Storefront API (GraphQL) voor productgegevens
- Shopify Plus Checkout (inheems, niet aangepast gebouwd)
- Sanity CMS voor redactionele inhoud, landingspagina's en blogposts
- Vercel voor hosting en edge-functies
- Recharge via hun headless API voor abonnementen
- Klaviyo asynchroon geladen via een lichte aangepaste integratie
Als je een vergelijkbare setup evalueert, heeft ons team bij Social Animal diepgaande ervaring met deze exacte architectuur — we hebben onze benadering gedocumenteerd met betrekking tot headless CMS-ontwikkeling en Next.js-ontwikkeling als je het grotere plaatje wilt.
De migratiearchitectuur
Datalagen
We hielden Shopify als single source of truth voor alle commercegegevens. Producten, varianten, inventaris, prijzen, klanten, bestellingen — alles blijft in Shopify. Dit was niet-onderhandelbaar. Shopify's commerce-engine is beproefd en hun omzettingspercentages van checkout zijn moeilijk te verslaan.
Voor inhoud stelden we Sanity in als een headless CMS. Productpagina's haalden gestructureerde gegevens uit Shopify (prijzen, varianten, inventaris) en redactionele inhoud uit Sanity (ingrediëntverhalen, gebruiksgidsen, cross-sell-verhalen). Deze scheiding is cruciaal — het betekent dat het marketingteam pagina-inhoud kan bijwerken zonder productgegevens aan te raken, en het operationsteam inventaris kan beheren zonder landingspagina's te breken.
// Vereenvoudigde productpaginaopvragen (Next.js App Router)
async function getProductPageData(handle: string) {
const [shopifyProduct, sanityContent] = await Promise.all([
getShopifyProduct(handle), // Storefront API GraphQL
getSanityProductContent(handle) // Sanity GROQ-query
]);
return {
product: shopifyProduct,
editorial: sanityContent,
// Metavelden samenvoegen voor gestructureerde gegevens
structuredData: buildProductSchema(shopifyProduct, sanityContent),
};
}
Renderstrategie
Niet elke pagina heeft dezelfde renderbenadering nodig. We waren hier doelbewust over:
- Productpagina's: ISR met 60-seconden-revalidatie. Producten veranderen niet elke seconde, maar we hadden inventarisnauwkeurigheid nodig binnen een minuut.
- Collectiepagina's: ISR met 5-minuten-revalidatie. Deze veranderen nog minder frequent.
- Homepage en landingspagina's: ISR met revalidatie op aanvraag geactiveerd door Sanity-webhooks. Wanneer het marketingteam publiceert, raakt een webhook onze revalidatie-eindpunt.
- Winkelmand/accountpagina's: Volledig aan client-zijde met server-gerenderete shells. Deze zijn inherent dynamisch.
- Blog/redactioneel: Statische generatie bij bouwtime met revalidatie op aanvraag.
De winkelmandobjectimplementatie
Dit is waar @shopify/hydrogen-react zijn waarde bewees. De CartProvider en bijbehorende hooks handelen al het winkelmandstatushoogste beheer af, inclusief optimistische UI-updates. De winkelmand leeft in Shopify's Storefront API (niet lokale staat), wat betekent dat het wordt behouden tussen sessies en apparaten.
// Winkelmandje met optimistische updates
'use client';
import { CartProvider, useCart } from '@shopify/hydrogen-react';
function CartDrawer() {
const { lines, totalQuantity, cost, linesUpdate } = useCart();
return (
<Sheet>
{lines.map((line) => (
<CartLine
key={line.id}
line={line}
onQuantityChange={(quantity) =>
linesUpdate([{ id: line.id, quantity }])
}
/>
))}
<CartTotal cost={cost} />
<CheckoutButton />
</Sheet>
);
}
Checkout
We hebben geen aangepaste checkout gebouwd. Dit is belangrijk. Shopify's native checkout (vooral op Plus met Checkout Extensibility) heeft jaren A/B-testen en optimalisatie ingebakken. Shop Pay alleen kan het checkout-omzettingspercentage met 50% verhogen voor terugkerende klanten. We pasten het aan met behulp van Checkout UI Extensions voor merkconformiteit en upsell-widgets, maar de kernstroom blijft Shopify-native.
Core Web Vitals repareren: Wat maakte echt het verschil
Dit is het onderdeel dat de meeste casestudies onderschatten. Headless gaan lost je Core Web Vitals niet magisch op. Je kunt absoluut een trage Next.js-site bouwen. Ik heb het gebeuren zien. Wat telt is de specifieke optimalisaties die je doet zodra je controle hebt over de renderingpipeline.
LCP: Van 8,2s naar 1,4s
De single grootste LCP-verbetering kwam uit drie dingen:
Renderblokkeringsresources elimineren. In het oude Shopify-theme laadden 14 derde-partij scripts synchroon. In onze Next.js-build is kritieke CSS inline, JavaScript is gedeeld en wordt alleen waar nodig geladen, en derde-partij scripts laden na het renderen van de hoofd-inhoud met
next/scriptmetstrategy="lazyOnload".Afbeeldingsoptimalisatie met
next/image. We serveerden responsieve afbeeldingen in WebP/AVIF-formaat, correct geschaald voor elk viewport. Hero-afbeeldingen gingen van 3MB PNG's naar ~80KB AVIF-bestanden. Het LCP-element (meestal de hero-afbeelding) laadt nu als een prioriteit voorgeprefetched bron.Edge-caching met stale-while-revalidate. ISR op Vercel betekent dat de eerste bezoeker na een revalidatievenster een gecachte pagina onmiddellijk krijgt terwijl de server op de achtergrond opnieuw genereert. De meeste bezoekers wachten nooit op een serverrender.
CLS: Van 0,42 naar 0,02
Layoutverschuiving werd veroorzaakt door afbeeldingen zonder dimensies, lettertypen die laat laden (FOUT), en dynamisch geïnjecteerde app-widgets. Onze fixes:
- Alle afbeeldingen hebben expliciete
widthenheightattributen (of gebruikenaspect-ratioCSS) - Lettertypen voorgeprefetched met
font-display: swapen grootte-aangepaste fallbacks - Geen dynamisch geïnjecteerde derde-partij widgets boven aan de vouw
- Skeleton UI-onderdelen voor elke asynchrone inhoud
INP: Van 510ms naar 78ms
Interaction to Next Paint was het moeilijkst op te lossen. Het oude theme had event-handlers aan de hele DOM bevestigd, jQuery-waterfalls, en zware client-side JavaScript die de main thread blokkeerde.
React Server Components waren de sleutel hier. Door de meeste van de pagina op de server te renderen en alleen interactieve componenten (winkelmandje, productkiezers, quizwidget) te hydrateren, reduceerden we dramatisch de hoeveelheid client-side JavaScript. Onze totale client-bundel voor de productpagina daalde van 2,4MB naar 187KB.
De nummers daarna
| Metriek | Voor (maart 2024) | Na (november 2024) | Status |
|---|---|---|---|
| LCP | 8,2s | 1,4s | 🟢 Goed |
| FID | 340ms | 12ms | 🟢 Goed |
| CLS | 0,42 | 0,02 | 🟢 Goed |
| INP | 510ms | 78ms | 🟢 Goed |
| Mobile PageSpeed | 18 | 94 | 🟢 |
| Desktop PageSpeed | 42 | 99 | 🟢 |
| Totaal JS (Productpagina) | 2,4MB | 187KB | — |
| TTFB (p75) | 1,8s | 0,12s | — |
Het ROAS-verhaal: Hoe performance winst werd
Dit is waar de theorie in de praktijk wordt getest. Niemand migreert naar headless voor de lol — de business case moet er zijn.
De nieuwe site lanceerde in fasen tussen juli en oktober 2024. Tegen november hadden we schone gegevens om te vergelijken. De resultaten waren, eerlijk gezegd, beter dan we projecteerden.
Directe omzettingsimpact
Bounce rate op mobiel daalde van 71% naar 38%. Dat is alleen al massief — het betekent dat 46% meer bezoekers zelfs het product bleven bekijken. Omzettingspercentage op mobiel steeg van 1,2% naar 2,8%.
Omzettingspercentage op desktop verbeterde van 2,4% naar 3,9%.
Totaal geblend omzettingspercentage: 1,2% → 3,1%
Adplatformimpact
Dit is het onderdeel dat zelfs ons verraste. Binnen 6 weken nadat alle Core Web Vitals groen waren:
- Google Ads CPC daalde 22% — Google's landingspagina-ervaringsscore verbeterde, wat direct de cost-per-click verlaagde
- Meta Ads CPM daalde 18% — Meta's algoritme begon hun advertenties meer te tonen (beter landingspagina = hogere relevantiepunten = lagere kosten)
- Google Shopping indrukshare steeg 34% — Betere pagina-ervaring betekende dat Google meer bereid was hun productaanbiedingen te tonen
Het gecombineerde effect op ROAS:
| Kanaal | ROAS Voor | ROAS Na | Verandering |
|---|---|---|---|
| Meta Ads | 1,8x | 5,2x | +189% |
| Google Search Ads | 2,1x | 7,4x | +252% |
| Google Shopping | 2,4x | 8,8x | +267% |
| Geblend | 1,95x | 6,8x | +249% |
De 249% geblende ROAS-stijging kwam uit twee samengestelde factoren: lagere cost-per-click EN hoger omzettingspercentage. Wanneer je kliks minder kosten en elke klik een hoger percentage omzet, compoundeert de wiskunde prachtig.
Organisch verkeer
Ik zou het niet af moeten maken zonder de SEO-impact te vermelden. Binnen 4 maanden nadat alle Core Web Vitals groen waren:
- Organisch verkeer steeg 67%
- Gemiddelde positie voor doelsleutelwoorden verbeterde met 4,2 posities
- Organische opbrengsten stegen 89%
Google is duidelijk geweest dat pagina-ervaring een rankingfactor is. Dit was real-world bewijs.
Tijdlijn, budget en werkelijke kosten
Ik geloof in transparantie over wat projecten als deze werkelijk kosten. Hier is de werkelijke uitsplitsing:
Tijdlijn: 7 maanden van kickoff tot volledige lancering (met een gefaseerde rollout vanaf maand 5)
Team: 2 senior frontend-ontwikkelaars, 1 Shopify backend-specialist, 1 ontwerper, 1 projectmanager (deeltijd)
Totale projectkosten: ~$145.000
Maandelijkse hosting/infrastructuur: ~$350/maand (Vercel Pro + Sanity Growth-plan)
Doorlopende Shopify Plus: $2.300/maand (onveranderd — ze waren al op Plus)
Terugverdientijd: Het project betaalde zichzelf binnen 2,8 maanden terug op basis van verhoogde opbrengsten van verbeterde ROAS en omzettingspercentages.
Is dit soort investering geschikt voor elk merk? Nee. Als je minder dan $1 miljoen per jaar doet, werkt de wiskunde waarschijnlijk nog niet. Maar voor DTC-merken die meer dan $50.000 maandelijks aan advertenties besteden met slechte Core Web Vitals, is de ROI bijna altijd aanwezig. We helpen graag met specifieke details — neem contact met ons op of controleer onze prijsmodellen voor headless commerce-projecten.
Lessen geleerd en wat we anders zouden doen
Wat werkte
- Shopify checkout native houden was 100% de juiste oproep. Geen regressie in checkout-omzetting.
- ISR met revalidatie op aanvraag gaf ons het beste van twee werelden: statische performance met dynamische inhoud.
- Gefaseerde rollout (eerst blog/redactionele pagina's lanceren, dan collecties, dan PDP's, dan homepage) liet ons performance in productie valideren voordat we high-traffic pagina's migreerden.
Wat we anders zouden doen
- De Recharge headless-migratie eerder starten. Hun headless API had enkele onverwachte onverwachtechten, en het kostte 3 weken van onze tijdlijn. Als je Recharge gebruikt, budget extra tijd.
- Testinfrastructuur van dag één opzetten. We voegden het in maand 2 toe en verloren wat vroege vergelijkingsgegevens.
- Vercel's Edge Config gebruiken voor feature flags in plaats van de omgevingsvariabele-benadering waar we mee begonnen. Zou de gefaseerde rollout schoner hebben gemaakt.
Een eerlijke kanttekening
De headless-benadering voegt operationele complexiteit toe. GlowCo beheert nu twee systemen in plaats van één. Hun marketingteam kan niet zomaar een Shopify-app installeren en deze op de winkel zichtbaar maken — elke nieuwe derde-partij integratie vereist ontwikkelingwerk. Voor GlowCo, op hun schaal en advertentiebudget, overweegt de prestatieverbetering deze friction verre. Maar het is een echte afweging die je van het begin af aan moet begrijpen.
Veelgestelde vragen
Hoe lang duurt het om een Shopify-winkel naar headless Next.js te migreren? Voor een typisch DTC-merk met 30-100 SKU's, verwacht u 4-8 maanden afhankelijk van complexiteit. GlowCo's project duurde 7 maanden vanwege aangepaste functies zoals hun skincare-quiz en Recharge-abonnementsintegratie. Eenvoudiger winkels met minder aangepaste functies kunnen in 4-5 maanden worden gedaan.
Breekt headless gaan Shopify-apps? Ja, de meeste theme-afhankelijke Shopify-apps werken niet in een headless setup. Apps die UI in je winkel injecteren (review-widgets, loyaliteitspoppen, upsell-tools) moeten worden vervangen door API-gebaseerde alternatieven of aangepaste componenten. Backend-apps (inventarisbeheer, verzending, enz.) blijven prima werken omdat ze de frontend niet aanraken.
Is Hydrogen of Next.js beter voor headless Shopify? Het hangt af van je team en eisen. Hydrogen (gebouwd op Remix) biedt out-of-the-box nauwere Shopify-integratie en is Shopify's officieel ondersteunde pad. Next.js biedt een groter ecosysteem, meer hostingflexibiliteit en React Server Components. We kozen Next.js voor GlowCo vanwege de bestaande expertise van het team en Vercel's edge-caching mogelijkheden. Beide zijn uitstekende keuzes.
Hoeveel kost een headless Shopify-migratie in 2025? Realistische budgetten variëren van $80.000 tot $250.000+ afhankelijk van winkelcomplexiteit, aangepaste functies en agencyuurtarieven. GlowCo's project was $145.000. Wees voorzichtig met bureaus die onder $50K voor een volledige headless build citeren — je krijgt waarschijnlijk een sjabloon met beperkte aanpassingen. Maandelijkse infrastructuurkosten variëren doorgaans van $200-600 voor hosting en CMS.
Beïnvloeden Core Web Vitals werkelijk Google Ads-kosten? Ja. Google Ads gebruikt een "Landing Page Experience"-score als onderdeel van zijn Quality Score-berekening. Betere pagina-snelheid en Core Web Vitals-scores leiden tot hogere Quality Scores, wat direct uw cost-per-click verlaagt. GlowCo zag een 22% CPC-verlaging nadat hun Core Web Vitals verbeterden. Meta gebruikt vergelijkbare signalen voor advertentierelevantiebepaling.
Kun je Shopify checkout houden bij headless gaan? Absoluut, en we raden het sterk aan. Shopify's checkout is zeer geoptimaliseerd en bevat functies zoals Shop Pay (die checkout-omzetting met 50%+ kan verhogen voor terugkerende shoppers). Met Shopify Plus kunt u Checkout Extensibility gebruiken om de uitstraling aan te passen en upsells toe te voegen terwijl u de kerncheckout-stroom intact houdt.
Wat is het verschil tussen headless Shopify en Shopify Hydrogen? Headless Shopify is een breed concept — elke aangepaste frontend die Shopify's Storefront API gebruikt. Hydrogen is Shopify's specifieke framework voor het bouwen van headless-winkels, gebouwd op Remix en gedeployed op Shopify's Oxygen-hosting. Je kunt headless gaan met Next.js, Astro, Nuxt of elk framework. Hydrogen is slechts één optie binnen het headless Shopify-ecosysteem.
Is headless het waard voor kleine Shopify-winkels? Meestal niet. Als je minder dan $1 miljoen jaarlijkse opbrengsten hebt en minder dan $20.000 per maand aan advertenties uitgeeft, zal de kosten van een headless-migratie waarschijnlijk geen zinvolle ROI opleveren. Focus eerst op het optimaliseren van je bestaande theme — verwijder ongebruikte apps, comprimeer afbeeldingen, schakel over naar een performantie-gericht theme zoals Dawn. Overweeg headless wanneer je advertentiebudget hoog genoeg is dat zelfs kleine efficiëntie-verbeteringen in aanzienlijke dollarbedragen worden omgezet.