Cloudflare Workers Edge i Oslo

#Når delt hosting møter Black Week

Mange norske nettbutikker lever fortsatt på oppsettet de startet med: WooCommerce på et delt webhotell, Vipps i kassen, Bring-integrasjon for frakt og et tema som har vokst med årene. Det fungerer helt til det ikke gjør det. Black Week og julehandelen presser trafikken opp mot mange ganger normalen, og et delt webhotell deler nettopp det som er knapt: regnekraften. Når fraktkalkulatoren mot Bring bruker to sekunder på å svare og hver eneste produktside rendres på nytt for hver besøkende, merkes taket lenge før serveren faktisk gir opp. Kundene merker det først, i form av en kasse som somler akkurat i det øyeblikket kjøpsviljen er størst.

Cloudflare Workers er en måte å flytte deler av jobben ut av webhotellet på, uten å bytte plattform. En Worker er kode som kjører i Cloudflares datasentre, blant dem ett i Oslo, noen få millisekunder unna brukeren. Koden starter i V8-isolater på under fem millisekunder, uten kaldstart og uten servere som må dimensjoneres på forhånd. WordPress og WooCommerce blir stående som kildesystem med redaksjon, utvidelser og betalingsflyt intakt, mens edge-laget foran tar seg av det en PHP-server er dårlig egnet til.

Rådene i denne teksten er hentet fra egen drift: wppoland.com serveres fra Cloudflare-nettverket med Workers-mellomvare foran mer enn 7000 statiske sider, og oppsettet vi beskriver på tjenestesiden for Cloudflare edge-utvikling er det samme vi selv står opp med hver dag.

#Hva en Worker gjør foran WooCommerce-kassen

En Worker og en PHP-server er gode på forskjellige ting. PHP-serveren kjenner produktene, kundene og ordrelogikken; nettverkskanten kjenner brukerens posisjon og svarer på millisekunder, men vet ingenting om lagerstatus. En fornuftig arkitektur lar hver av dem gjøre sitt, og konklusjonen følger av seg selv: WordPress og WooCommerce blir stående som kildesystem, mens Worker-laget foran fungerer som filter og hurtigbuffer.

Edge-caching er kjernen. En WooCommerce-butikk rendrer hver side dynamisk, også når innholdet ikke har endret seg på dagevis. En Worker kan mellomlagre komplette HTML-svar i nettverkskanten og samtidig skille presist: anonyme besøkende får den mellomlagrede versjonen på noen titalls millisekunder, mens innloggede kunder, fylte handlekurver og alt som hører til kassen går urørt videre til kildeserveren. For en norsk butikk betyr presisjonen noe helt konkret: callback-adressene fra Vipps skal aldri caches, sesjonskapsler skal respekteres, og fraktprisene fra Bring kan mellomlagres med kort levetid slik at kalkulatoren slutter å hamre på et eksternt API for hver sidevisning. Den typen regelverk er vanskelig å uttrykke i et generelt cache-programtillegg, men er noen titalls linjer kode i en Worker.

Rundt kjernen kommer de udramatiske, men virksomme oppgavene: omdirigeringshåndtering med tusenvis av regler uten .htaccess-kaos, bildeoptimalisering og formatvalg i kanten, geo-ruting for butikker som selger til Sverige og Danmark i tillegg til Norge, og sikkerhetshoder som vedlikeholdes ett sted i stedet for i hvert enkelt tema. Har butikken i tillegg et team som jobber med selve butikkfunksjonaliteten, samarbeider edge-arbeidet tett med WooCommerce-utvikling for Oslo-markedet, slik at cache-regler og kassefunksjonalitet ikke utvikles i hver sin silo.

#Latens fra Oslo til Tromsø og videre ut i verden

Norge er et av Europas mest langstrakte land, og fysikk lar seg ikke forhandle bort: hver kilometer fiber koster tid. En kunde i Tromsø som handler i en nettbutikk driftet fra Oslo, eller enda vanligere fra et datasenter i Danmark eller Tyskland, betaler rundturstid for hver eneste forespørsel som ikke er mellomlagret. En typisk butikkside utløser titalls forespørsler, og alt som ikke er mellomlagret, reiser hele veien hver gang. På mobilnett i distriktene, der mange nordmenn faktisk handler, forsterkes hvert tapte millisekund av variabel dekning.

Cloudflare har eget datasenterpunkt i Oslo og over 300 lokasjoner globalt. En Worker svarer fra punktet nærmest brukeren: kunden i Tromsø får siden fra nærmeste nordiske lokasjon i stedet for fra et kontinentalt datasenter, og kunden i Berlin får den fra Berlin. For norske virksomheter med eksportkunder er det siste poenget ofte det viktigste. En B2B-leverandør med forhandlere i Norden og EU trenger ikke flytte hostingen ut av Norge for å gi utenlandske kunder rask svartid, edge-laget gjør jobben der kunden er.

