En WordPress-side kan loade på under ét sekund. Den samme WordPress-installation kan også bruge otte sekunder på at vise sin forside. Forskellen ligger sjældent i WordPress selv - den ligger i de beslutninger der er truffet oven på det.
Denne guide gennemgår hvert lag i WordPress-performance-stakken: fra servervalg og caching til billeder, JavaScript, databasen og CDN. Målet er at du kan åbne PageSpeed Insights og begynde at rette problemer med det samme.
Hvorfor WordPress-sider er langsomme - og hvad det egentlig handler om
WordPress som platform er ikke langsom. Det er et modent, veloptimeret PHP-system der serverer milliarder af sidevisninger dagligt. Problemet opstår konsekvent på samme steder: for mange plugins der gør for meget, et tema der loader halvt internet af JavaScript på forsiden, og en hosting-løsning der ikke er dimensioneret til opgaven.
Hver gang en bruger besøger din side, skal WordPress forespørge databasen, eksekvere PHP, samle HTML, og sende det afsted - sammen med alle de CSS- og JavaScript-filer der er registreret. Et gennemsnitligt WordPress-site loader i dag over 20 separate scripts og stylesheets. Mange af dem er unødvendige på de fleste sider.
Det er et arkitekturproblem, ikke et WordPress-problem. Og det betyder at løsningen er disciplin i plugin-valg, korrekt konfiguration og et bevidst setup - ikke at skifte platform. Du kan læse mere om almindelige misforståelser om PHP og WordPress plugins for at forstå, hvorfor mange af de forestillinger folk har om WordPress-performance ikke holder vand.
Mål performance rigtigt - og forstå hvad tallene betyder
Før du optimerer, skal du vide hvad du måler. Her er tre centrale værktøjer og deres forskelle:
PageSpeed Insights kombinerer lab-data fra Lighthouse med field-data fra Chrome User Experience Report (CrUX). Field-data er rigtige brugeres oplevelse over de seneste 28 dage - det er det Google bruger i ranking-signalet. Lab-data er en simuleret test under kontrollerede forhold. Begge er nyttige, men de fortæller ikke det samme.
Lighthouse (i Chrome DevTools eller som CLI) giver dig detaljerede diagnostikker og mulighed for at teste lokalt eller bag login. Brug det til at forstå hvad der er galt, ikke som den endelige dom over din side.
GTmetrix giver et vandfald der viser præcis hvilke ressourcer der loader hvornår, og i hvilken rækkefølge. Det er uundværligt til at identificere render-blocking ressourcer og tredjepartsscripts der forsinker siden.
Core Web Vitals er de tre målinger der tæller mest: LCP (Largest Contentful Paint - hvornår det vigtigste indhold er synligt), INP (Interaction to Next Paint - responsivitet ved interaktion) og CLS (Cumulative Layout Shift - visuel stabilitet). Se den dybdegående artikel om Core Web Vitals og brugeroplevelse for en grundig gennemgang af hver metrik og hvad der påvirker dem.
Hosting som fundament
Ingen mængde caching og optimering kompenserer for dårlig hosting. Det er det fundament alt andet hviler på.
Dårlig WordPress-hosting kender du på: delt server med hundredvis af andre sites, ingen opcode-cache (OPcache), PHP 7.4 eller ældre, MySQL uden query-cache, og support der sender dig et link til en artikel i stedet for at løse problemet. Loadtider på 2-4 sekunder selv på en tom WordPress-installation er symptomer.
God hosting har OPcache aktiveret, kører PHP 8.2+, tilbyder Redis eller Memcached til objekt-cache, og placerer din database tæt på din webserver - helst på samme maskine eller i samme datacenter. Managed WordPress-hosting fra udbydere som Kinsta, WP Engine eller Cloudways er typisk konfigureret korrekt fra start.
Fremragende hosting tilføjer server-niveau side-caching (Nginx FastCGI cache eller lignende), automatisk HTTP/2 eller HTTP/3, og geografisk placering tæt på dine primære brugere. Kombineret med et CDN - mere om det senere - er det fundamentet for en side der konsekvent scorer grønt i Core Web Vitals.
Caching-lagene forklaret
Caching er ikke ét valg - det er flere lag der arbejder uafhængigt af hinanden.
Side-cache gemmer den færdige HTML-output fra WordPress og serverer den direkte uden at eksekvere PHP eller forespørge databasen. Det er det mest effektive enkeltgreb du kan gøre. Plugins som W3 Total Cache, WP Super Cache og LiteSpeed Cache håndterer dette på applikationsniveau - men den mest effektive side-cache sidder i Nginx eller Apache, før PHP overhovedet starter.
Objekt-cache gemmer resultater af databaseforespørgsler i hukommelsen, så gentagne kald til `wp_options` eller custom queries ikke rammer databasen hver gang. WordPress har et indbygget objekt-cache API, men det er ikke persistent som standard - det nulstilles ved hvert sideload. Med Redis eller Memcached som persistent backend overlever cachen på tværs af requests. På sites med mange samtidige brugere eller tunge queries er det afgørende.
Browser-cache styres via HTTP-headers (Cache-Control, Expires) og fortæller browseren hvor længe den må gemme statiske filer lokalt. Billeder, CSS og JavaScript bør have lange cache-tider - typisk 1 år - kombineret med versionerede filnavne (cache-busting) så opdateringer stadig leveres korrekt.
OPcache er PHP's egen bytecode-cache. Når PHP kompilerer en fil første gang, gemmes resultatet i hukommelsen og genbruges ved efterfølgende requests. Det reducerer CPU-forbrug markant. Sørg for at det er aktiveret og dimensioneret korrekt - standardkonfigurationen er ofte for lille til et aktivt WordPress-site.
Billeder: det største lavthængende frugt
Billeder udgør gennemsnitligt 50-70% af en websides samlede filstørrelse. Det er også det område hvor de fleste sites har de største uoptimerede ressourcer liggende.
Brug WebP som standard format - det er 25-35% mindre end JPEG ved samme visuelle kvalitet og understøttes af alle moderne browsere. AVIF er endnu mere effektivt (30-50% mindre end WebP), men browserunderstøttelsen er stadig ikke universel nok til at erstatte WebP helt. Brug AVIF med WebP som fallback via ``-elementet.
Komprimering skal ske ved upload - ikke ved visning. Plugins der komprimerer on-the-fly bruger serverressourcer ved hvert request. Brug et plugin der konverterer og komprimerer ved upload og gemmer de optimerede versioner til disk.
Srcset og sizes er afgørende for mobilperformance. WordPress genererer automatisk srcset-attributter for uploadede billeder, men du skal sørge for at dine temaer og page builders bruger dem korrekt og ikke hardkoder bredder. En bruger på en 375px bred mobil skal ikke downloade et 1200px bredt billede.
Lazy loading er nu standard i WordPress via `loading="lazy"` på img-tags. Det er godt - men det vigtigste billede på siden (typisk hero-billedet eller LCP-elementet) må aldrig lazy loades. Det vil forsinke LCP direkte. Sæt eksplicit `loading="eager"` og overvej at tilføje `fetchpriority="high"` på LCP-billedet.
JavaScript og CSS: render-blocking er fjenden
Browseren kan ikke rendere siden mens den downloader og parser render-blocking ressourcer. Hvert script og stylesheet i `
` uden `defer` eller `async` blokerer rendering.Defer og async på JavaScript-filer fortæller browseren at den ikke behøver vente. `defer` downloader filen parallelt og eksekverer den efter HTML-parsing er færdig - i dokumentrækkefølge. `async` downloader og eksekverer så hurtigt som muligt, uden garanti for rækkefølge. Brug `defer` til scripts der er afhængige af DOM eller hinanden, `async` til uafhængige scripts som analytics.
Critical CSS er den CSS der er nødvendig for at rendere det synlige indhold uden scroll (above the fold). Inlining af critical CSS i `
` og deferred loading af resten af stylesheetet eliminerer render-blocking CSS. Det er et af de mest effektive greb til at forbedre LCP - men det kræver enten manuel ekstraktion eller et værktøj der gør det automatisk.Gennemgå hvilke scripts der faktisk er nødvendige på hver side. Et kontaktformular-plugin behøver ikke loade sit JavaScript på blogindlæg. Conditional loading - at registrere scripts kun på de sider der bruger dem - er en af de mest undervurderede optimeringsteknikker i WordPress-udvikling.
Database-oprydning og -optimering
WordPress-databasen vokser over tid med revisioner, transients, spam-kommentarer og forældede metadata. En oppustet database er sjældent årsagen til dramatisk langsom performance, men det bidrager - og det gør administration sværere.
Post-revisioner er den største synder. WordPress gemmer som standard ubegrænset antal revisioner. Tilføj `define('WP_POST_REVISIONS', 5);` i `wp-config.php` for at begrænse det. Ryd eksisterende revisioner op med et plugin eller direkte SQL.
Transients er midlertidige data gemt i `wp_options`. Udløbne transients ryddes normalt automatisk, men på travle sites kan de hope sig op. Kør `DELETE FROM wp_options WHERE option_name LIKE '%_transient_%' AND option_value < UNIX_TIMESTAMP();` for at rydde op manuelt.
Tabellerne bør optimeres jævnligt. `OPTIMIZE TABLE` defragmenterer tabellerne og genvinder ledig plads. Det kan gøres via phpMyAdmin eller med WP-CLI: `wp db optimize`.
Slow query log er dit vigtigste diagnoseværktøj til database-performance. Aktiver det i MySQL-konfigurationen og sæt tærsklen til 1 sekund. Queries der konsekvent dukker op er kandidater til indeksering eller caching.
CDN: hvornår giver det mening
Et Content Delivery Network distribuerer dine statiske filer - billeder, CSS, JavaScript - til servere geografisk tæt på dine brugere. I stedet for at alle requests rammer din server i fx Frankfurt, serveres filer fra den nærmeste PoP (Point of Presence).
Et CDN giver mening når: dine brugere er geografisk spredte, din hosting-server er geografisk langt fra din primære målgruppe, eller du har høj trafik og vil aflaste din webserver. For et dansk site med primært danske brugere og en server i Danmark er gevinsten ved et CDN mere begrænset - men det reducerer stadig belastningen på din server og kan forbedre TTFB (Time to First Byte) markant for internationale besøgende.
Cloudflare er det mest udbredte valg og tilbyder et gratis lag med CDN, DDoS-beskyttelse og automatisk komprimering. Det er i de fleste tilfælde det rigtige udgangspunkt. Alternativt integrerer managed WordPress-hosts ofte med Cloudflare eller BunnyCDN.
Vær opmærksom på cache-invalidering: når du opdaterer indhold, skal CDN-cachen ryddes. De fleste WordPress CDN-plugins håndterer dette automatisk ved publicering.
Et minimalt, performant plugin-setup
Hvert plugin tilføjer potentielt PHP-eksekvering, databaseforespørgsler og scripts til din side. Det handler ikke om at have færrest mulige plugins - det handler om at hvert plugin tjener et klart formål og er implementeret effektivt.
SEO-plugins er et godt eksempel. Et tungt SEO-plugin der loader scripts og stylesheets på alle sider - inklusiv admin - kan alene tilføje hundredvis af millisekunder. Signocore SEO er bygget med performance som et eksplicit designprincip: det loader kun hvad der er nødvendigt, og kun på de sider hvor det er relevant. Kombineret med Signocore Toolkit - der samler en række nyttige WordPress-forbedringer i ét plugin frem for mange separate - reducerer du antallet af aktive plugins uden at miste funktionalitet.
Princippet er konsolidering: ét plugin der gør tre ting effektivt er næsten altid bedre end tre plugins der hver gør én ting, men bringer sin egen afhængighedstræ med.
Et realistisk performance-budget og tjekliste
Et performance-budget er en konkret grænse for hvad en side må koste at loade. Det tvinger prioritering og forhindrer at performance langsomt eroderes med hvert nyt feature eller plugin.
Et realistisk budget for et WordPress-site med primært tekstindhold og et par billeder:
Total sidestørrelse: under 1 MB (komprimeret over wire)
JavaScript: under 200 KB (parsed og eksekveret)
CSS: under 50 KB (critical CSS inline, resten deferred)
Billeder: ingen enkelt billedfil over 150 KB
LCP: under 2,5 sekunder på mobile devices
TTFB: under 600 ms
Tjekliste til en komplet performance-gennemgang:
Hosting: OPcache aktiveret, PHP 8.3+, Redis/Memcached tilgængeligt
Side-cache: aktiveret og verificeret (tjek Response Headers for cache-status)
Objekt-cache: persistent backend konfigureret
Billeder: WebP-konvertering aktiv, srcset korrekt, LCP-billede har fetchpriority="high"
JavaScript: alle scripts har defer eller async, ingen unødvendige scripts på sider der ikke bruger dem
CSS: critical CSS inlined, render-blocking stylesheets elimineret
Database: revisioner begrænset, transients ryddet, tabeller optimeret
CDN: statiske assets serveres fra CDN, cache-invalidering testet
Plugins: gennemgå aktive plugins og deaktiver alt der ikke aktivt bruges
Måling: PageSpeed Insights field-data grønt på mobile Core Web Vitals
Performance er ikke en opgave der afsluttes - det er en egenskab ved et site der kræver løbende opmærksomhed. Nye plugins, opdateringer, nyt indhold og voksende databaser ændrer billedet over tid. Sæt PageSpeed Insights i din kalender som en månedlig tjekopgave, og behandl performance-regression som en fejl der skal rettes - ikke en uundgåelig konsekvens af et levende site.
