Slik optimaliserte vi WordPress fra 4 sekunder til 180 ms

WordPress-ytelse handler ikke om å installere en caching-plugin og håpe. Det handler om arkitektur. Serveren. PHP-versjonen. Antall plugins. Databasen. Hostingmiljøet. Alt henger sammen, og én flaskehals ødelegger resten.

De fleste WordPress-sider vi ser bruker mellom 2 og 5 sekunder på å laste. Google anbefaler under 2,5 sekunder for Largest Contentful Paint. Hvert ekstra sekund øker fluktfrekvensen med opptil 32 %. Konsekvensen er konkret: du taper trafikk, rangeringer og konverteringer.

Men det trenger ikke være slik. Med riktig infrastruktur og noen strukturelle grep kan de fleste WordPress-sider komme under 200 millisekunder i total responstid. Her er hvordan.

WordPress i seg selv er ikke tregt. Det er summen av valgene rundt WordPress som skaper problemet. Noen av dem er tatt bevisst. De fleste er tatt av byrået som leverte nettsiden for tre år siden og aldri så seg tilbake.

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, uavhengig av om de faktisk brukes der.

Vi ser jevnlig nettsider med 25-40 aktive plugins. Tre av dem gjør det samme. Fem har ikke blitt oppdatert på over et år. Og to av dem har kjente sikkerhetshull som ingen har tatt tak i.

Elementor, WPBakery og Divi løser et reelt problem: de lar folk uten kodekunnskap lage nettsider. Problemet er ytelsesstraffen.

En typisk Elementor-side laster 300-500 KB ekstra JavaScript og CSS. På alle sider. Selv de som ikke bruker Elementor-funksjonalitet. Hvert widget-element genererer nestet HTML som gjør nettsiden tyngre enn nødvendig. Gutenberg med skreddersydde blokker er et bedre valg for ytelse.

Du deler server med hundrevis av andre nettsider. Når nabosiden har en trafikktopp, merker du det. PHP-versjonen er ofte utdatert (7.x er fortsatt vanlig i Norge). Og du har ingen kontroll over serverkonfigurasjonen.

Delt hosting er nok greit for en hobby-blogg. For en bedriftsnettside som skal generere leads og salg er det uforsvarlig.

WordPress sin databasemodell (EAV-mønsteret i wp_postmeta) er fleksibel, men treg i skala. Uten object cache må databasen gjøre det samme arbeidet for hver eneste besøkende. 100+ spørringer per sidevisning er vanlig på dårlig konfigurerte sider.

Tradisjonell WordPress-hosting bruker Apache eller Nginx med PHP-FPM. Hver gang noen besøker nettsiden, starter serveren PHP fra bunnen. Laster WordPress-kjernen, alle plugins, kobler til databasen, bygger siden og sender den til nettleseren. Og gjør det hele på nytt for neste besøkende.

FrankenPHP endrer dette fundamentalt. Det er en moderne applikasjonsserver bygget på Caddy. Worker Mode holder WordPress-applikasjonen i minnet, klar til å svare øyeblikkelig.

Forskjellen i praksis:

• Tradisjonell PHP-FPM: TTFB 200-400 ms (best case). Ofte 1-4 sekunder på delt hosting.
• FrankenPHP Worker Mode: TTFB under 30 ms. Konsekvent.

Det er jo ikke bare hastighet. FrankenPHP gir automatisk HTTPS via Let's Encrypt, HTTP/2 og HTTP/3 ut av boksen, og Early Hints som lar nettleseren begynne å laste ressurser før siden er ferdig generert.

Bare ved å bytte fra delt hosting til FrankenPHP ser vi typisk 90-99 % reduksjon i TTFB. Uten å endre en eneste linje kode.

Det nest viktigste grepet etter serverbyttet er Redis Object Cache. I stedet for at WordPress spør MySQL-databasen for hvert eneste sidebesøk, lagrer Redis resultatene i minnet.

En nettside med 127 databasespørringer per sidevisning kan reduseres til 8-10 (resten treffer cachen). Handlekurver og sesjoner hentes fra Redis i stedet for treg MySQL. Og køsystemer for e-post og ERP-synkronisering kjøres i bakgrunnen uten å påvirke ytelsen.

Redis er ikke en plugin. Det er en infrastrukturtjeneste som kjører ved siden av WordPress. En caching-plugin inne i WordPress er et kompromiss. Redis er løsningen.

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.

• Caching-plugins (unødvendig med Redis og FrankenPHP)
• SEO-plugins som dupliserer hverandre
• «Optimaliserings»-plugins som paradoksalt nok bremser ytelsen
• Inaktive plugins som fortsatt laster kode i bakgrunnen
• Kontaktskjema-plugins med 400 KB JavaScript for et skjema med tre felter

Vi bygger lette WPFluent-plugins med MVC-arkitektur. Kontaktskjema, nyhetsbrev-integrasjon, custom post types og lignende funksjonalitet som plugins gjør halvveis, men skreddersydd kode gjør presist. Typisk størrelse: 10-20 KB. Pluginene de erstatter: 1-3 MB.

Resultatet: JavaScript redusert fra over 1 MB til under 350 KB. CSS fra 600+ KB til under 150 KB.

Denne delen er mest tidkrevende, men gir stor effekt. Elementor-innhold migreres til Gutenberg med skreddersydde blokker som rendrer ren, semantisk HTML.

