Cloudflare Workers og WordPress: WooCommerce levert fra edge

#Cloudflare Workers og WordPress: WooCommerce levert fra edge

Cloudflare Workers kjører JavaScript i ytterkanten av Cloudflares globale nettverk. WordPress kjører PHP på én origin-server. Å sette Workers foran WordPress er arkitekturen som lar en WooCommerce-butikk arve edge-nettverkets ytelse uten å skrive om CMS-et. Avveiningene er reelle og fortjener å nevnes eksplisitt.

Denne artikkelen forankres i pilaren headless WordPress-tjeneste og henger sammen med renderingsbeslutningen ISR vs SSR og økonomien i headless WordPress.

#TL;DR

• Workers håndterer lese-stien, WordPress håndterer skriving og forfatterskap.
• WooCommerce-katalog og produktdetaljer rendres på edge; handlekurv og checkout blir på origin.
• Cache-invalidering er webhook-drevet, ikke tidsbasert.
• Cloudflare Pages begrenser _redirects-filen til 2000 regler, planlegg rundt det.
• Workers gratisplan begrenser komprimert bundle til 1 MB; betalt plan øker dette.

#Hva Cloudflare Workers faktisk er

Workers er et V8-isolat-runtime som kjører JavaScript, TypeScript og WebAssembly inne i Cloudflares edge-nettverk (Cloudflares nettverksside lister datasentrene). Det er ikke Node.js, ikke en Lambda-container, og ikke et sted å kjøre PHP. WordPress blir værende på sin origin; Workeren er en JS-revers-proxy som sitter foran.

Noen kjennetegn som former hva du kan og ikke kan gjøre på Workers foran WordPress:

• Ingen PHP. En Worker kan ikke kjøre wp-load.php. Den kan hente fra /wp-json/wp/v2/posts og /wp-json/wc/v3/products, transformere responsen og returnere HTML eller JSON. Hver autentisert mutasjon håndteres av WordPress-installasjonen.
• CPU er budsjettet som biter først. Gratisplanen gir omtrent 10 ms CPU per forespørsel, betalt løfter dette mot 30 ms, og Unbound går høyere. En statisk rendret produktside som leser fra Workers KV koster nesten ingenting; en SSR-mal-loop som aggregerer fire /wp-json/-kall og kjører Markdown-til-HTML på beskrivelsen, sprenger taket fort på gratisplanen.
• To lagringslag, to konsistensmodeller. Workers KV er eventuelt konsistent og rask for edge-lesninger; skrivinger kan bruke opp mot et minutt på å propagere globalt og burst-skrivinger blir throttlet. D1 er sterkt konsistent SQLite på edge. For WooCommerce er KV greit for cachede /products-listinger; live lagertellere hører hjemme på WordPress-origin eller i Durable Objects.
• Bundle-størrelse er reell. Det komprimerte Worker-skriptet ligger på 1 MB i gratisplanen, 10 MB i betalt. En full Astro- eller Next.js-app med bilder og språk-bundler trenger den betalte planen.
• Naboprodukter løser overlappende problemer. Cloudflare Pages Functions sitter i samme runtime og er det ergonomisk riktige hjemmet for en Astro- eller Next.js-app. Vercel Edge Functions og AWS Lambda@Edge løser lignende formater med andre kostnadsmodeller. Workers vinner når WordPress allerede ligger bak Cloudflare-DNS og teamet vil ha én plattform for cache, WAF og rendering.

Kode skrevet mot Web Platform-API-er (Fetch, Request, Response, Streams, Web Crypto) kjører uten endring. Kode som er avhengig av Node-standardbiblioteket, native moduler eller filsystemtilgang gjør det ikke.

#Tolags-arkitekturen

I en Workers + WordPress-løsning deler to systemer ansvaret:

WordPress-origin. Forfatterskap (Block Editor, REST API, WP-CLI), skriveoperasjoner (opprett, oppdater, slett innlegg; ordreopprettelse; brukerregistrering) og kilden til sannhet for innhold og produktdata.

Cloudflare Workers edge. Rendering av lese-stien (HTML-generering), API-aggregering (samle flere WordPress REST-endepunkter til én frontend-respons), edge-caching (per rute, per tag) og tverrgående hensyn (geo-ruting, A/B-varianter, header-omskriving).

