WordPress 7.0 vs Astro 7 på Cloudflare - hvem vinner i 2026?

For de fleste bedriftsnettsteder er Astro 7 på Cloudflare billigere, raskere og enklere å sikre enn WordPress 7.0. Men fortrinnet har en pris som forrige utgave av denne sammenligningen tiet om: rammeverket har sin egen utgivelsestakt, og noen betaler for den i utviklertid.

Første utgave av denne sammenligningen skrev jeg i april, mot Astro 6 og et WordPress 7.0 som fortsatt lå i release candidate. Begge har kommet siden, og vi har flyttet dette nettstedet fra Astro 6 til Astro 7. Dermed har jeg noe jeg ikke hadde da: en spesifisert regning for en stor rammeverksmigrering, kjørt på vårt eget korpus på godt over ti tusen sider.

Anbefalingen om plattform har ikke endret seg. Det som har endret seg, er hvor mye jeg vet om de skjulte kostnadene på Astro-siden.

#WordPress 7.0, tre måneder etter lansering

WordPress 7.0 kom 20. mai 2026. Det lønner seg å skille det som ble annonsert fra det som faktisk lå i pakken.

#AI Client og Abilities API

AI Client er infrastruktur, ikke en ferdig AI-skribent. WordPress 7.0 gir et enhetlig API for å snakke med modeller, men vil ha en ekstern nøkkel og konfigurasjon før noe skjer. Abilities API lar agenter oppdage og kalle WordPress-funksjonalitet programmatisk, noe som betyr mye for utvidelsesutviklere og er praktisk talt usynlig for en redaktør.

Det er et viktig fundament. Det er ikke en funksjon en kunde legger merke til i administrasjonen den første dagen.

#Real-time collaboration kom ikke

Samtidig redigering var det høyeste løftet knyttet til denne utgivelsen, og det ble trukket etter tekniske problemer. Tre måneder senere er det fortsatt borte fra 7.0-linjen. Den som solgte WordPress 7.0 til en kunde med løfte om flere redaktører i samme dokument, har en ubehagelig samtale foran seg.

#Arkitekturen under har ikke flyttet seg

Det oppfriskede administrasjonspanelet og de nye blokkene er et visuelt framskritt. Under ligger fortsatt PHP, MySQL og en tradisjonell server som må lappes, mellomlagres og overvåkes. Ingen av nyhetene i 7.0 endrer at hver utvidelse utvider angrepsflaten, eller at ytelse først kommer etter et lag med mellomlagring og CDN.

#WordPress 7.0, byttehandelen

Hva du får:

• Den beste innholdsredigereren for ikke-tekniske folk, uten reell konkurranse i den kategorien
• Et utvidelsesøkosystem som telles i titusener
• WooCommerce som en komplett handelsplattform
• Abilities API som grunnmur for agentintegrasjoner

Hva det koster:

• Kjernevekt og overhead du ikke kan slå av
• En angrepsflate som vokser med hver utvidelse
• Budsjett til drift, sikkerhetskopier, overvåking og sikkerhetsutvidelser
• Ytelse som først kommer etter mellomlagring og CDN
• Sikkerhetsutgivelser med få ukers mellomrom

#Astro 7 og hva som faktisk endret seg fra versjon 6

Astro 7.0.0 kom 22. juni 2026, 104 dager etter Astro 6.0.0. Tre endringer har konsekvenser du ikke ser i endringsloggen før du kjører ditt eget bygg.

#Rust-kompilatoren sluttet å være et eksperiment

I Astro 6 var Rust-kompilatoren et frivillig eksperiment. Astro 7 bytter avhengigheten @astrojs/compiler mot @astrojs/compiler-rs og gjør den til standard. Byggene blir raskere. Parseren blir samtidig strengere.

Hos oss knakk det på nøyaktig én linje. En HTML-kommentar skrevet inne i et JSX-uttrykk, omtrent {import.meta.env.DEV && ( <!-- ... --> )}, gikk gjennom den gamle kompilatoren og avvises av den nye. Rettelsen er en JavaScript-kommentar i stedet. Ett minutts arbeid, forutsatt at du vet hva du leter etter, for feilmeldingen peker på en posisjon i kompilert utdata og ikke i kilden din.

#Vite 8 under panseret

Astro 6 sto på Vite 7. Astro 7 går til Vite 8, den Rolldown-baserte linjen. For de fleste prosjekter er dette usynlig, men på store korpus er det verdt å følge med på minnebruken i bygget, fordi allokeringsprofilen er en annen enn før.

#CSP hasher inline-stiler, og det svir

Dette er endringen som kostet oss en hel dag.

