WordPress hosting, sky vs edge vs tradisjonell

I 2026 er WordPress-hosting et arkitekturvalg, ikke bare et abonnement. Du velger hvor PHP kjører, hvor MySQL ligger, hva som caches på kanten, og hvilke underleverandører som behandler personopplysninger for norske og europeiske brukere.

Denne guiden sammenligner managed hosting, skybasert IaaS/PaaS og edge-lag. Den går deretter gjennom PHP-workers, objektcache, WooCommerce-grenser på edge, datalagring under GDPR/personvernregelverk i NO/EU, og hvordan CI/CD holder miljøene reproduserbare. Målet er et beslutningsgrunnlag du kan ta med til driftsteamet, ikke en leverandørliste.

Lenker til WordPress-hastighetsoptimalisering og praktisk serveradministrasjon i WordPress hosting handbook er nyttige når du går fra valg til måling.

#Hva skiller managed, sky og edge for WordPress

De tre modellene løser ulike problemer. Bland dem feil, og du betaler for kompleksitet uten å få lavere TTFB der det teller.

#Managed WordPress-hosting

Managed-plattformer eier stacken: PHP-FPM, Nginx eller LiteSpeed, MySQL, daglige sikkerhetskopier, staging og ofte WP-CLI. Du slipper å patche OS, men du arver deres grenser for samtidige workers, cron-intervaller og hvilke objektcacher som støttes.

Typisk passform: markedsføringssider, blogg, mindre WooCommerce-butikker med forutsigbar trafikk, og team uten dedikert DevOps. Svakhet: når checkout eller admin treffer worker-taket, er eneste knapp «oppgrader plan» eller «flytt ut».

#Skybasert hosting (IaaS og PaaS)

På AWS, Google Cloud, Azure eller europeiske alternativer bygger du selv (eller via Terraform) VM-er, managed database, lastbalanser og nettverk. Kubernetes er vanlig for store flåter, men en godt satt Autoscale-gruppe med PHP-FPM og Redis er nok for mange norske nettbutikker.

Fordel: du styrer CPU-burst, database-IOPS og region. Ulempe: patching, sertifikater, loggaggregasjon og failover er ditt ansvar. Sky uten runbooks er bare dyrere nedetid.

#Edge-hosting med CDN og Workers

Edge her betyr CDN, HTML/edge-cache og compute nær brukeren (for eksempel Cloudflare Workers). Edge er sjelden «WordPress uten opprinnelse». Det er et lag foran opprinnelsen: cache hit for anonyme sider, bot-filtrering, bildeomskriving, A/B uten å treffe PHP.

For cache-miss, innloggede brukere og POST til checkout går trafikken fortsatt til opprinnelsen. Planlegg for det, ellers blir edge en illusjon av hastighet.

#Hvilke PHP- og databaseversjoner WordPress anbefaler

Før du sammenligner leverandører, sjekk at de oppfyller minstekravene. WordPress.org anbefaler i sin kravside PHP 8.3 eller nyere, MySQL 8.0 eller nyere eller MariaDB 10.11 eller nyere, og HTTPS-støtte. Det er anbefalinger for vertskapet, ikke en garanti for at alle utvidelser du bruker støtter samme versjon.

I praksis betyr det tre spørsmål til en ny leverandør: hvilken PHP-versjon kjører produksjon i dag, hvor raskt kommer neste versjon, og kan du velge versjon per miljø slik at staging kan testes på den nye før produksjon flyttes. En managed-plan som låser deg på en eldre PHP-gren, gir deg et oppgraderingsprosjekt på leverandørens tidsplan i stedet for din egen.

#Hvor mange PHP-workers trenger WordPress

En PHP-worker er én prosess (eller tråd i noen stacks) som kjører én forespørsel om gangen. Antall workers ganger gjennomsnittlig behandlingstid setter taket for forespørsler per sekund før køen vokser og TTFB stiger.

Regneeksempel: en butikk med 20 workers og 400 ms gjennomsnittlig PHP-tid håndterer grovt 50 forespørsler/s før kø. Hvis hvert produktside-treff uten page cache bruker 800 ms fordi plugins treffer eksterne API-er, halveres kapasiteten. Løsningen er sjelden «flere plugins», oftere færre synkroniserte kall, bedre page cache og flere workers bare der det er målt behov.

Praktiske tiltak:

• Mål queue-tid for PHP-FPM (slowlog, APM) før du dobler workers.
• Skill admin/cron fra frontend med egne pools der plattformen tillater det.
• Unngå at wp-cron kjører på hver frontend-forespørsel; bruk systemcron.
• Hold sessions og midlertidige filer ute av treg lokal disk når flere noder deler last.

WordPress.orgs serverdokumentasjon understreker at hosting er mer enn «PHP + MySQL»: filrettigheter, HTTPS, og hvordan prosesser isoleres påvirker både sikkerhet og stabilitet.

#Hvordan stille inn pm.max_children i PHP-FPM

På egen server eller sky er workers en innstilling du eier. PHP-manualen for FPM beskriver tre moduser for pm: static gir et fast antall barneprosesser, dynamic justerer antallet mellom pm.start_servers, pm.min_spare_servers og pm.max_spare_servers, og ondemand starter prosesser først når forespørsler kommer. Felles for alle er pm.max_children, som ifølge manualen «setter grensen for hvor mange samtidige forespørsler som blir betjent» (egen oversettelse).

Taket bestemmes i praksis av minne: hver PHP-prosess bruker RAM, og hvis pm.max_children ganger typisk prosesstørrelse er større enn det serveren har ledig, bytter du kø mot swapping. For å se hvor tiden går, sett request_slowlog_timeout til for eksempel noen sekunder. Da skriver FPM en PHP-backtrace til slowlog-filen for hver forespørsel som bruker lengre tid, og du ser hvilken plugin eller hvilket eksternt kall som holder workeren.

#Når bør du bruke Redis eller Memcached på WordPress

Objektcache lagrer resultatene av wp_cache_* og persistente objekter mellom forespørsler. Uten persistent backend lever cachen bare i minnet under én forespørsel. Dokumentasjonen for WP_Object_Cache sier det rett ut: «Som standard er objektcachen ikke persistent» (egen oversettelse), og data lagres ikke på tvers av sidevisninger før du installerer en persistent backend som drop-in i wp-content. Med Redis eller Memcached gjenbrukes options, postmeta-hotspots og transients på tvers av workers.

Når objektcache hjelper mest:

• WooCommerce med mange produkter og varianter
• Sider med tunge WP_Query-er som ikke page-caches
• Multisite eller mange aktive plugins som leser options gjentatte ganger

Når den hjelper lite:

• Rent statiske landingssider som allerede er full-page-cached på CDN
• Feilkonfigurerte plugins som bypasser objektcachen eller skriver enorme objekter
• Database som allerede er flaskehalsen på skriveintensive checkout-flows

Sett TTL bevisst. Evict aggressive nøkler ved deploy. Overvåk hit-rate: en «Redis er på» uten treffprosent er teater. Hold Redis i samme region som PHP for å unngå ekstra latens; et objektcache-hopp til et annet kontinent koster mer enn det sparer.

#Hva Cloudflare cacher som standard foran WordPress

Mange tror at et CDN foran WordPress automatisk cacher hele siden. Cloudflares egen dokumentasjon om standard cacheoppførsel sier noe annet: «Cloudflare-CDN-et cacher ikke HTML eller JSON som standard» (egen oversettelse). Uten egne regler caches filer etter filendelse, som bilder, CSS, JS, fonter og PDF, mens HTML-en fra PHP går til opprinnelsen hver gang.

Dokumentasjonen lister også hva som stopper caching selv når du har slått det på: et Set-Cookie-svar fra opprinnelsen, Cache-Control: private, no-store, no-cache eller max-age=0, og alle forespørsler som ikke er GET. For å cache HTML anbefaler Cloudflare en Cache Rule som cacher alt, eller Workers for egendefinert logikk.

Konsekvensen for WordPress er at en plugin som setter cookie på hver side, stille gjør edge-cachen verdiløs. Sjekk svarhodene på en anonym produktside før du konkluderer med at «CDN-et ikke hjelper».

#Hvilke WooCommerce-sider kan caches på edge

WooCommerce blander cachebare katalogsider med svært dynamiske stier: handlekurv, checkout, Min konto, REST for betalingsgatewayer, webhooks fra Vipps/Klarna/Stripe. Edge-cache som serverer anonym HTML for /produkt/ er bra. Edge-cache som serverer samme HTML for en bruker med varer i kurven ødelegger konvertering.

Typiske edge-regler som fungerer i praksis:

• Cache GET for katalog, innlegg og cachebare landinger
• Bypass for cookies som woocommerce_items_in_cart, wp_woocommerce_session_*, innloggingscookies
• Aldri cache POST, admin-ajax for handlevogn, eller betalingscallbacks
• Hold opprinnelsen nær betalings- og ERP-integrasjoner; edge kan ikke «flytte» PCI- eller sesjonslogikk magisk