Grensen er skarp. Alt som muterer tilstand bor på WordPress-origin. Alt som leser, rendrer eller aggregerer kan bo på Workers. Handlekurv og checkout sitter på grenselinjen fordi de er stateful, men leselastige.

#Konkrete WooCommerce-mønstre som flytter til Workers

Noen Workers-foran-WooCommerce-mønstre vi har levert eller sett levert rent, med norsk handelskontekst:

Edge-cache for /wp-json/-lesninger. En Worker-rute matcher /wp-json/wc/v3/products* og leverer fra cache når cache-nøkkelen (URL pluss et lite sett vary-headere) er fersk. Lagerfølsomme endepunkter som /wp-json/wc/v3/products/<id> får kortere TTL pluss webhook-invalidering på woocommerce_product_set_stock-actionen. PHP-origin slutter å håndtere produktlistings-fan-out fra feed-eksportører, prisroboter og bot-trafikk.

Cart-aware sidecaching. Katalogsiden caches, men minihandlekurv-fragmentet ikke. Workeren leser wp_woocommerce_session_*-cookien, henter handlekurv-fragmentet fra origin og syr responsen sammen. Katalog-HTML-en er cachebar på tvers av alle anonyme brukere; handlekurv-fragmentet er per-sesjon og ucachet. Vipps- og Klarna NO-callbacker treffer den samme grensen: Workeren markerer responsen som dynamisk slik at ordrebekreftelses-visningen ikke henger på en utdatert cache-variant. Det er også her MobilePay-overgangen fra Vipps for nordiske checkout-flyter blir håndtert, med dual-routing før kuttdatoen og enkelt-routing etter.

Bildtransformasjon på edge. WooCommerce-produktbilder lastes opp til WordPress-mediebiblioteket i full oppløsning. En Worker-rute foran /wp-content/uploads/ skalerer, omkoder til AVIF og caches på edge. Origin slutter å kjøre Imagick på hver ucachet forespørsel, som er en av de mest støyende CPU-kildene på en travel WooCommerce-boks.

Geo-rettede omdirigeringer og A/B-varianter. Workers leser cf-ipcountry og skriver om /shop/ til /shop/se/ for svenske besøkende, eller tildeler en A/B-kohort-cookie og leverer variant-HTML, alt uten en runde til PHP. Bring-fraktsporing er et godt eksempel: en Worker-rute foran /sporing/ slår opp Bring-tracking-API-et, caches per kolli-ID i kort tid og slipper origin for det offentlige sporingsmønsteret. Husk håndtering av æ/ø/å i URL-er: encode disse som UTF-8 prosent-escapede sekvenser før cache-key-utledning, ellers ser Workeren /sporing/forsen-pakke/ og /sporing/fors%C3%A5n-pakke/ som to separate poster.

Egendefinerte WAF-regler utover WAF Pro-standardene. Blokker POST mot /xmlrpc.php, ratebegrens /?s=-søk fra én ASN, slipp forespørsler som inneholder wp-config i stien. Workers gir et programmerbart lag over den administrerte WAF-en uten å betale for Enterprise-regelplasser.

Det som blir værende på WordPress-origin: Block Editor-lagringer, ordreopprettelse fra autentisert checkout, callbacks fra betalingsleverandører (Vipps, Klarna NO, MobilePay), admin-sesjoner og webhook-fan-outen som utløser cache-invalidering på Workeren. PHP-serveren skalerer til redaksjonsvolum pluss ordrevolum, ikke til anonym katalogtrafikk.

#Hvor grensen skal trekkes

Tre rutekategorier, tre ulike renderingsregler:

Statisk eller ISR på edge. Markedssider, blogginnlegg, kategoriarkiver, produktdetaljsider. Caches aggressivt med webhook-drevet invalidering.

SSR på edge uten cache. Handlekurv, konto, dashboards, checkout-sider som er personlige og sesjonsdrevne. Workers kjører renderingen ved hver forespørsel; WordPress leverer dataene via REST.

