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 reproducerbare. 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.
Managed vs sky vs edge
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 å patch 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-lag 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.
PHP-workers og samtidig last
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.
Eksempel fra drift: 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.
Objektcache: Redis, Memcached og hva som faktisk hjelper
Objektcache lagrer resultatene av wp_cache_* og persistente objekter mellom forespørsler. Uten persistent backend (filbasert i /tmp) starter hver PHP-prosess kald. 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.
WooCommerce og grensene for 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
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.
Datalagring, GDPR og norsk/EU-kontekst
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?
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.
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:
- Git som sannhetskilde for custom code (tema, mu-plugins, infrastructure-as-code).
- Bygg og test i CI: PHPStan/Psalm der det finnes, PHPUnit for egne plugins, lint for tema.
- Deploy til staging med samme PHP-versjon og extensions som produksjon.
- Smoke-tester: forsiden, en produktside, add-to-cart, innlogging.
- Produksjon med atomisk release (ny release-katalog + symlink) eller container-image med healthcheck.
- 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 arkitektur 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.
Ytelse: mål før du bytter plattform
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. En global markedsføringsside kan ha lav TTFB på cache-hit og fortsatt treg checkout. Optimaliser laget som faktisk er flaskehalsen.
Vanlige feil vi ser i revisjoner
- 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».
Når WPPoland hjelper
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 wppoland.com.
Oppsummering
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 reproducerbare.
Velg arkitektur etter målt last og compliance, deretter juster cache og workers. Det er mer holdbart enn å jakte på den nyeste hosting-etiketten.
