Skip to main content
Lastetiden ned fra 4 sekunder til under 200 ms

WordPress-ytelse

God WordPress-ytelse måles i millisekunder. Vi bygger om på FrankenPHP Worker Mode og Redis, får Core Web Vitals i grønt og dokumenterer hvert grep med konkrete tall.

Laster siden tregt?
Google merket det før deg

Dårlig WordPress-ytelse koster mer enn tålmodighet. Core Web Vitals teller i rangeringen, og hvert ekstra sekund lastetid øker fluktfrekvensen med opptil 32 % ifølge Googles egne tall. Synlighet du betaler for, tapt før siden i det hele tatt vises.

En typisk WordPress-side på delt webhotell laster på 2-5 sekunder. Pluginene sender JavaScript til besøkende som aldri får bruk for det. Temaet kjører databasespørringer ingen har bedt om. Og serveren bygger hele WordPress fra bunnen av ved hver eneste sidevisning, for samtlige som åpner siden.

Vi har feilsøkt hundrevis av slike sider, og selv om symptomene varierer fra side til side, går mønsteret under panseret igjen. Svaret er sjelden å installere enda en caching-plugin. Det som faktisk flytter siden, er arkitekturen den hviler på.

<30ms

TTFB med FrankenPHP Worker Mode

98/100

Lighthouse Performance i produksjon

32%

Høyere fluktfrekvens per ekstra sekund

0ms

Total Blocking Time etter optimalisering

Hvorfor er WordPress-siden treg?

Skylden ligger jo sjelden hos WordPress selv. Den ligger i alt rundt: feil hosting og en plugin-liste ingen har ryddet i på årevis.
01 / 04

Plugins uten opprydding

Hver eneste plugin tar med seg JavaScript, CSS og nye databasespørringer inn på siden. 20 plugins gir fort 400 KB ekstra skript og 50+ spørringer mot databasen — og den regningen betales på nytt for hver eneste sidevisning.
02 / 04

En database som gjentar seg selv

EAV-modellen i WordPress er fleksibel, men treg når datamengden vokser. Uten object cache tygger databasen seg gjennom nøyaktig samme jobb for hver eneste besøkende.
03 / 04

Naboene på webhotellet

Du deler maskin med hundrevis av andre nettsteder. Får naboen en trafikktopp, er det din lastetid som betaler regningen — og PHP-versjonen bestemmer noen andre uansett.
04 / 04

Caching som plaster

En caching-plugin demper symptomene, men arkitekturproblemet under blir liggende urørt. Skikkelig caching skjer på infrastrukturnivå, med Redis foran databasen og Varnish foran applikasjonen.

FrankenPHP Worker Mode
hele WordPress ferdig lastet i minnet

Tradisjonell WordPress-hosting starter PHP helt på nytt for hver eneste forespørsel. Først lastes rammeverket, så kobles databasen opp og hver plugin initialiseres på nytt. Når siden er levert, kastes alt sammen, og nestemann får nøyaktig samme runde noen millisekunder senere. Det skjer flere tusen ganger i døgnet på en travel side, og hver runde koster tid ingen besøkende får igjen.

Worker Mode fjerner akkurat denne sløsingen. I stedet for å bygge alt opp på nytt holder serveren applikasjonen ferdig lastet i minnet mellom forespørslene, slik at svaret begynner å komme idet forespørselen treffer. Dermed forsvinner oppstartskostnaden helt, og TTFB lander under 30 millisekunder. Til sammenligning bruker en vanlig PHP-FPM-oppsett 200-300 ms bare på å komme i gang.

FrankenPHP er dessuten bygget på Caddy. Automatisk HTTPS følger med uten en eneste konfigurasjonslinje, det samme gjør HTTP/2 og HTTP/3, og Early Hints lar nettleseren hente ressurser mens serveren fortsatt setter sammen resten av siden.

WordPress-ytelse i alle lag

01 / 06

Redis Object Cache