Kun origin, ingen Worker. WP Admin (/wp-admin/), Block Editor og WordPress core REST-endepunkter brukt internt for forfatterskap. Workers-rutekonfigurasjonen ekskluderer disse eksplisitt fra edge-laget.

Den vanlige feilen er å forsøke å flytte handlekurven til edge-cachen. Handlekurven er per-bruker-tilstand; å cache den på tvers av brukere er en sikkerhetshendelse som venter på å skje. SSR på edge er den riktige modellen: Workeren rendrer HTML-en for denne brukerens handlekurv, men cacher ikke resultatet.

#Cache-invalidering, det bærende elementet

ISR på edge er korrekt kun når invalideringen er korrekt. Mønsteret som fungerer:

Tagg hver cachet respons. Hver rendret side merkes med WordPress-post-ID-er, term-ID-er og produkt-ID-er den refererer til. Cloudflare Workers-cachen støtter tag-basert purging via cache-API-et.

Webhook ved hver WordPress-skriving. Publisering, slug-endring, sletting av innlegg, lageroppdatering, prisendring. Hver av dem fyrer en webhook til en Workers-rute som oversetter “post 8421 endret seg” til “purge tag wp-post-8421” via Cloudflare-API-et.

Tidsbasert revalidering kun som sikring. Et stale-while-revalidate-vindu på 1 time fanger opp feil i webhook-leveranser. Det er ikke hovedmekanismen. En side som revalideres hvert 60. sekund, bygges 60 ganger i timen per side; med 5000 sider gir det 300000 unødvendige renderinger.

Rekkefølgen betyr noe: invalider først, skriv så. Når en WordPress-publisering fyrer webhooken, invaliderer Workeren taggen, og neste forespørsel bygger siden på nytt fra den nå oppdaterte origin. Snur du rekkefølgen, sniker en utdatert rendering seg inn i cachen og blir værende til neste invalidering.

#Grenser å planlegge rundt

Cloudflares dokumenterte plattformgrenser:

• _redirects-tak på Cloudflare Pages: 2000 regler. Over det feiler deploys. Vi sporer dette i byggepipelinen og ligger nå på 1600.
• Worker-bundle-størrelse: 1 MB komprimert i gratisplanen, høyere i betalte planer. Ruter som leverer fulle Astro- eller Next.js-applikasjoner trenger den betalte planen.
• CPU-tid per forespørsel: 10 ms i gratisplanen, 50 ms eller mer i betalte. SSR med tung mal-logikk passerer gratisplanens tak fort; ISR-cachede responser bruker nesten ingen CPU.
• Subforespørsler per forespørsel: 50 i gratisplanen, mer i betalte. WordPress REST-aggregering som vifter ut til flere endepunkter treffer dette taket på komplekse sider.

Det vanlige arkitektoniske svaret: design for den betalte planen, lever på den betalte planen, behandle gratisplanen som en utviklingssandkasse.

#Feilformer det er verdt å kjenne før du shipper

Noen konkrete måter vi har sett en Workers + WordPress-løsning ryke eller overraske teamet på:

KV-skrivethrottling under burst-invalidering. Et bulk-produktimport som rører 5000 SKU-er fyrer 5000 woocommerce_update_product-webhooks. Workeren oversetter hver til en KV-skriving på en cache-nøkkel per SKU. KV-skrivekapasiteten er ratebegrenset per namespace, så skrivinger kø-er seg og cachen blir værende utdatert i flere minutter. Fiksen er debouncing på WordPress-siden og batchede invalideringer, eller å bytte ut per-SKU-mappingen med ett tag-purge-kall mot Cloudflare cache-API-et.

Cold-start vs warm-start på lavtrafikk-locales. Et V8-isolat som gjenbrukes på tvers av forespørsler legger til nesten ingen oppstartskostnad. Den første forespørselen inn til en region etter et langt idle-vindu betaler ekstra 5 til 50 ms mens isolatet booter og skriptet parses. For en sparsomt trafikkert lokal side (en regional landingsside for /oslo/, /bergen/ med lavere volum) ser p99-latens verre ut enn p50. Syntetiske monitorer fra mange lokasjoner glatter dette ut; RUM viser det som det er.