Astro 7 regner ut hasher for <style>-blokker som ligger inne i siden, og legger dem i style-src-direktivet. Etter spesifikasjonen for Content Security Policy opphever enhver hash i et direktiv 'unsafe-inline'. Resultatet: alle dynamiske style=""-attributter slutter å virke. Hos oss forsvant Shiki-tokenfargene i kodeblokker, sammen med temavariabler, animasjonshastigheter og bakgrunnsbilder. Forsiden alene ga 26 CSP-brudd, og hver side med syntaksutheving var berørt.

Det finnes ingen bryter for å slå hashingen av. 'unsafe-hashes' alene løser det heller ikke, fordi den dekker style-attributter, men ikke innholdet i <style>-elementer.

Løsningen viste seg enklere enn den så ut, for mengden inline-stiler er endelig. På rundt 260 000 forekomster i hele korpuset fantes det 143 unike verdier. Samle dem inn én gang, skriv hashene inn i konfigurasjonen, legg til 'unsafe-hashes' for attributt-tilfellet, og bruddene faller til null på tvers av alle maltyper.

Det etterlater en løpende forpliktelse. Enhver ny komponent som innfører en ny inline-stilverdi, havner enten på listen eller blir stille blokkert i produksjon. Dette trenger en port i CI, ellers får du vite om det fra en brukerhenvendelse.

#En ny standard markdown-kjede

Astro 7 endrer hvordan markdown behandles som standard. Har du din egen remark- og rehype-kjede, må du hente inn @astrojs/markdown-remark eksplisitt for å beholde eksisterende oppførsel. Det er én linje i avhengighetene, men når den mangler, gir det en stille renderingsforskjell i stedet for en byggefeil, og derfor er den lett å sende ut ved et uhell.

#Hva migreringen fra Astro 6 til 7 faktisk kostet oss

Tall fra vår egen utrulling, ikke fra dokumentasjonen.

Tre av de fire store bruddendringene gjaldt ikke oss, og det er hele poenget. Vi har ingen Astro DB, ingen serveradapter å flytte og bygger statisk, så omorganiseringen av serverinngangen gikk oss forbi. Et prosjekt som kjører SSR med adapter og en Astro-database får en helt annen regning for den samme migreringen.

Den praktiske lærdommen: kostnaden ved en stor Astro-utgivelse skalerer ikke med størrelsen på nettstedet. Den skalerer med hvor mange berøringspunkter du har mot kjøretidsmiljøet. Våre over fjorten tusen sider kostet mindre enn én applikasjon med Astro DB og egen adapter ville gjort.

#Direkte sammenligning 2026

Resultat: Astro 7, WordPress 3, én uavgjort.

WordPress tok tilbake ett poeng i denne utgaven, og ikke gjennom en ny funksjon. Det tok det på utgivelsestakt. Et WordPress-nettsted fra tre år tilbake bygger fortsatt, fordi det ikke finnes noe bygg. Et Astro-nettsted fra tre år tilbake ligger to majors bak, og noen må dra det framover.

#Når du bør migrere i 2026, sjekklisten min med 8 punkter

Migrering lønner seg når minst fem av åtte stemmer:

1. Innholdsnettsted, blogg eller landingsside, altså nøyaktig det Astro ble bygget for
2. PageSpeed under 80 til tross for WordPress-optimalisering, altså et arkitekturproblem og ikke et konfigurasjonsproblem
3. Driftskostnader over rundt to hundre euro i måneden
4. Gjentakende sikkerhetshendelser, lapping av utvidelser, brute force-forsøk
5. Et utviklerteam som kan JavaScript og TypeScript, og som fortsatt er der når neste store oppgradering skal gjennomføres
6. Ikke behov for WooCommerce eller et tungt innlogget brukerområde
7. SEO er prioritert, og Core Web Vitals flytter posisjonene
8. Nettstedet betjener flere land og global TTFB betyr noe

Punkt fem er bevisst videre enn i april-utgaven av denne listen. Kravet er ikke å kunne JavaScript på lanseringsdagen. Kravet er å vite hvem som kjører npm update ni måneder senere.

Tre eller færre: bli på WordPress. Fire: vurder hybrid. Fem eller flere: migreringen lønner seg.

#Casestudie, før og etter

#Bedriftsnettsted, kunde i Warszawa

Før: WordPress med Elementor, PageSpeed i rødt på mobil, lastetid målt i sekunder, en løpende månedlig driftspost.

Etter: Astro på Cloudflare Pages, PageSpeed i grønt, lastetid godt under sekundet, statisk drift på gratisnivået.

Nettoeffekt: driftsposten forsvant, og Core Web Vitals gikk fra rødt til grønt på hovedmalene. Det samme nettstedet gikk senere gjennom migreringen fra Astro 6 til 7 under vårt vedlikehold, og kunden merket ingenting utover én utrulling.