Spørringsresultatene ligger ferdige i minnet. Handlekurver, sesjoner og transients hentes fra Redis i stedet for MySQL, og belastningen på databasen stuper.
02 / 06

Bilder i riktig format

WebP og AVIF genereres automatisk, med responsiv srcset for hver skjermstørrelse. Ingen mobilbrukere skal måtte laste ned en 4 MB stor JPEG over mobilnettet.
03 / 06

Kritisk CSS

CSS-en for det synlige feltet inlines rett i HTML-dokumentet, mens resten lastes asynkront etter at brukeren allerede ser innhold. Ingen render-blokkering, raskere First Contentful Paint.
04 / 06

Lazy loading

Bilder, iframes og tunge komponenter venter til de nærmer seg viewport før de lastes. Den første sidelastingen blir lettere, og Time to Interactive faller tilsvarende.
05 / 06

Edge-cache nær brukeren

Statiske ressurser besvares fra edge-noden som står nærmest den som spør. Ved deploy invaliderer Traefik nøyaktig de oppføringene som er berørt, i stedet for å tømme alt.
06 / 06

Databaseoptimalisering

Query Monitor peker ut de trege spørringene først, deretter legger vi indekser der de mangler og rydder gamle transients ut av wp_options. Effekten av hvert grep måles før vi går videre.

Samme nettside, to målinger

butikken.no4.2s
19 plugins på delt webhotell
butikken.no180ms
4 plugins på FrankenPHP + Redis

Identisk innhold målt med identisk verktøy — det eneste som er byttet ut, er arkitekturen under [1].

Core Web Vitals: tallene side om side

Vanlig WordPress
LCP
3.2s (dårlig)
INP
280ms (trenger forbedring)
CLS
0.15 (trenger forbedring)
TTFB
1.2s
FCP
2.8s
Total Blocking Time
450ms
Lighthouse Score
45-65
Bygd av PXL
Googles terskel
LCP
0.8s (bra)
INP
12ms (bra)
CLS
0.01 (bra)
TTFB
28ms
FCP
0.6s
Total Blocking Time
0ms
Lighthouse Score
95-100

Slik måler vi WordPress-ytelse

Vi stoler ikke på magefølelsen når ytelse skal vurderes. Hver terskel settes i konkrete tall, og vi dokumenterer nøyaktig hva hvert grep endret.
01 / 04

Lighthouse CI

Automatiserte Lighthouse-kjøringer ligger inne i CI/CD-pipelinen, og faller scoren under terskelen vi har satt, blir bygget blokkert før det når produksjon. Regresjoner stoppes i døra.
02 / 04

Real User Monitoring

Labdata er kontrollerte og snille. Ekte brukere er ikke det, så vi henter Core Web Vitals fra faktiske besøk og ser hvor mobil, desktop og utlandet skiller lag.
03 / 04

Syntetisk overvåkning

Faste ytelsestester fra flere geografiske punkter, døgnet rundt. Trendlinjene avslører gradvis forverring lenge før noen rekker å irritere seg over den i nettleseren.
04 / 04

Query Monitor

Databasespørringer, hooks og PHP-minnebruk analyseres per sidevisning. Da slipper vi å gjette: flaskehalsen får et konkret navn og et linjenummer å peke på.

Når er det på tide å ta tak i ytelsen?

Noen varsler er vanskelige å overse:

  • Lastetiden ligger over 2 sekunder selv etter at caching-pluginen er på plass
  • Lighthouse gir Performance-score under 70
  • Google Search Console flagger Core Web Vitals-problemer
  • Besøkende gir opp før siden rekker å vise innhold
  • Mobilopplevelsen henger merkbart etter desktop
  • Kampanjer og trafikktopper gjør siden tregere akkurat når den skal selge mest

Kjenner du igjen tre eller flere? Da bør du nok se på infrastrukturen før du installerer enda en plugin.

Spørsmål vi ofte får

Nysgjerrig på hvor rask WordPress-siden din kan bli?

Fortell oss litt om nettsiden, så kommer vi tilbake med konkrete tall på potensialet.