For Core Web Vitals er effekten direkte målbar. Time to First Byte er grunnmuren som Largest Contentful Paint bygger på, og det er nøyaktig der edge-caching setter inn. I prosjektene våre faller TTFB for mellomlagrede sider jevnlig fra flere hundre millisekunder til under femti, målt på reelle brukerdata og ikke i laboratorietester.

#Bot-trafikk og skraping av priser i NOK

Den enkleste testen kan enhver butikk gjøre selv: sammenlign sidevisningene i analyseverktøyet med forespørslene i serverloggen. Gapet mellom de to tallene er trafikk uten mennesker bak, og i kartleggingene våre er det gapet sjelden lite. Det koster tre steder samtidig: kildeserveren bruker regnekraft på besøk som aldri kan konvertere, analysetallene mister presisjon som beslutningsgrunnlag, og i verste fall leses hele prislisten i NOK, lagerstatus inkludert, av aktører som justerer sine egne priser mot dine.

Skrapere ser dessuten sjelden ut som angrep. De opptrer som jevn, høflig trafikk fordelt utover døgnet, gjerne bak roterende forbruker-IP-er, og avslører seg først i mønsteret: hver produktside besøkt nøyaktig en gang, aldri en handlekurv. Et delt webhotell har ingen forsvarslinje mot dette, for filtreringen må skje før forespørselen når PHP.

En Worker filtrerer automatisert trafikk i nettverkskanten. Legitime crawlere som Google og prissammenligningstjenester butikken selv ønsker å være synlig i, beholder tilgang. Uønsket skraping møter klassifisering og rate-begrensning per nettverkssegment, og AI-crawlere kan gis egne regler: slipp inn de som siterer med kildehenvisning, brems de som bare høster. Kildeserveren ser bare trafikken som er verdt å bruke regnekraft på.

#Personvern: GDPR og Datatilsynets blikk

Ingen seriøs samtale med en norsk virksomhet kommer utenom personvernet, og terskelen er høyere her enn mange andre steder. Datatilsynet har markert seg som et av Europas mer prinsipielle tilsyn, og etterdønningene etter Schrems II har lært norske virksomheter å stille spørsmålet tidlig: hvor behandles dataene, og av hvem?

Vår vurdering begynner derfor ikke med hva Cloudflare lover, men med hva edge-laget faktisk kommer til å se. En Worker som mellomlagrer statiske sider og filtrerer bots, behandler i praksis nesten ingen personopplysninger; en Worker som tar imot skjemadata, behandler mer, og den forskjellen er en designbeslutning vi tar sammen med deg. Først når det bildet er tegnet, henter vi inn avtaleverket: Cloudflare inngår databehandleravtale etter artikkel 28 og fører en offentlig liste over underdatabehandlerne sine, og med Data Localization Suite kan behandlingen av forespørselsinnhold avgrenses til EU-lokasjoner med europeisk nøkkelhåndtering. Dokumentasjonen vi leverer er skrevet for å legges rett inn i behandlingsprotokollen, ikke for å ligge i en skuff.

Unntaket finnes, og det er verdt å kjenne før prosjektet starter: enkelte kontrakter, særlig i offentlig sektor, krever at all behandling skjer på navngitte servere i Norge, og et globalt distribuert nettverk kan per definisjon ikke love det.

#Tre mønstre fra norske prosjekter

Detaljene under er endret av hensyn til kundene, men hvert av de tre forløpene har gjentatt seg i norske prosjekter mer enn en gang.

Nettbutikken foran Black Week: en WooCommerce-butikk med Vipps i kassen og Bring-frakt hadde to år på rad opplevd at nyhetsbrevutsendelser i november la kassen nede i minuttene etterpå, akkurat når klikkene strømmet inn. Edge-cache-laget ble derfor skrevet rundt kampanjerytmen: kampanjesidene varmes opp i hurtigbufferen før hver utsendelse, en utgått sideversjon serveres mens en fersk hentes i bakgrunnen, og kildeserveren ser i praksis bare handlekurver og betalinger. Neste Black Week gikk utsendelsene ut uten at noen først måtte varsle driftsleverandøren.

B2B-grossisten med prislekkasje: en grossist med flere tusen varelinjer i NOK fant lekkasjen et annet sted enn ventet, i produktfeeden som var satt opp for en prissammenligningstjeneste flere år tilbake og aldri stengt. Adressen ble hentet hvert kvarter av systemer ingen lenger kjente. En Worker la tilgangsstyring og rate-begrensning på feed-endepunktene og bot-klassifisering foran resten av katalogen, uten å berøre verken Google eller kundenes egne innkjøpssystemer. Feeden finnes fortsatt, men bare for dem den ble laget for.