#wppoland.com, dette nettstedet

Over fjorten tusen forhåndsrendrede sider på seks språk, hvorav omtrent tre tusen ligger i sitemap som innhold ment for indeksering. Resten er en by-ganger-tjeneste-utrulling med noindex. Drift på Cloudflares gratisnivå. Det samme nettstedet kjørte tidligere på WordPress med betalt månedlig drift.

Å migrere det korpuset fra 6 til 7 var fem filer og én arbeidsdag, nesten alt av det Content Security Policy.

#Integrasjonene som avgjør valget i Norge

Sammenligningen over handler om plattform. I norske prosjekter er det sjelden plattformen alene som avgjør, det er listen over systemer nettstedet faktisk skal snakke med. Den listen ser annerledes ut her enn i et engelsk eller tysk prosjekt, og den bestemmer mer enn PageSpeed gjør.

Kravene som går igjen hos norske kunder:

• innlogging for medlemmer, kunder eller ansatte mot en identitetsløsning organisasjonen allerede bruker, ofte ID-porten eller en intern løsning
• skjemaer som ikke skal ende i en innboks, men gå videre til fagsystemet eller CRM-et
• påmelding til kurs, arrangementer og medlemsaktiviteter, med deltakerlister noen skal kunne hente ut selv
• innhold som skal ut både på nettstedet og i nyhetsbrev, og som redaksjonen skriver én gang

For WordPress finnes det en ferdig utvidelse til nesten alt av dette. Haken er at de fleste utvidelsene er bygget for et internasjonalt marked. Den norske delen, altså koblingen mot den identitetsløsningen eller det fagsystemet kunden faktisk har, ender likevel som skreddersydd kode. Da betaler du både for plugin-vedlikeholdet og for integrasjonen.

Astro har ingen tilsvarende utvidelsesbutikk. Alt er et API-kall, enten ved bygg eller i en funksjon på kanten. Det høres ut som mer arbeid, og for et helt standard nettsted er det også det. Men i akkurat de tilfellene der WordPress-løsningen uansett ville blitt skreddersydd, taper du ingenting på å droppe plugin-laget. Det er verdt å gjøre den vurderingen integrasjon for integrasjon, ikke for nettstedet under ett.

Utgivelsestakten fra forrige avsnitt slår også inn her, og på en måte som er lett å overse i et anbud. En skreddersydd integrasjon mot ID-porten eller et fagsystem er kode noen må se på igjen ved neste store Astro-versjon. På WordPress ligger den samme integrasjonen i en utvidelse som i praksis kan stå urørt i årevis. Det er ikke et argument mot Astro, men det er en post som hører hjemme i driftsavtalen framfor i overraskelsene.

Et poeng til som hører hjemme i en norsk vurdering: WordPress og Astro er ikke de eneste to alternativene på bordet. I større norske organisasjoner konkurrerer valget like ofte mot Enonic eller Umbraco, som allerede står i leverandørlisten og har et redaksjonsmiljø rundt seg. Kommer du inn i den diskusjonen med Astro, må argumentet handle om redaksjonen og driften, ikke om byggetid.

#Hvordan en migrering fra WordPress til Astro ser ut i praksis

#Steg 1, revisjon av WordPress-nettstedet

Tell custom post types, list opp utvidelsene med hva hver av dem faktisk gjør, kartlegg malene. Dette avgjør kompleksiteten i alt som følger.

#Steg 2, eksporter innholdet

WP CLI eller REST-API-et for å hente innlegg, sider og medier til markdown eller JSON. Det meste av dette lar seg automatisere.

#Steg 3, bygg Astro-malene

Gjenoppbygg oppsett og komponenter i .astro-syntaks. Tailwind CSS oppfører seg identisk. De fleste WordPress-maler har direkte motstykker.

#Steg 4, Content Collections

Definer innholdstyper med Zod-validering. Motstykket til custom post types, bortsett fra at typingen fanger feilen i bygget i stedet for i produksjon.

#Steg 5, drift og DNS

Cloudflare Pages koblet til Git-repositoriet, domenet satt opp. Bygg utløses ved hver push.

#Steg 6, én-til-én-omdirigeringer

Kartlegg hver gammel URL til den nye stien. Dette er steget der rangeringer dør når det gjøres på slump.

#Steg 7, testing og innsending til GSC

Full gjennomgang, Lighthouse-kjøringer på hver maltype, ny sitemap i Google Search Console.

#Steg 8, tretti dagers overvåking

Følg posisjoner, indeksering og Core Web Vitals gjennom den første måneden.