1 MB-bundle-taket på gratisplanen. En full Next.js 15-app med Cloudflare-adapteren, react-server-dom, et par språk-bundler og WooCommerce REST-klienten passerer 1 MB komprimert lett. Deployen feiler på opplasting, ikke i runtime. Plan for betalt (10 MB) eller splitt rendering på flere Worker-skript.

Subforespørsels-fan-out på aggregerte sider. En kategoriside som henter termin, produkter, relaterte kategorier, brødsmuler og menyen treffer fem /wp-json/-endepunkter. Gratisplanen begrenser subforespørsler til 50 per Worker-invokasjon, betalt til 1000. Aggregeringslag som prekomponerer responsen på WordPress-siden, eller et enkelt GraphQL-endepunkt via WPGraphQL, holder antallet forutsigbart.

Webhook-leveringsfeil etterlater utdatert cache. WordPress fyrer webhooken i shutdown-actionen; hvis PHP-FPM-workeren timer ut eller nettet ryker, når webhooken aldri Workeren. For MobilePay-rebrand-overgangs-webhooks, der callback-formatet endret seg under flyttingen fra Vipps, betyr manglende sikring at en gammel render kan vise feil betalingsstatus. Tag-basert stale-while-revalidate på 1 time fanger dette opp; uten et bakplan blir den utdaterte renderen sittende til neste manuelle purge.

#Kompatibilitet med Astro og Next.js

Ifølge stack-vurderinger Q3 2026 leverer både Astro 5+ og Next.js 15 offisielle Cloudflare-adaptere. Astros adapter kompilerer statiske + SSR-ruter til Workers; Next.js-adapteren gjør det samme med App Router. Begge produserer en deploy-artefakt som kjører på Cloudflare Pages med Workers under panseret.

Valget mellom dem er dekket i beslutningsmatrisen Next.js vs Astro. For en innholdstung WooCommerce-butikk er Astro vanligvis det riktige standardvalget fordi static-first-modellen kartlegges rent på katalogen. For en mer applikasjonstung løsning (konto, dashboard, kompleks personalisering) har Next.js’ server components-modell den ergonomiske fordelen.

Uansett er WordPress-origin uendret. Workers + WordPress er et arkitekturmønster, ikke et rammeverksvalg.

#Slik ser byråoppdraget ut

En Workers + WordPress-migrering i WPPolands headless WordPress-tjeneste går gjennom fire faser.

Fase én, revisjon. Kartlegging av WordPress-installasjonen (plugins, egenskrevet kode, REST-API-flate, antall admin-brukere), måling av baseline-TTFB og TTI, identifisering av alt som er avhengig av PHP-rendering ved forespørselstidspunkt (temafunksjoner, page builders, server-side personalisering).

Fase to, REST- og webhook-stillas. Legge til eller herde WordPress REST-endepunktene fronten trenger. Sette opp webhook-utløsere for publisering, slug-endring og (for handel) lagerendring. Verifisere webhook-leveranseveien på et staging-domene.

Fase tre, frontend-bygg og overgang. Bygge Astro- eller Next.js-fronten, deploye til Cloudflare Pages, kjøre side om side med den gamle fronten i et målevindu, så bytte over via DNS eller Cloudflare-proxy. Sitemap- og kanonisk URL-håndtering i tråd med vår SEO-mønstersjekkliste er ikke til forhandling.

Fase fire, observability og tuning. Edge-logger (Cloudflare Logpush), origin-logger (WordPress-serveren) og syntetiske tester. Justering av cache-TTL-er og tag-invalideringsmønstre basert på den faktiske trafikkprofilen.

Vi lover ikke konkrete tall på forhånd fordi TTFB og TTI avhenger av plugin-lasten på WordPress-origin, frontend-rammeverket og brukerens nettverk. Vi publiserer protokoller og kjører målingen: se vårt benchmark-stillas for metodikken vi holder oss til.

#Hvor dette hører hjemme

Denne pilarartikkelen forankres i klyngen headless WordPress-tjeneste. For rammeverksvalg, se beslutningsmatrisen Next.js vs Astro. For renderingsvalg per rute, se ISR vs SSR-beslutningen. For SEO-migreringsrisiko, se headless WordPress SEO-mønstersjekklisten. For kostperspektiv, se økonomien i headless WordPress 2026.