Skip to main content
Fra 4 sekunder til under 200 ms

WordPress-ytelse

Nettsiden din bruker fire sekunder på å laste. Besøkende forventer under to. Google straffer alt over 2,5. FrankenPHP Worker Mode endrer regnestykket fullstendig.

Treg nettside?
Google har allerede lagt merke til det

Google har bekreftet at Core Web Vitals påvirker rangeringer. Hvert sekund ekstra lastetid øker fluktfrekvensen med opptil 32 %. For en bedriftsnettside som lever av synlighet i søkemotorene, er treg ytelse det samme som å betale for usynlighet.

De fleste WordPress-sider på delt webhotell bruker 2-5 sekunder på å laste. Pluginene laster JavaScript du ikke trenger. Temaet kjører databasespørringer det aldri burde. Og serveren starter WordPress fra bunnen av for hver eneste sidevisning.

Vi har nok sett dette hundrevis av ganger. Og svaret er sjelden «installer en caching-plugin». Svaret er arkitektur.

<30ms

TTFB med FrankenPHP

98/100

Lighthouse Performance

32%

Økt fluktfrekvens per sekund

0ms

Total Blocking Time

Hva gjør WordPress treg?

Ytelsesproblemene er sjelden WordPress sin feil. De er konsekvensen av feil arkitektur, feil hosting og for mange plugins.
01 / 04

For mange plugins

Hver plugin legger til JavaScript, CSS og databasespørringer. 20 plugins kan bety 400 KB ekstra JavaScript og 50+ databasespørringer per sidevisning.
02 / 04

Treg database

WordPress sin EAV-databasemodell er fleksibel, men treg i skala. Uten object cache må databasen gjøre samme jobb for hver besøkende.
03 / 04

Delt webhotell

Du deler server med hundrevis av andre nettsider. Når nabosiden har en trafikktopp, merker du det. PHP-versjonen er utdatert og du har ingen kontroll.
04 / 04

Ingen caching-strategi

En caching-plugin er bedre enn ingenting, men det er et plaster på et arkitekturproblem. Riktig caching skjer på infrastrukturnivå med Redis og Varnish.

FrankenPHP Worker Mode
applikasjonen i minnet

Tradisjonell WordPress-hosting starter PHP fra bunnen for hver sidevisning. Laster rammeverket, kobler til database, initialiserer plugins, bygger siden. Og gjør det hele på nytt for neste besøkende.

FrankenPHP Worker Mode endrer dette fundamentalt. Applikasjonen startes én gang og blir liggende i minnet, klar til å svare øyeblikkelig. Oppstartskostnaden eliminert. Resultatet er TTFB under 30 millisekunder, mot 200-300 ms med tradisjonell PHP-FPM.

I tillegg gir FrankenPHP automatisk HTTPS, HTTP/2 og HTTP/3 ut av boksen, og Early Hints som lar nettleseren begynne å laste ressurser før siden er ferdig generert.

Ytelsesoptimalisering i alle lag

01 / 06

Redis Object Cache

Databasespørringer cachet i minnet. Handlekurver, sesjoner og transiente data hentes fra Redis i stedet for MySQL. Dramatisk lavere databasebelastning.
02 / 06

Bildekomprimering

Automatisk konvertering til WebP/AVIF med responsive srcset. Bilder serveres i riktig størrelse for enhetens skjerm. Ingen 4 MB JPEG-er til mobil.
03 / 06

Kritisk CSS

Above-the-fold CSS inlines i HTML. Resten lazy-loades asynkront. Eliminerer render-blokkering og gir raskere First Contentful Paint.
04 / 06

Lazy loading

Bilder, iframes og tunge komponenter laster først når de er i viewport. Reduserer initial sidelast og forbedrer Time to Interactive.
05 / 06

CDN og edge caching

Statiske ressurser serveres fra edge-noder nær brukeren. Traefik håndterer intelligent cache-invalidering ved deploy.
06 / 06

Databaseoptimalisering

Query Monitor identifiserer trege spørringer. Indeksering, query optimization og transient cleanup gjøres systematisk, ikke tilfeldig.

Før og etter optimalisering

butikken.no4.2s
19 plugins · Delt webhotell
butikken.no180ms
4 plugins · FrankenPHP + Redis

Samme nettside, to forskjellige arkitekturer. Forskjellen handler ikke om WordPress. Den handler om hvordan WordPress er satt opp [1].

  1. [1]Google/SOASTA — The State of Online Retail Performance

Core Web Vitals: Typisk vs. optimalisert

Typisk 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
PXL-optimalisert
Google anbefaler
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 ytelse

Vi bruker ikke «det føles raskere» som mål. Vi måler konkrete tall og setter terskler.
01 / 04

Lighthouse CI

Automatiserte Lighthouse-kjøringer i CI/CD-pipelinen. Bygget blokkeres hvis ytelsen faller under terskelen. Ingen regresjoner slipper gjennom.
02 / 04

Real User Monitoring

Core Web Vitals fra ekte brukere, ikke bare labdata. Vi ser forskjellen mellom mobil og desktop, mellom Norge og resten av verden.
03 / 04

Syntetisk overvåkning

Regelmessige ytelsestester fra flere geografiske lokasjoner. Trendlinjer viser om ytelsen forbedres eller degraderes over tid.
04 / 04

Query Monitor

Detaljert analyse av databasespørringer, hooks og PHP-minnebruk per sidevisning. Identifiserer flaskehalser med kirurgisk presisjon.

Når trenger du ytelsesoptimalisering?

Noen signaler er tydelige:

  • Nettsiden bruker over 2 sekunder på å laste — selv med caching-plugin
  • Lighthouse Performance-score er under 70
  • Google Search Console varsler om Core Web Vitals-problemer
  • Besøkende forlater siden før den er lastet ferdig
  • Nettsiden er merkbart tregere på mobil enn desktop
  • Du merker ytelsesfall under kampanjer eller trafikktopper

Da handler det nok ikke om en bedre caching-plugin. Da handler det om infrastruktur.

SB
CG
JB
Mer om oss

Klar for å bygge noe skikkelig?

Enten du starter på nytt, eller må få orden på noe eksisterende – vi kan hjelpe.

Kontakt ossVåre tjenester