Slik fikk vi WordPress fra 4 sekunder til 180 ms
WordPress-ytelse steg for steg: slik gjorde vi en WordPress-side 22 ganger raskere med FrankenPHP Worker Mode, Redis og plugin-opprydding.
- Publisert
- Oppdatert
- Lesetid
- 7 min

Kort fortalt
- WordPress-ytelse avgjøres av arkitekturen: server, PHP-versjon, plugins, database og hosting henger sammen, og en caching-plugin retter ikke opp grunnproblemet.
- FrankenPHP Worker Mode holder WordPress i minnet og gir TTFB under 30 ms, mens Redis Object Cache fjerner mesteparten av databasebelastningen.
- Etter plugin-opprydding, overgang fra Elementor til Gutenberg og CI/CD med ytelsestesting kommer de fleste WordPress-sider under 200 millisekunder i responstid.
Nettsiden din er treg, og Google har lagt merke til det
WordPress-ytelse avgjøres av arkitekturen. Serveren, PHP-versjonen, antall plugins, databasen og hostingmiljøet henger sammen, og én flaskehals drar ned resten. En caching-plugin retter ikke opp noe av dette. FrankenPHP Worker Mode gir TTFB under 30 ms i våre målinger, og Redis Object Cache fjerner mesteparten av databasebelastningen.
De fleste WordPress-sider vi ser bruker mellom 2 og 5 sekunder på å laste. Google anbefaler under 2,5 sekunder for Largest Contentful Paint. Ifølge Google/SOASTA Research (2017) øker sannsynligheten for at en mobilbesøkende forlater siden med 32 % når lastetiden går fra 1 til 3 sekunder. Det koster deg trafikk, rangeringer og konverteringer.
Med riktig infrastruktur og noen strukturelle grep kommer de fleste WordPress-sider under 200 millisekunder i total responstid.
Hvorfor er WordPress treg?
WordPress i seg selv er ikke tregt. Problemet er summen av valgene rundt. Noen er tatt bevisst, men de fleste ble tatt av byrået som leverte nettsiden for tre år siden og aldri så på den igjen.
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. Noen plugins laster ressursene sine på alle sider, også der de ikke brukes.
Vi ser jevnlig nettsider med 25–40 aktive plugins. Tre av dem gjør det samme, fem har ingen oppdatert på over et år, og to har kjente sikkerhetshull som ingen har tatt tak i.
Tunge sidebyggere
Elementor, WPBakery og Divi lar folk uten kodekunnskap lage nettsider, og det er et reelt behov. Prisen er ytelsen.
En typisk Elementor-side laster 300–500 KB ekstra JavaScript og CSS på alle sider, også de som ikke bruker Elementor-funksjonalitet. Hvert widget-element genererer nestet HTML som gjør siden tyngre enn nødvendig. Gutenberg med egne blokker er et bedre valg for ytelse.
Delt webhotell
Du deler server med hundrevis av andre nettsider, så når nabosiden får en trafikktopp, merker du det. PHP-versjonen er ofte utdatert (7.x er fortsatt vanlig i Norge, selv om PHP 7.4 mistet støtten i november 2022), og du har ingen kontroll over serverkonfigurasjonen.
Delt hosting er greit for en hobbyblogg. For en bedriftsnettside som skal gi henvendelser og salg, er det uforsvarlig.
Treg database uten caching
Databasemodellen i WordPress (EAV-mønsteret i wp_postmeta) er fleksibel, men treg med store datamengder. Uten object cache gjør databasen det samme arbeidet for hver eneste besøkende. Over 100 spørringer per sidevisning er vanlig på dårlig konfigurerte sider.
FrankenPHP: serveren som endrer regnestykket
Tradisjonell WordPress-hosting bruker Apache eller Nginx med PHP-FPM. Hver gang noen besøker nettsiden, starter serveren PHP fra bunnen: den laster WordPress-kjernen og alle plugins, kobler til databasen, bygger siden og sender den til nettleseren. Så gjør den det samme for neste besøkende.
FrankenPHP er en applikasjonsserver for PHP bygget på Caddy. I Worker Mode ligger WordPress-applikasjonen i minnet og kan svare med en gang.
Forskjellen i praksis:
- Tradisjonell PHP-FPM gir TTFB på 200–400 ms i beste fall, ofte 1–4 sekunder på delt hosting.
- FrankenPHP Worker Mode gir typisk TTFB under 30 ms i våre målinger.
FrankenPHP har også automatisk HTTPS via Let's Encrypt, HTTP/2 og HTTP/3 uten ekstra oppsett, og Early Hints, som lar nettleseren begynne å laste ressurser før siden er ferdig generert.
Bare ved å flytte fra delt hosting til FrankenPHP ser vi typisk 90–99 % lavere TTFB, uten å endre en eneste linje kode.
Redis: databasen som lever i minnet
Det nest viktigste grepet etter serverbyttet er Redis Object Cache. Redis lagrer resultatene i minnet, så WordPress slipper å spørre MySQL-databasen ved hvert sidebesøk.
En nettside med 127 databasespørringer per sidevisning kan komme ned i 8–10, fordi resten treffer cachen. Handlekurver og sesjoner hentes fra Redis i stedet for fra MySQL, og køer for e-post og ERP-synkronisering kjører i bakgrunnen uten å gå ut over ytelsen.
Redis kjører som en infrastrukturtjeneste ved siden av WordPress. En caching-plugin inne i WordPress er et kompromiss, mens Redis løser selve problemet.
Plugin-opprydding: færre, lettere, bedre
Etter infrastrukturen tar vi fatt på pluginene. Regelen er enkel: kan det løses med 50 linjer ren kode, er det bedre enn en plugin.
Dette fjerner vi som regel
- Caching-plugins (unødvendige med Redis og FrankenPHP)
- SEO-plugins som overlapper hverandre
- «Optimaliserings»-plugins som i praksis gjør siden tregere
- Inaktive plugins som fortsatt laster kode i bakgrunnen
- Kontaktskjema-plugins med 400 KB JavaScript for et skjema med tre felter
Dette erstatter vi med egen kode
Vi bygger lette WPFluent-plugins med MVC-arkitektur for kontaktskjema, nyhetsbrev-integrasjon, custom post types og lignende funksjoner som plugins ofte bare løser halvveis. En slik plugin er typisk 10–20 KB. Pluginene den erstatter, er 1–3 MB.
JavaScript går fra over 1 MB til under 350 KB, og CSS fra over 600 KB til under 150 KB.
Elementor ut, Gutenberg inn
Denne delen tar mest tid, men gir stor effekt. Vi flytter Elementor-innholdet til Gutenberg, med blokker vi lager selv og som gir ren, semantisk HTML.
Med egne Gutenberg-blokker får du:
- Ren HTML uten nestet shortcode-spaghetti
- Ikke noe Elementor-rammeverk i JavaScript (300–500 KB spart)
- Bedre tilgjengelighet (WCAG), fordi du styrer HTML-strukturen selv
- En raskere redaktøropplevelse i wp-admin
- Enklere vedlikehold
For nye prosjekter anbefaler vi å holde seg unna Elementor. Trenger prosjektet ikke WordPress, gir Sanity + Next.js enda bedre ytelse uten plugin-problemene.
Core Web Vitals: tallene Google bryr seg om
Google måler brukeropplevelse med tre metrikker. Terskelverdiene på web.dev gjelder 75-persentilen av sidevisningene, på mobil og desktop.
LCP (Largest Contentful Paint) måler hvor raskt hovedinnholdet vises. Google anbefaler under 2,5 sekunder, og etter optimalisering ligger vi typisk på 0,8–1,2 sekunder.
INP (Interaction to Next Paint) måler responstiden når brukeren klikker eller blar. Google anbefaler under 200 ms. Etter optimalisering er den typisk 10–30 ms.
CLS (Cumulative Layout Shift) måler visuell stabilitet. Google anbefaler under 0,1, og etter optimalisering er den typisk 0,01.
Google bekrefter at Core Web Vitals brukes av rangeringssystemene. Samtidig understreker Google at det ikke finnes ett enkelt signal, og at relevant innhold fortsatt vinner. Gode tall er altså ingen garanti, men røde Core Web Vitals gir konkurrenter med like godt innhold et forsprang.
Slik måler du WordPress-ytelse
Tre gratis verktøy gir deg svaret.
Google PageSpeed Insights viser både labdata og feltdata fra ekte brukere. Testen tar 30 sekunder og viser hva som trekker ned.
Google Search Console viser Core Web Vitals for hele nettsiden over tid. Utviklingen sier like mye som enkeltmålingene.
Query Monitor er en WordPress-plugin som viser databasespørringer, hooks, minnebruk i PHP og lastetid per komponent. Den avslører hvilke plugins som bremser siden.
Kjør PageSpeed Insights nå. Er scoren under 70, har du et problem som koster deg penger.
Hva med caching-plugins?
WP Super Cache, W3 Total Cache og LiteSpeed Cache lover alle raskere nettsider, og de holder det delvis.
En caching-plugin lagrer ferdige HTML-sider og serverer dem direkte uten å kjøre PHP. Det er bedre enn ingenting, men det dekker over et arkitekturproblem:
- Cachen må tømmes når innholdet endres, og det feiler ofte
- Innloggede brukere (handlekurv, Min side) får ikke cachet innhold
- Første besøk etter at cachen er tømt, er like tregt som uten cache
- Pluginen gjør en allerede sammensatt stack enda mer sammensatt
Med FrankenPHP Worker Mode og Redis trenger du ikke caching-plugins. Serveren er rask nok til å generere hver side i sanntid.
Bildekomprimering og lazy loading
Bilder står ofte for mesteparten av lastetiden, selv når TTFB er lav. Noen enkle grep hjelper:
- Konverter til WebP eller AVIF (40–60 % mindre enn JPEG)
- Bruk responsive
srcset, så nettleseren henter riktig størrelse for enheten - Lazy-load alle bilder under folden
- Komprimer med kvalitet 75–85 % (forskjellen synes ikke, men filene blir mye mindre)
Et hero-bilde på 4 MB i JPEG er trolig den vanligste ytelsesfeilen vi ser. Som WebP i riktig størrelse blir det 200 KB med samme visuelle kvalitet.
Versjonskontroll og CI/CD
Ytelse er noe du må følge med på hele tiden. Nye plugins, innholdsendringer og WordPress-oppdateringer kan gjøre siden tregere igjen, og uten en pipeline som fanger det opp, faller ytelsen gradvis.
Med Lighthouse i CI/CD-pipelinen stoppes bygget hvis ytelsen faller under terskelen. Hver deploy blir testet automatisk, så tregere kode når ikke produksjon.
Når optimalisering ikke er nok
Noen ganger lønner det seg mer å erstatte WordPress enn å optimalisere det.
Er nettsiden en ren innholdsside uten nettbutikk eller tunge integrasjoner, er Sanity + Next.js et bedre utgangspunkt. Statisk generering gir lastetider under 100 ms uten caching, plugins eller PHP, og vedlikeholdet blir billigere fordi det ikke finnes plugins å holde oppdatert.
Har du derimot en fungerende WordPress-side med nettbutikk, integrasjoner og en redaksjon som kjenner verktøyet, er modernisering med FrankenPHP, WPFluent og CI/CD nesten alltid riktig. Ikke migrer bare for å migrere.
Oppsummering
WordPress-ytelse handler om fem ting:
- Server: FrankenPHP Worker Mode gir 90–99 % lavere TTFB. Flytt bort fra delt hosting.
- Cache: Redis Object Cache fjerner mesteparten av databasebelastningen og kjører som en egen tjeneste ved siden av WordPress.
- Plugins: Bruk færre og lettere plugins, og erstatt tunge plugins med egen kode der det gir mening.
- Frontend: Fjern Elementor, bruk Gutenberg med egne blokker og komprimer bildene.
- Pipeline: CI/CD med automatisk ytelsestesting stopper tregere kode før den når produksjon.
Gjør du alle fem, går du fra sekunder til millisekunder. Gjør du bare punkt 1 og 2, er du allerede foran de fleste WordPress-sidene vi analyserer.
Usikker på hvor du bør starte? Ta kontakt for en uforpliktende ytelsesanalyse, så forteller vi deg hva som gir mest effekt for pengene.