Skreddersydde Gutenberg-blokker gir:

• Ren HTML uten nestet shortcode-spaghetti
• Ingen Elementor JavaScript-rammeverk (300-500 KB spart)
• Bedre tilgjengelighet (WCAG) fordi HTML-strukturen er kontrollert
• Raskere redaktøropplevelse i wp-admin
• Enklere vedlikehold over tid

For nye prosjekter anbefaler vi å unngå Elementor helt. Og for prosjekter der WordPress ikke er nødvendig: Sanity + Next.js gir enda bedre ytelse uten plugin-problematikken.

Google måler brukeropplevelse gjennom tre metrikker:

LCP (Largest Contentful Paint): Hvor raskt hovedinnholdet vises. Google anbefaler under 2,5 sekunder. Etter optimalisering: typisk 0,8-1,2 sekunder.

INP (Interaction to Next Paint): Responstid ved interaksjon (klikk, scroll). Google anbefaler under 200 ms. Etter optimalisering: typisk 10-30 ms.

CLS (Cumulative Layout Shift): Visuell stabilitet. Google anbefaler under 0,1. Etter optimalisering: typisk 0,01.

Disse tre tallene påvirker rangeringene dine direkte. En nettside med røde Core Web Vitals taper trafikk til konkurrenter med grønne. Det er jo ikke en teori, det er bekreftet av Google.

Du trenger ikke gjette. Tre gratisverktøy gir deg svaret:

Google PageSpeed Insights: Gir både lab-data og feltdata (fra ekte brukere). Testen tar 30 sekunder og forteller deg nøyaktig hva som er galt.

Google Search Console: Viser Core Web Vitals for hele nettsiden over tid. Trenden er vel så viktig som enkelttall.

Query Monitor (WordPress-plugin): Viser databasespørringer, hooks, PHP-minnebruk og lastetider per komponent. Avslører hvilke plugins som faktisk bremser.

Kjør PageSpeed Insights nå. Hvis scoren er under 70, har du et problem som koster deg penger.

WP Super Cache, W3 Total Cache, LiteSpeed Cache. Alle lover raskere nettsider. Og de leverer. Delvis.

En caching-plugin lagrer ferdiggenererte HTML-sider og serverer dem direkte uten å kjøre PHP. Det er bedre enn ingenting. Men det er et plaster på et arkitekturproblem:

• Cachen må invalideres ved innholdsendringer (som ofte feiler)
• Innloggede brukere (handlekurv, minesider) får ikke cachet innhold
• Første besøk etter cache-tømming er like tregt som uten cache
• Pluginen legger til enda mer kompleksitet i en allerede kompleks stack

Med FrankenPHP Worker Mode og Redis trenger du ikke caching-plugins. Serveren er rask nok til å generere hver side i sanntid.

Bilder er ofte den største flaskehalsen i total lastetid, selv om TTFB er rask. Noen enkle grep:

• 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 % (usynlig forskjell, stor filbesparelse)

En 4 MB JPEG som hero-bilde er nok den vanligste ytelsestabben vi ser. Konvertert til WebP med riktig størrelse: 200 KB. Samme visuelle kvalitet.

Ytelsesoptimalisering er ikke et engangstiltak. Nye plugins, innholdsendringer og WordPress-oppdateringer kan introdusere regresjoner. Uten en pipeline som fanger det opp, degraderes ytelsen gradvis.

CI/CD med Lighthouse i pipelinen betyr at bygget blokkeres hvis ytelsen faller under terskelen. Automatisert ytelsestesting ved hver deploy. Ingen regresjoner slipper gjennom til produksjon.

Noen ganger er svaret ikke å optimalisere WordPress, men å erstatte det.

Hvis nettsiden er en ren innholdsside uten nettbutikk eller tunge integrasjoner, er Sanity + Next.js et bedre utgangspunkt. Statisk generering gir sub-100ms lastetider uten caching, plugins eller PHP. Og vedlikeholdskostnadene er lavere fordi det ikke er noen plugin-avhengigheter å holde oppdatert.

Vi bygger Sanity-nettsider fra 15 000 kr med vedlikehold fra 2 500 kr/mnd.

Men har du en fungerende WordPress-side med nettbutikk, integrasjoner og en redaksjon som kjenner verktøyet? Da er modernisering med FrankenPHP, WPFluent og CI/CD nesten alltid riktig. Ikke migrer for migreringens skyld.

WordPress-ytelse handler om fem ting:

1. Server: FrankenPHP Worker Mode gir 90-99 % reduksjon i TTFB. Bytt bort fra delt hosting.
2. Cache: Redis Object Cache fjerner mesteparten av databasebelastningen. Ikke en plugin, en infrastrukturtjeneste.
3. Plugins: Færre og lettere. Erstatt tunge plugins med skreddersydd kode der det gir mening.
4. Frontend: Fjern Elementor. Bruk Gutenberg med skreddersydde blokker. Komprimer bilder.
5. Pipeline: CI/CD med automatisert ytelsestesting. Ingen regresjoner.

Gjør du alle fem, går du fra sekunder til millisekunder. Gjør du bare punkt 1 og 2, er du allerede foran 95 % av norske WordPress-sider.

Usikker på hvor du bør starte? Ta kontakt for en uforpliktende ytelsesanalyse. Vi forteller deg hva som gir mest effekt for pengene.