Redesignet med tjue år gamle adresser: en virksomhet som konsoliderte flere nettsteder etter en overgang til ny frontend, satt igjen med tusenvis av gamle adresser som fortsatt hadde både lenker og rangeringer. En edge-funksjon med versjonert omdirigeringstabell løste det på en vedlikeholdbar måte: reglene ligger i en datastruktur, endringer går gjennom kodegjennomgang, og hver omdirigering besvares i nettverkskanten før noen server involveres. En slik omdirigeringstabell er dessuten ofte første steg i en migrering til Next.js eller Astro der WordPress beholdes som redaksjonssystem.

#Grønn profil: mindre servertid er også bærekraft

I norske anbud og leverandørvurderinger veier klima og miljø stadig tyngre, og i offentlige anskaffelser skal miljøhensyn som hovedregel vektes med minst tretti prosent. Edge-arkitektur er ingen klimaløsning i seg selv, men den har en dokumenterbar effekt som hører hjemme i slike vurderinger: hver forespørsel som besvares fra hurtigbufferen i nettverkskanten, er en forespørsel kildeserveren aldri bruker CPU-sykluser på. En butikk som lar edge-laget bære kampanjetoppene, kan dimensjonere serverne etter grunnlasten i stedet for etter Black Week, og det er en reell reduksjon i løpende ressursbruk, ikke et regnestykke på papir.

Vi hjelper gjerne med å tallfeste dette for leverandørskjemaer og miljørapportering: treffrate i cache, redusert opprinnelsestrafikk og dimensjonering før og etter. Tall er uansett ryggraden i hele arbeidsmåten vår, så dokumentasjonen finnes allerede.

#Når edge ikke lønner seg

Tenk på en liten norsk nettbutikk med noen hundre ordrer i året, et rimelig norsk webhotell og kunder som stort sett bor i samme fylke. Den butikken har sjelden et problem en Worker løser. Et velkonfigurert cache-programtillegg, komprimerte bilder og et ryddig tema tar den minst like langt, for en brøkdel av innsatsen, og uten at det legges til enda et stykke programvare som noen må eie. Det siste punktet er undervurdert: en Worker ingen vedlikeholder, blir med tiden et større problem enn den trege siden den skulle fikse, og har ikke virksomheten kapasitet til å drifte kode, er det i seg selv et argument mot prosjektet.

Regnestykket snur i tre situasjoner som går igjen i norsk netthandel: når butikken har sesongtopper den ikke rår over, slik Black Week og julehandelen er, når en vesentlig del av kundene sitter i Sverige, Danmark eller lenger ute i EU, og når loggene viser at maskiner leser mer av katalogen enn mennesker gjør. Da bærer ett av problemene alene kostnaden ved et edge-lag, og kartleggingen tallfester hvilket.

#Samarbeidsmodell for norske B2B-kunder

Den største risikoen i et edge-prosjekt er ikke koden, men et omfang ingen har tegnet grensene for. Arbeidsmåten vår er derfor bygget for å holde hvert steg lite og etterprøvbart. Først en kartlegging med måletall: TTFB fra reelle brukerdata, cache-treffrater, bot-andel i trafikken og personvernkrav. Ut av den kommer en prioritert liste over edge-kandidater med forventet effekt. Den første produksjonssatte Workeren er bevisst liten, gjerne edge-caching for de ti viktigste landingssidene, og leverer før- og etter-tall i løpet av noen uker. Deretter rulles løsningen ut trinnvis, hver etappe med regresjonstester og en dokumentert vei tilbake. Til slutt følger dashbord, varsler og dokumentasjon som gjør teamet ditt selvhjulpent i stedet for avhengig av oss.

Praktisk fungerer samarbeidet slik norske B2B-kjøpere er vant til fra andre spesialiserte leverandører: skriftlig og etterprøvbart, med faste kontaktpunkter og uten binding til timeverk ingen kan kontrollere. Norge og Polen deler tidssone, så det finnes ingen forsinkelse i dialogen, og all kode leveres med dokumentasjon på engelsk som interne utviklere eller en fremtidig leverandør kan overta. Grunnen til at et WordPress-byrå tar denne typen oppdrag, er praktisk: feilene i et edge-prosjekt oppstår nesten alltid i møtet mellom lagene, en cache-regel som spiser en Vipps-callback, et sidebygger-tema som setter informasjonskapsler ingen visste om. Den som skriver Worker-koden, må derfor kjenne kildesystemet like godt som kanten. WordPress har vært håndverket vårt siden 2007, edge-laget drifter vi selv, og for alt som gjelder selve kildesystemet står WordPress-utvikling for Oslo-markedet klar under samme tak.

Prisingen er individuell og følger omfanget av edge-logikken. Første steg er uansett kartleggingen, og den har en innebygd grense vi holder oss til: viser tallene at et cache-programtillegg og et ryddigere tema løser problemet ditt, stopper prosjektet der, og du sitter igjen med måletallene og en prioritert liste du kan handle på med hvem som helst.

Sist oppdatert: 10. juli 2026