Klassisk vs. headless WooCommerce
Kortversjonen: bli ved klassisk WooCommerce når én PHP-server med god bufring kan betjene en enkeltbutikk, og gå headless når mobil hastighet begrenser inntekten, katalogen er stor, eller én katalog må mate flere grensesnitt. Headless er ikke automatisk bedre. Det er bedre under bestemte forhold, og en ombygging utenfor disse forholdene legger bare til kostnad.
Headless WooCommerce betyr at WordPress og WooCommerce forblir backend, eksponert gjennom Store API eller WPGraphQL, mens PHP-temaet erstattes av et frakoblet grensesnitt på Next.js eller Astro som rendrer kantbufret HTML.
Beslutningsmatrisen
| Kriterium | Klassisk WooCommerce | Headless WooCommerce |
|---|---|---|
| Katalogstørrelse | Opptil noen tusen SKU-er | Store kataloger, fasettert bla |
| Mobile Core Web Vitals | Bra med fullsides-bufring | Best, null PHP per forespørsel på kanten |
| Bygge- og driftskostnad | Lavere, én stack | Høyere, to stacker å vedlikeholde |
| Redaksjonell opplevelse | Native WordPress | Native WordPress, forhåndsvisning på eget domene |
| Flere grensesnitt | Én butikk | Én katalog, mange grensesnitt |
| Kassekompleksitet | Native, enklest | Serverautoritativ, mer kobling |
| Tid til lansering | Raskere | Rundt seks uker for en mellomstor butikk |
Når klassisk fortsatt vinner
For en enkeltbutikk under noen tusen produkter vil et klassisk WooCommerce på god EU-hosting med fullsides-bufring, ren database og optimaliserte ressurser nå mobil LCP under to sekunder uten ombygging. En norsk nettbutikk med noen hundre varer og et rent tema trenger ingen andre kodebase for å være rask. Hvis butikken din er treg i dag, er årsaken nesten alltid infrastruktur og teknisk gjeld, ikke rendringsmodellen. Fiks det først. Veiledningen for WooCommerce-ytelsesoptimalisering viser nøyaktig hvordan, og den er langt rimeligere enn å gå headless.
En butikk på visittkort-skala, en butikk med liten katalog, eller et team uten grensesnittkapasitet til å vedlikeholde en andre stack bør bli ved klassisk. Vedlikeholdskostnaden for to stacker er reell og tilbakevendende.
Når headless vinner
Headless tjener inn kostnaden sin i tre situasjoner. For det første, når mobile Core Web Vitals direkte former inntekten og en bufring-finjustert monolitt fortsatt ikke kan holde LCP under to sekunder under belastning. For det andre, når katalogen er stor og fasettert bla gjør PHP-rendering til flaskehalsen. For det tredje, når én katalog må mate flere flater, som en nettbutikk, en native app og en kiosk i butikken, fra én enkelt sannhetskilde. En norsk kjede som håndterer trafikktopper under salgsdager som julehandelen på mobil, er nettopp tilfellet der kantrendering betaler seg.
I de tilfellene rendrer grensesnittet ferdigbygd HTML på kanten uten PHP per forespørsel, noe som fjerner de verste halelatens-tilfellene, mens WooCommerce fortsatt eier katalog, ordrer, skatt og lager.
Delen alle undervurderer: kassen
Kassen er der headless WooCommerce-migreringer lykkes eller mislykkes. Betaling, skatt og ordreopprettelse må forbli serverautoritative inne i WooCommerce. Grensesnittet orkestrerer trinnene, men backend eier pengene. Å implementere kasselogikken på nytt i grensesnittet er måten butikker ender opp med feilprisede ordrer og ødelagt mva. Vi holder kassen på serversiden og lar grensesnittet drive opplevelsen rundt den.
Hvordan migreringen forløper
Tidsplanen domineres av to ting: å holde kassen korrekt, og å føre over SEO uten tap. Vi fryser datakontrakten først, bygger grensesnittet mot Store API, holder kassen i WooCommerce, bevarer hver URL og hvert strukturert-data-blokk, og bytter deretter over bak et CDN med den gamle butikken fortsatt tilgjengelig til den nye er bevist. En crawl-diff før lansering er det som hindrer rangeringsfallene som gir headless et dårlig rykte.
WordPress-nyhetsbrev
Tips, oppdateringer og WordPress-beste praksis en gang i måneden.
Vi respekterer personvernet ditt. Ingen spam.
Usikker på hvilken side du er på?
Vi bryter avveiningen ned mot din reelle katalog, trafikk og team før vi anbefaler noe. Ofte er det ærlige svaret å optimalisere den klassiske butikken først og vurdere headless senere.
Veier du klassisk mot headless?
Få en migreringsvurdering. Vi vurderer butikken din mot beslutningsmatrisen, modellerer kostnaden begge veier og sier rett ut hvilken som passer, selv når svaret er å bli ved klassisk.
Få en vurdering →Relaterte ressurser
- WooCommerce-ytelsesoptimalisering - prøv dette før en ombygging
- WooCommerce-utvikler - hvordan vi jobber med butikker
- Shopify Plus vs. headless WooCommerce - hvis du også veier Shopify
- Headless WordPress: Next.js vs. Astro - valg av grensesnitt-rammeverk
- Migreringscasestudie: PageSpeed 18 til 99 - en reell ombygging til en moderne stack, lastetid 12 s til 0,3 s, med fullstendige målinger