WooCommerce sin egen veiledning for cache-plugins bekrefter grensen: handlekurv, Min konto og checkout skal holdes utenfor cache fordi de viser informasjon som gjelder den enkelte kunden. Cookie-listen der er woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed og store_notice[notice id]. Tilbyr cachelaget databasecache, foreslår veiledningen også å unnta _wc_session_. Bruk listen som utgangspunkt for bypass-regelen på edge, ikke en egen gjetning.

Et norsk scenario: kampanje på Black Week med tung katalogtrafikk fra hele Norden. CDN og edge-cache tar landings- og produktsider. Checkout forblir på opprinnelsen i en EU-region med nok PHP-workers og Redis. Hvis du prøver «hele butikken på Workers», mangler du fortsatt en autoritativ database for lager, ordrer og moms.

Mål TTFB for både cache-hit og cache-miss. web.dev sin TTFB-veiledning skiller serverrespons fra nettverksforsinkelse; edge forbedrer ofte det siste for statisk innhold, mens PHP- og databasespor fortsatt dominerer uncached checkout.

#GDPR og datalagring ved valg av WordPress-hosting

For virksomheter i Norge gjelder personvernregelverket i praktisk samspill med GDPR via EØS. Hostingvalg er også leverandørvalg: hvor ligger MySQL-snapshots, logger, sikkerhetskopier, support-tilgang og underleverandører?

Sjekkliste før du signerer:

• Primær region for database og filer (for eksempel EU/EØS). «Global anycast» for CDN er ikke det samme som datalagring for personopplysninger.
• Databehandleravtale (DPA) med tydelige underleverandører.
• Overføringsgrunnlag hvis data går utenfor EØS (standardkontraktsklausuler, tilleggstiltak). «Vi bruker US CDN» uten dokumentasjon er en risiko, ikke en funksjon.
• Logger og APM: inneholder de e-post, IP, ordre-ID? Hvor lenge lagres de?
• Tilgang for support: hvem kan SSH/SFTP, og logges det?

For amerikanske leverandører finnes ett overføringsgrunnlag til: EU-kommisjonen vedtok 10. juli 2023 en tilstrekkelighetsbeslutning for EU-US Data Privacy Framework. Ifølge kommisjonens side om dataoverføringer til USA gjelder den bare selskaper som deltar i rammeverket. Sjekk derfor om akkurat din hosting- eller CDN-leverandør står på deltakerlisten, i stedet for å anta at «USA er dekket».

Norske offentlige og semioffentlige aktører følger ofte Digdirs føringer for sky og informasjonssikkerhet. Selv private butikker tjener på samme disiplin: klassifiser data, skill miljøer, og ikke bland produksjonsdatabaser inn i «globalt edge replicate alt»-eksperimenter.

Edge-compute som kjører på persondata (A/B, personalisering) må vurderes som behandling. Cache-nøkler som inkluderer bruker-ID på hundrevis av PoP-er øker angrepsflaten. Hold personlig innhold på opprinnelsen eller i kortlivede, godt nøkkelstyrte lag.

#Hvordan erstatte wp-cron med systemcron

WP-Cron kjører ikke på klokka. Det sjekkes når noen laster en side, så planlagte oppgaver forsinkes på stille nettsteder og konkurrerer med besøkende på travle. WordPress sin utviklerdokumentasjon viser løsningen i to trinn. Først slås den trafikkstyrte utløsningen av i wp-config.php:

define( 'DISABLE_WP_CRON', true );

Deretter kaller systemets planlegger wp-cron.php med en webforespørsel. Dokumentasjonen bruker */15 * * * * som eksempel på hvert 15. minutt og viser et wget-kall mot wp-cron.php. Velg intervallet etter de faktiske jobbene: en nettbutikk med abonnementsfornyelser trenger kortere intervall enn en blogg med planlagte innlegg. På managed hosting, spør hvordan leverandøren kjører cron før du endrer noe, siden noen allerede gjør dette for deg.

#Hvordan sette opp CI/CD for WordPress-hosting

Uten CI/CD blir staging «manuell FTP natt til fredag». I 2026 bør kode, tema, plugins du eier, og infrastrukturdefinisjoner gå gjennom pipeline.

Minimum som fungerer:

1. Git som sannhetskilde for custom code (tema, mu-plugins, infrastructure-as-code).
2. Bygg og test i CI: PHPStan/Psalm der det finnes, PHPUnit for egne plugins, lint for tema.
3. Deploy til staging med samme PHP-versjon og extensions som produksjon.
4. Smoke-tester: forsiden, en produktside, add-to-cart, innlogging.
5. Produksjon med atomisk release (ny release-katalog + symlink) eller container-image med healthcheck.
6. Database-migrasjoner via WP-CLI eller kontrollerte migrasjonsskript, aldri «rediger i produksjon».

Hemmeligheter (API-nøkler, DB-passord) hører hjemme i vault eller plattformens secret store, ikke i Git. Objektcache og CDN-purge bør trigges etter deploy, ikke «husker vi å tømme Redis».

For managed-hosting: bruk deres Git-deploy eller rsync-hooks, men behold samme testgate. For sky: Terraform/Ansible + image-bake reduserer snøfnugg-servere. For edge: deploy Workers/CDN-config fra samme repo som WordPress-koden, med review på cache-regler som kan ødelegge checkout.

#Hvordan velge WordPress-hostingarkitektur i praksis

Start med arbeidsbelastning, ikke med markedsord.

• Innholdstung, geografisk spredt lesetrafikk: managed eller sky-opprinnelse pluss aggressiv edge-cache.
• WooCommerce med norske betalinger og ERP: EU-regionert opprinnelse, Redis, nok PHP-workers, edge kun for katalog.
• Sterke compliance-krav: sky eller managed med dokumentert EU/EØS-lagring og kort underleverandørliste.
• Lite team, forutsigbar trafikk: managed først; flytt til sky når worker-tak og database-I/O blir målt begrensning.

Hybrid er normalt: managed eller sky for WordPress, Redis i samme region, CDN/Workers foran. Ren «serverless WordPress overalt» er fortsatt et spesialtilfelle, ikke standarden for autentiske butikker.

#Hvilke ytelsesmål ta før du bytter WordPress-hosting

Bytte hosting uten baseline er gjetting. Logg i minst én uke:

• TTFB og LCP på nøkkelmaler (forside, kategori, produkt, checkout-steg)
• PHP-FPM queue og slow requests
• MySQL slow query-log
• Cache hit-rate (page + object)
• Feilrater på betalingswebhooks

web.dev anbefaler å forstå hva TTFB faktisk måler før du jager et magisk tall. TTFB der er summen av omdirigeringer, DNS-oppslag, tilkobling og TLS, og ventetiden til første byte kommer. Som grov rettesnor kaller web.dev 0,8 sekunder eller mindre godt og over 1,8 sekunder dårlig. En global markedsføringsside kan ha lav TTFB på cache-hit og fortsatt treg checkout. Optimaliser laget som faktisk er flaskehalsen.

#Vanlige hostingfeil på WordPress-sider

• Edge-cache uten cookie-bypass for WooCommerce-sesjoner
• For få PHP-workers, kompensert med flere cache-plugins som kjemper om samme HTML
• Redis i annen region enn PHP
• Sikkerhetskopier bare på samme disk som produksjon
• Ingen staging som speiler PHP-versjon og extensions
• Personopplysninger i CDN-logger uten retention-policy
• Deploy uten purge av page cache, så gamle HTML-fragmenter lever i timer

Hver av disse er billigere å fikse med måling og konfigurasjon enn med «vi bytter leverandør igjen».

#Hjelp med valg av WordPress-hosting

Vi kartlegger eksisterende stack, måler workers og cache, og foreslår managed, sky eller hybrid uten å overselge edge der checkout må være konsistent. Arbeidet dekker typisk arkitekturvalg, Redis/page-cache-tuning, CDN-regler for WooCommerce, og CI/CD til staging/produksjon.

Trenger du en konkret gjennomgang av infrastrukturen, ta kontakt via kontaktsiden.

#Hvordan velge mellom managed, sky og edge i 2026

Managed gir driftshjelp og tak. Sky gir kontroll og ansvar. Edge gir lav latens for cachebart innhold, ikke en erstatning for PHP og MySQL på dynamiske WooCommerce-stier. PHP-workers og objektcache bestemmer kapasitet på opprinnelsen. GDPR og datalagring i NO/EU styrer region og underleverandører. CI/CD holder endringer reproduserbare.

Velg arkitektur etter målt last og compliance, deretter juster cache og workers. Det er mer holdbart enn å jakte på den nyeste hosting-etiketten.