Kort fortalt
WordPress består Core Web Vitals på 49 % af sites (april 2026) og ligger dermed sidst i sammenligningen; Astro ligger på 67 %, Shopify på 79 %. En gennemsnitlig WooCommerce-butik kører 58 aktive plugins, og hver eneste sideindlæsning skal igennem dem alle, før serveren svarer. Vedligeholdelsen er den skjulte post: 11.334 nye sårbarheder i økosystemet i 2025, 91 % af dem i plugins, og mediantiden til første udnyttelse er fem timer. Et build koster 10.000-35.000 kr. hos en freelancer og 12.000-35.000 kr. for en webshop, men drift og vedligeholdelse lægger 200-3.000 kr./md. oveni resten af sitets levetid. Mål din p75 TTFB i felt-data først — ligger den over Googles grænse på 800 ms, er problemet stakken og ikke indholdet.
WordPress er ikke længere den hurtige vej til et hurtigt website: kun 49 % af WordPress-sites består Core Web Vitals, mod 67 % på Astro og 79 % på Shopify. Platformen er ikke i sig selv langsom. Det er de 58 plugins, en gennemsnitlig WooCommerce-butik kører, sidebyggeren og databasekaldet ved hver eneste sideindlæsning, der er det. Prisen på selve buildet er stadig lav — den flytter bare over i drift og vedligeholdelse.
49 % består testen. Det er sidstepladsen
HTTP Archives Core Web Vitals Technology Report måler ikke laboratorieforhold, men rigtige besøg fra rigtige browsere. I opgørelsen for april 2026 består 49 % af WordPress-sites Core Web Vitals. Det er den laveste andel blandt de platforme, der blev sammenlignet — Astro ligger på 67 %, Shopify på 79 %, Wix på 80 % og Duda på 85 % (tal gengivet af Search Engine Journal).
Det tal skal læses rigtigt. Det siger ikke, at WordPress-koden er langsom. Det siger, at et gennemsnitligt site bygget på WordPress i 2026 er langsommere end et gennemsnitligt site bygget på næsten hvad som helst andet. Når du hyrer nogen til at bygge på WordPress, køber du ikke platformen alene. Du køber den stak, folk typisk stabler ovenpå.
Problemet er ikke WordPress. Det er de 58 plugins ovenpå
Metorik opgjorde i marts 2026 plugin-forbruget på over 6.000 WooCommerce-butikker. Gennemsnittet er 58 aktive plugins. Det stiger med butikkens størrelse — 51 hos de mindste, 66 hos dem over en million i omsætning — og tallet har ligget stabilt siden 2023. Én butik i datasættet kørte 237 plugins på én gang (Metorik, 6.000+ butikker).
Hver af dem er kode, der skal indlæses, køres og vedligeholdes. Det er ikke en fejl i WordPress. Det er den måde, økosystemet er bygget til at blive brugt på — og det er derfor, gennemsnittet ser ud, som det gør.
Frontend er ikke engang det værste. TTFB — tiden fra klik til den første byte kommer retur — er det tal, der låser alt andet. En grænse på 800 ms nævnes ofte som tommelfingerregel for god TTFB (web.dev). HTTP Archive opgør i Web Almanac 2025, at 44 % af mobilbesøgene og 55 % af desktopbesøgene på tværs af nettet holder sig under den grænse. Din LCP skal samlet holdes under 2,5 sekunder. Bruger serveren et helt sekund, før den overhovedet svarer, er der ikke meget budget tilbage til billeder og skrifttyper. Ingen billedkomprimering redder den situation.
Årsagen er triviel. Hver eneste sideindlæsning på et almindeligt WordPress-site starter en PHP-proces, som slår op i en database, kører samtlige plugins' hooks igennem og først derefter sender HTML afsted. Det arbejde skal gøres om for hver besøgende. CoreWebVitals.io's feltmålinger sætter p75 TTFB på delt hosting til mellem 900 og 1.400 ms — og samme site flyttet til managed hosting til 120-250 ms (CoreWebVitals.io).
Vedligeholdelsesgælden, ingen sætter pris på i tilbuddet
Der blev fundet 11.334 nye sårbarheder i WordPress-økosystemet i 2025. Det er 42 % flere end året før. 91 % af dem sad i plugins, 9 % i temaer og seks stykker i selve WordPress-kernen. Antallet af højrisiko-sårbarheder steg 113 % — der kom flere af dem på ét år end i de to foregående år tilsammen (Patchstack, State of WordPress Security 2026).
To tal fra samme rapport gør det til en driftsopgave og ikke en engangsopgave: den vægtede mediantid fra offentliggørelse til første udnyttelse er fem timer, og 46 % af sårbarhederne havde ikke fået en rettelse fra udvikleren, da de blev offentliggjort. Din opdateringsknap er altså hverken hurtig nok eller fuldstændig.
Det er den regning, der ikke står i tilbuddet. Hver af de 58 plugins er en leverandør, du har outsourcet en del af dit site til — og hver af dem kan holde op med at blive vedligeholdt, uden at nogen fortæller dig det.
Hvad en WordPress-hjemmeside og en WordPress-webshop koster
Prisen på selve buildet er ikke problemet. Den er lav, og det er hele pointen med WordPress. Problemet er, at posten under stregen løber videre hver måned, så længe sitet lever.
| Løsning | Pris | Hvad der typisk er med |
|---|---|---|
| Hjemmeside, freelancer | 10.000-35.000 kr. | 5-10 sider, tilpasset tema, SEO-opsætning, kontaktformular |
| Hjemmeside, skræddersyet | 35.000-100.000 kr. | Eget design, sidebygger, integrationer, optimering |
| Webshop, lille | 12.000-20.000 kr. | Op til ca. 30 varer, betaling (MobilePay, Stripe, Klarna), mobil-first |
| Webshop, mellem | 20.000-35.000 kr. | Op til 200 varer med varianter, økonomiintegration (Dinero, e-conomic, Billy) |
| Webshop, stor | 35.000-150.000+ kr. | 500+ varer, filtre, B2B, flersprog, ERP-integration |
| Drift | 1.500-6.000 kr./år | Hosting 100-500 kr./md., domæne 80-150 kr./år, premium-licenser 500-3.000 kr./år |
| Vedligeholdelse | 200-3.000+ kr./md. | Opdateringer og backup i bunden; overvågning, performance og prioriteret support i toppen |
Intervallerne er gengivet fra danske leverandørers offentlige prissider — WP-Guide, Webza og Webworq. Tallene er deres, ikke mine, og de er vejledende. Webza regner det selv tre år frem: en WooCommerce-webshop med 25.000 kr. i opsætning og 6.000 kr. om året til hosting og vedligehold ender omkring 43.000 kr. Det er ikke dyrt. Det er bare ikke det tal, du fik oplyst.
Hvad en statisk stak leverer i stedet
En statisk stak bygger siderne én gang, ved deploy, og lægger færdige HTML-filer på et CDN. Der er ingen PHP-proces, ingen database og ingen plugin-hooks, når en besøgende rammer siden — der er en fil. TTFB bliver et spørgsmål om afstand til nærmeste edge-node, ikke om hvad din server nåede at regne ud.
Det fjerner tre poster på én gang. Plugin-overhead findes ikke, fordi der ikke er noget runtime at hænge det på. Angrebsfladen skrumper, fordi der ikke er en eksekverende applikation at udnytte — de 91 % plugin-sårbarheder har ingen adresse. Og vedligeholdelsesabonnementet har ikke noget at holde i live mellem udgivelserne.
Sitet her er bygget sådan: HTML genereret ved build, CSS inline i dokumentet, nul JavaScript sendt til browseren. Prisen er, at redaktøroplevelsen er en anden, og at man ikke bare installerer en funktion, man mangler. Det er en reel omkostning. Den skal bare vejes mod de rigtige tal, ikke mod en fornemmelse af, at WordPress er "det nemme valg".
Hvornår WordPress stadig er det rigtige valg
Der findes situationer, hvor svaret er WordPress, og hvor jeg vil sige det. Har du et redaktionsteam på fem, der publicerer dagligt og skal have et velkendt værktøj, vinder WordPress. Har du en WooCommerce-shop med en ERP-integration, der virker, er migreringen sjældent pengene værd, før noget andet tvinger den frem. Og skal sitet bruge funktionalitet, der findes færdig som plugin, og du hverken har budget eller lyst til at få den bygget, så er plugin-stakken prisen for at slippe billigt.
Det er en reel afvejning. Det, der ikke længere holder, er argumentet om, at WordPress er den hurtige vej. Tallene siger det modsatte.
Sådan afgør du det på dit eget site
Brug tre målinger, i denne rækkefølge, før du beslutter noget:
- p75 TTFB fra felt-data. Ikke fra en test i Lighthouse — fra rigtige besøgende. Ligger den over 800 ms, er problemet stakken, og frontend-optimering er spildt arbejde. Ligger den under 300 ms, kan du optimere frontend med udbytte.
- Antal aktive plugins, og hvornår hvert af dem sidst blev opdateret. Alt over to år uden opdatering er gæld, ikke funktionalitet.
- p75 LCP på din vigtigste landingsside. Ikke forsiden. Den side, folk kommer ind på fra Google.
Jeg har skrevet rækkefølgen ud i gennemgangen af Core Web Vitals og fejlsøgningen i tekniske SEO-problemer. Skal du bruge tallene til at afgøre, om det er et nyt site eller en optimering, ligger beslutningsgrundlaget i nyt website eller optimering.
Mål p75 TTFB og p75 LCP på dine to vigtigste landingssider, før du beslutter noget. Ligger TTFB over Googles grænse på 800 ms, er der ingen grund til at bruge en krone på frontend-optimering: problemet sidder i stakken, og spørgsmålet er, om du skal flytte hosting eller flytte platform. Tæl samtidig dine aktive plugins og hvornår hvert af dem sidst blev opdateret — alt over to år er gæld, ikke funktionalitet.
Vil du have målingen og vurderingen udefra, laver jeg den som en afgrænset opgave: felt-data, plugin-gæld og hostingopsætning gennemgået, med en anbefaling der enten lyder "bliv, og ret hosting" eller "byg om" — og et estimat på begge veje, så du kan regne på det selv. Priserne står under ydelser. Send domænet, så siger jeg hvad jeg ser.