I dag ville jeg lagt til et niende steg: skriv ned hvilken Astro-versjon du leverte og hva som må sjekkes ved neste store versjon. En runbook skrevet på migreringsdagen tar en time. Å rekonstruere den kunnskapen et halvt år senere tar en dag.

#Hybridløsning, WordPress pluss Astro

Du trenger ikke velge én av to. Hybriden ser slik ut:

• WordPress som headless CMS, redigeringsverktøyet for innhold
• Astro som frontend, som genererer statiske sider fra WordPress-data
• WPGraphQL eller REST-API-et som bro
• Cloudflare Pages som drift for frontenden

Redaksjonen beholder grensesnittet den kjenner, besøkende får en statisk side, utviklerne får en moderne stack. Hele kostnadsmodellen bak dette ligger i TCO-guiden headless mot monolitt.

#Den skjulte kostnaden jeg ikke skrev om i april

Astro 6.0.0 kom 10. mars 2026. Astro 7.0.0 kom 22. juni. Ved utgangen av august hadde 7.x-linjen nådd 7.2.8. Den takten har WordPress aldri hatt.

For oss er det håndterbart, fordi vi vedlikeholder vår egen stack og har porter i CI som fanger drift før den når produksjon. For en kunde som fikk et nettsted og så forsvant i to år, ser det annerledes ut. Nettstedet fortsetter å virke, for statisk HTML slutter ikke å virke. Men å legge til noe som helst etter to år betyr å hoppe over to majors samtidig, og det er atskillig tyngre enn to migreringer tatt etter hverandre.

Den ærlige versjonen av anbefalingen lyder derfor slik. Astro vinner på ytelse, infrastrukturkostnad og sikkerhet. WordPress vinner på å være trygt å la ligge lenger. Har vedlikeholdsbudsjettet ingen post for tekniske gjennomganger, er den andre egenskapen verdt mer enn tabellen antyder.

#Energifotavtrykk og CSRD-rapportering

Hos kunder som omfattes av bærekraftsrapportering har energifotavtrykket til nettstedet begynt å dukke opp i anbudsdokumenter. Det er verdt å skille med én gang mellom det som kan dokumenteres og det som bare ser bra ut i et tilbud.

Mekanismen er reell og lett å forklare for en revisor. Hvert dynamiske sidevisning i WordPress starter en PHP-FPM-prosess og et sett med MySQL-spørringer, så visningen bruker prosessorsykluser i et datasenter. En statisk side kommer ut av en mellomlagring på kanten av nettverket og bruker ingen applikasjonsprosess i det hele tatt ved et vanlig treff. Retningen på forskjellen er det ingen uenighet om.

Tallet er det uenighet om. Vi gir ikke kunder en prosentvis reduksjon i energibruk, fordi vi ikke har målt noen, og tallene som sirkulerer i leverandørmateriell har ingen publisert metode bak seg. Skal et konkret tall inn i en rapport, må det komme fra driftsleverandørens egne data for perioden, ikke fra en sammenligning av arkitekturer.

Praktisk råd: ta det leverandøren faktisk publiserer om infrastrukturen og energimiksen sin, og siter det som deres påstand, ikke som din egen måling. Å gå over til statisk arkitektur er et argument om ressursbruk, ikke et miljøsertifikat.

#Min spådom for 2026 og 2027

WordPress forblir dominerende for WooCommerce-butikker, nettsteder med ikke-teknisk redaksjon, prosjekter bygget på ferdige utvidelser og selskaper som må lansere raskt og billig.

Astro med Cloudflare tar innholdsnettsteder og ytelsesdrevne blogger, bedriftssider og landingssider, teknisk dokumentasjon og flerspråklige nettsteder med global rekkevidde.

April-anslaget mitt satte statiske rammeverk til 30 til 40 prosent av de innholdsdrevne nettstedene som i dag kjører på WordPress, innen utgangen av 2027. Det står jeg ved, med forbeholdet fra avsnittet over: den migreringen lønner seg bare der frontenden er budsjettert som programvare.

#Oppsummering

WordPress 7.0 er en solid utgivelse som ikke rører plattformens fundament. Astro 7 er mer opprydding under panseret enn nye funksjoner for brukeren: Rust-kompilator som standard, Vite 8 og strengere CSP.

Bygger du nettbutikk: WordPress. Bygger du bedriftsside, blogg eller landingsside der ytelse og SEO betyr noe: Astro 7 med Cloudflare. Bygger du begge deler: vurder hybriden.

Er du usikker, ta kontakt. Er Astro riktig valg for prosjektet ditt, finner du mer på siden Astro-utvikler.

Mariusz Szatkowski, WordPress- og Astro-utvikler. Arrangør av WordCamp Gdynia, bidragsyter til WordPress Core. Bygger på begge plattformer for kunder i Polen og Europa.