WordPress-hastighetsoptimalisering, komplett WPO-guide | WPPoland

Mariusz Szatkowski

Omfattende WordPress-optimalisering, hvordan gjøre siden raskere? (WPO)

Sist verifisert: 12. oktober 2026

17 min lesetid

Guide

500+ WP-prosjekter

“WordPress-en min er treg”. Denne setningen har jeg hørt tusenvis av ganger. Og vanligvis er svaret ikke “installer enda en plugin”, men “rydd opp det du har”. Ytelsesoptimalisering (WPO, Web Performance Optimization) er en holistisk prosess. Det holder ikke å komprimere bilder hvis databasen “hoster” ved hver spørring.

Her er et komplett WordPress-optimaliseringskart, fra grunnleggende til avanserte teknikker. WPO er en systematisk disiplin i flere lag, som berører hosting, kode, ressurser og hvordan nettleseren oppfører seg. Guiden går gjennom hvert lag, fra serverkonfigurasjon til det siste som tegnes på skjermen, med reelle tall og kode du kan ta i bruk i dag.

#Hvordan hastigheten på en WordPress-side påvirker konverteringer

Hastighet er ikke et forfengelighetstall. Googles egen forskning viser at når lastetiden øker fra 1 til 3 sekunder, øker sannsynligheten for at besøkende forlater siden med 32 %. Ved 5 sekunder stiger den til 90 %. For netthandel målte Amazon at hver ekstra 100 ms forsinkelse kostet dem 1 % av salget (Greg Linden, Amazon, 2006).

Core Web Vitals ble et bekreftet rangeringssignal hos Google i 2021. Sider som klarer alle tre tersklene (LCP under 2,5 sekunder, CLS under 0,1 og INP under 200 ms) får et løft i mobilsøk. Ifølge data fra Chrome User Experience Report (CrUX) fra slutten av 2025 består bare 43 % av WordPress-domenene alle tre Core Web Vitals på mobil. Mer enn halvparten av WordPress-sidene lar altså rangeringspotensial ligge ubrukt.

Deloittes studie “Milliseconds Make Millions” fant at en forbedring på 0,1 sekund i hastigheten på mobil økte konverteringsraten med 8,4 % for netthandel og 10,1 % for reiselivssider. Regner du på din egen trafikk, blir kostnaden ved en treg side konkret. En WooCommerce-butikk med €50 000 i månedlig omsetning kan tape €4 000-€5 000 hver måned på en side som laster på 4 sekunder i stedet for 2.

Husk: En rask side er ikke et mål i seg selv. Det er et verktøy for høyere konvertering og bedre SEO. Hver 100ms forsinkelse koster deg tapte kunder.

Hastighetsoptimalisering er ikke valgfritt. Det er den tekniske investeringen som gir høyest avkastning.

#Hvordan måle hastigheten på en WordPress-side

Start aldri optimaliseringen uten et utgangspunkt. Du trenger data, ikke gjetning.

PageSpeed Insights (PSI) gir deg både laboratoriedata (Lighthouse) og feltdata (CrUX). Laboratoriedata er nyttige for feilsøking, men det er feltdataene, samlet inn fra ekte Chrome-brukere over 28 dager, som Google faktisk bruker i rangeringen. Sjekk alltid “Origin Summary” for å se hvordan hele domenet presterer, ikke bare enkeltsider.

WebPageTest (webpagetest.org) tilbyr fossefallsdiagrammer, filmstripevisning og testing i flere steg. Kjør testene fra et sted nær målgruppen din. Bruk “repeat view” for å se hvordan caching påvirker senere lastinger. Fossefallsdiagrammet er det beste enkeltverktøyet for å finne trege tredjepartsskript og ressurser som blokkerer rendering.

Performance-fanen i Chrome DevTools lar deg ta opp en hel sidelasting og inspisere hver frame, hvert layoutskift og hver lange oppgave. Bruk “Coverage”-fanen (Ctrl+Shift+P, skriv så “Coverage”) for å finne ubrukt CSS og JavaScript. Slik finner du kandidater som kan fjernes eller utsettes.

CrUX Vis (cruxvis.withgoogle.com) gir deg historiske trenddata fra CrUX History API. Google har faset ut det eldre CrUX Dashboard i Looker Studio til fordel for dette verktøyet. Følg Core Web Vitals over tid, for én enkelt score sier lite uten kontekst. Sett opp automatisk overvåking med verktøy som SpeedCurve eller Calibre, så fanger du opp regresjoner før de når produksjon.

Noter utgangsverdiene dine: TTFB, LCP, CLS, INP, total sidevekt og antall forespørsler. Uten disse tallene kan du ikke bevise at optimaliseringene virket.

#Hvilke hosting- og DNS-grunnlag gjør WordPress raskere

Hvis serveren din svarer sakte (TTFB > 600ms), hjelper ingen plugin.

PHP-versjon: PHP 8.3 eller nyere, slik WordPress.org anbefaler.
Database: MySQL 8.0 eller nyere eller MariaDB 10.11 eller nyere.
Protokoll: HTTP/2 eller HTTP/3 (QUIC) er et must. Lar nettleseren laste ned mange filer samtidig over én tilkobling.

Time to First Byte (TTFB) bør ligge under 200 ms for sider fra cache og under 600 ms for dynamiske svar.

#Hvilken PHP-versjon er raskest for WordPress

WordPress.org anbefaler PHP 8.3 eller nyere. PHP 8.1 og eldre grener får ikke lenger sikkerhetsoppdateringer, så den som blir stående der, taper både fart og sikkerhet. Hvor mye raskere en bestemt side blir etter oppgraderingen, avhenger av tema, utvidelser og caching. Mål derfor TTFB før og etter byttet i stedet for å stole på en fast faktor. Sjekk PHP-versjonen med phpinfo() eller under Verktøy, Nettstedshelse, Info, og test oppgraderingen på staging først: gamle utvidelser er den vanlige kilden til fatale feil etter et PHP-hopp.

#Hvordan konfigurere OPcache for WordPress

OPcache kompilerer PHP-skript til bytekode og lagrer dem i delt minne. Slå det på og juster disse verdiene i php.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128M

Innstillingen jit=1255 slår på tracing JIT i PHP 8.x, noe som hjelper CPU-tunge operasjoner som sidebygging.

#Objektcache med Redis eller Memcached

WordPress lagrer som standard transients, spørringsresultater og sesjonsdata i tabellen wp_options. Redis eller Memcached flytter dette til minnet og kutter antall databasespørringer kraftig. En typisk WordPress-side som sender 50-80 databasespørringer kan komme ned i 5-10 med en vedvarende objektcache. Installer PHP-utvidelsen redis, legg til WP_REDIS_HOST i wp-config.php, og bruk en drop-in som object-cache.php fra pluginen Redis Object Cache.

#HTTP/2, HTTP/3 og CDN for WordPress

Multipleksing i HTTP/2 lar nettleseren laste ned dusinvis av ressurser over én tilkobling, og fjerner det gamle problemet med head-of-line blocking i HTTP/1.1. HTTP/3 (QUIC) går lenger, med tilkobling uten ekstra rundtur og bedre håndtering av pakketap. Cloudflare, Fastly og AWS CloudFront støtter alle HTTP/3 i dag.

CDN (Content Delivery Network): Hvis du har trafikk fra hele verden, bruk Cloudflare for å levere filer fra serveren nærmest brukeren. For en side med internasjonal trafikk er CDN et krav. Legg de statiske ressursene (bilder, CSS, JS, fonter) på edge-servere. For WordPress bør du sette opp CDN-en til å cache hele HTML-sider for besøkende som ikke er innlogget. Det alene kan få TTFB under 50 ms over hele verden.

#Hvorfor delt hosting gjør WordPress tregt

Delt hosting er den største flaskehalsen vi ser hos wppoland.com. Overbelastede servere, utdaterte PHP-versjoner og manglende støtte for objektcache gjør ytelsesoptimalisering nesten umulig. Flytt til administrert WordPress-hosting eller en VPS med riktig konfigurert NGINX eller LiteSpeed.

#Hvordan optimalisere WordPress-backend og database

Her skjer “magien” som du ikke ser, men føler når du jobber i admin-panelet. WordPress-databaser samler søppel over tid. Innleggsrevisjoner, foreldreløse metadata, utløpte transients og spamkommentarer blåser opp tabellene og gjør spørringene tregere.

Revisjoner: WordPress beholder som standard uendelige versjoner av hvert innlegg. Hvis du redigerer et innlegg 100 ganger, har du 100 kopier i databasen. Begrens dette i wp-config.php: define( 'WP_POST_REVISIONS', 5 );
Transients: Rens gamle “transients” (midlertidige data) fra databasen. Plugins etterlater ofte søppel der.
Heartbeat API: Begrens WordPress-”pulsen” (autolagring, admin-varsler) med “Heartbeat Control” plugin for å redusere server-CPU-belastning.

#Hvordan rydde i revisjoner, transients og autoload

Sammen med tømming av papirkurven etter 14 dager ser oppsettet i wp-config.php slik ut:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );

Utløpte transients hoper seg opp når plugins ikke rydder etter seg. Kjør denne SQL-spørringen for å se hvor mye autoloadede innstillinger du drar med deg:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Er resultatet over 1 MB, har du et problem. Finn de tyngste radene med:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Vanlige syndere er innstillinger fra plugins som ikke lenger er i bruk, serialiserte widgetdata og oppblåste temainnstillinger. Fjern det du ikke trenger.

#Hvordan finne trege databasespørringer

Bruk pluginen Query Monitor for å finne trege databasespørringer under sidelasting. Se etter spørringer uten riktige indekser, spørringer som kjøres inne i løkker (N+1-problemet) og spørringer som henter data som aldri vises. For egne spørringer bør du alltid bruke WP_Query med konkrete fields, posts_per_page og no_found_rows => true når du ikke trenger paginering:

$query = new WP_Query( [
    'post_type'      => 'product',
    'posts_per_page' => 10,
    'no_found_rows'  => true,
    'fields'         => 'ids',
] );

Parameteren no_found_rows hopper over det kostbare kallet SQL_CALC_FOUND_ROWS, noe som kan halvere spørretiden på store tabeller.

#WP-Optimize eller manuell databaseopprydding

WP-Optimize er en solid plugin for planlagt opprydding av revisjoner, kladder, innlegg i papirkurven, spamkommentarer og transients. På sider der du trenger full kontroll, kan du kombinere manuell SQL-opprydding med planlagte hendelser i wp-cron. Det viktigste er jevnlighet: kjør databasevedlikehold hver uke, ikke én gang i året når noe går i stykker.

#Hvordan optimalisere bilder i WordPress

Bilder er den største enkeltposten i sidevekten: Web Almanac 2025 anslår dem til rundt 37 % av vekten på en median mobilside. Å optimalisere dem gir den største enkeltforbedringen i lastetid.

#WebP eller AVIF for bilder i WordPress

WebP gir 25-35 % mindre filer enn JPEG ved samme visuelle kvalitet. AVIF går lenger, 30-50 % mindre enn WebP for fotografisk innhold. Nettleserstøtten for WebP er nå universell (over 98 % globalt). AVIF-støtten ligger rundt 92 % og stiger.

Reell sammenligning av filstørrelse fra et wppoland.com-prosjekt:

Format	Filstørrelse	Kvalitet
JPEG (original)	285 KB	Utgangspunkt
WebP	192 KB	Visuelt identisk
AVIF	128 KB	Visuelt identisk

Det er en reduksjon på 55 % bare ved å bytte format. Gang det med 40 bilder på en side, og du sparer megabyte.

#Responsive bilder og lazy loading

WordPress lager flere bildestørrelser ved opplasting. Bruk attributtene srcset og sizes slik at nettleseren laster ned bildet i riktig størrelse. Siden WordPress 5.5 legges loading="lazy" automatisk til bilder. For hero-bilder over folden bør du fjerne lazy loading, ellers forsinkes LCP:

add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
    if ( str_contains( $image, 'hero-image' ) ) {
        return false; // Slå av lazy loading for hero-bildet
    }
    return $value;
}, 10, 3 );

#Bilde-CDN for WordPress

Tjenester som Cloudflare Images, imgix og Bunny Optimizer kan bearbeide bilder fortløpende: endre størrelse, konvertere til WebP/AVIF og fjerne metadata på edge. Da slipper du å generere dusinvis av miniatyrstørrelser på serveren. Legg til fetchpriority="high" på LCP-bildet, så prioriterer nettleseren nedlastingen:

<img src="hero.webp" fetchpriority="high" width="1200" height="630"
     alt="WordPress performance optimization dashboard">

#Hvilke utviklertriks gjør WordPress raskere

Blokker hotlinking: Ikke la andre sider stjele båndbredden din ved å vise bildene dine på sine sider.

#Hvordan optimalisere WordPress-frontend (det brukeren ser)

Her kjemper vi for PageSpeed Insights score og Core Web Vitals.

Minifisering: Fjern unødvendige mellomrom og kommentarer fra CSS/JS/HTML. (Plugins som Autoptimize eller WP Rocket gjør dette).
Defer JS: Skyv JavaScript-lasting til slutten (etter HTML laster) så det ikke blokkerer siderendering.

Ressurser som blokkerer rendering er den vanligste årsaken til dårlig LCP. Nettleseren kan ikke tegne piksler før den har tolket all synkron CSS og JavaScript i <head>.

#Hvordan laste ikke-kritisk CSS asynkront

Flytt ikke-kritisk CSS ut av <head> og last den asynkront:

<link rel="preload" href="/css/below-fold.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/below-fold.css"></noscript>

For JavaScript bruker du defer for skript som trenger tilgang til DOM, og async for uavhengige skript som analyse:

add_filter( 'script_loader_tag', function( $tag, $handle ) {
    $defer_scripts = [ 'comment-reply', 'contact-form', 'analytics' ];
    if ( in_array( $handle, $defer_scripts, true ) ) {
        return str_replace( ' src=', ' defer src=', $tag );
    }
    return $tag;
}, 10, 2 );

#Hvordan legge inn kritisk CSS inline

Trekk ut CSS-en som trengs for å vise innholdet over folden, og legg den direkte i <head>. Verktøy som Critical (av Addy Osmani) eller generatoren for kritisk CSS i WP Rocket gjør dette automatisk. Den inline CSS-en bør være under 14 KB (størrelsen på det første TCP-overbelastningsvinduet), slik at nettleseren kan vise meningsfullt innhold allerede på det første svaret fra serveren.

#Hvordan fjerne ubrukt CSS med PurgeCSS

Bruk PurgeCSS eller UnCSS til å analysere de ferdige sidene og fjerne ubrukte CSS-regler. En typisk WordPress-side med sidebygger laster 300-500 KB CSS, der 70-80 % er ubrukt på en gitt side. Etter rensing:

# Eksempel på PurgeCSS-konfigurasjon
purgecss --css ./style.css \
         --content ./**/*.php ./**/*.html \
         --output ./style.purged.css

Vi ser jevnlig at CSS-filer krymper fra 400 KB til under 60 KB etter skikkelig tree shaking. Kombiner dette med minifisering (cssnano) og Brotli-komprimering for størst mulig besparelse.

#Hvordan fjerne skript og stiler fra plugins der de ikke trengs

Mange plugins laster ressursene sine på hver side, også der de ikke trengs. Fjern dem fra køen med en betingelse:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7-css' );
        wp_dequeue_script( 'contact-form-7-js' );
    }
}, 100 );

#WordPress-cachelag fra CDN til nettleser

Caching er den mest effektive ytelsesteknikken, fordi den fjerner arbeid helt. En god cachestrategi virker i lag.

#Sidecache

Lagre ferdig generert HTML, slik at WordPress og PHP ikke kjøres ved hver forespørsel. NGINX FastCGI cache, LiteSpeed cache eller plugin-løsninger som WP Super Cache og WP Rocket leverer statisk HTML til besøkende som ikke er innlogget. En side som tar 800 ms å generere dynamisk, kan leveres på 10 ms fra cache.

#Objektcache for innloggede brukere

Redis eller Memcached lagrer resultater fra databasespørringer, API-kall og beregnede verdier i minnet. Den vedvarende objektcachen er det cachelaget som betyr mest for innloggede brukere og dynamiske sider som ikke kan sidecaches fullt ut.

#Cache-Control-headere for statiske ressurser

Sett riktige Cache-Control-headere for statiske ressurser. Uforanderlige ressurser (versjonerte CSS/JS-filer) bør caches aggressivt:

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

For HTML-sider bruker du kortere cachetid eller stale-while-revalidate for å balansere ferskhet og hastighet:

Cache-Control: public, max-age=300, stale-while-revalidate=86400

#CDN-cache

CDN-en bør cache statiske ressurser på edge-lokasjoner over hele verden. Sett opp tømming av cachen slik at den utløses når innhold oppdateres. Cloudflares APO (Automatic Platform Optimization) for WordPress cacher hele HTML-sider på edge og tømmer dem automatisk når du publiserer eller oppdaterer innhold.

Lagene virker i denne rekkefølgen: CDN-ens edge-cache, deretter sidecachen på serveren, deretter objektcachen og til slutt nettleserens cache. Hvert lag fanger opp det forrige lag slipper gjennom.

#Hvordan optimalisere lasting av webfonter i WordPress

Webfonter stjeler ytelse uten at du merker det. En enkelt forespørsel til Google Fonts kan legge 200-500 ms til den kritiske renderingsbanen på grunn av DNS-oppslag, tilkobling og nedlasting fra en tredjepartskilde.

Fonter: Last Google-fonter lokalt eller bruk font-display: swap så teksten er synlig umiddelbart, før den fine fonten laster.

#Hvordan hoste fonter selv i WordPress

Last ned fontfilene og lever dem fra ditt eget domene. Da slipper du kostnaden ved en tredjepartstilkobling, og CDN-en kan cache dem. Bruk bare formatet woff2: det har over 99 % nettleserstøtte og gir best komprimering.

@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var.woff2') format('woff2');
    font-weight: 100 900;
    font-display: swap;
    unicode-range: U+0000-024F; /* Latinsk delsett */
}

#Hvordan bruke font-display swap og forhåndslaste fonter

Deklarasjonen font-display: swap ber nettleseren vise teksten med en gang i en reservefont, og bytte til den egne fonten når den er lastet. Det hindrer usynlig tekst (FOIT) og forbedrer LCP.

Forhåndslast hovedfonten slik at nedlastingen prioriteres:

<link rel="preload" href="/fonts/inter-var.woff2" as="font"
      type="font/woff2" crossorigin>

#Variable fonter og delsett

Variable fonter inneholder flere vekter og stiler i én fil. I stedet for å laste egne filer for regular (400), medium (500), semibold (600) og bold (700), dekker én variabel fontfil hele spennet. Den variable fonten Inter er 97 KB i woff2, mot 4 separate statiske filer på til sammen 180 KB.

Lag delsett av fontene slik at de bare inneholder tegnområdene du trenger. Et rent latinsk delsett kan redusere filstørrelsen med 40-60 % sammenlignet med full Unicode-dekning. Verktøy som glyphhanger eller parameteren &text= i Google Fonts API gjør dette enkelt.

#Hvordan fikse LCP, CLS og INP i WordPress

Googles Core Web Vitals er de tre måltallene som direkte påvirker rangeringen din i søk. Du må forstå hva som får hvert av dem til å feile for å kunne optimalisere målrettet.

#Hvordan forbedre LCP

LCP måler hvor raskt det største synlige elementet (vanligvis et hero-bilde eller en overskrift) blir vist. Målet er under 2,5 sekunder.

Vanlige årsaker til dårlig LCP:

Treg serverrespons (høy TTFB)
CSS og JavaScript som blokkerer rendering
Uoptimaliserte hero-bilder uten fetchpriority="high"
LCP-bilder med lazy loading (fjern loading="lazy" fra bilder over folden)
Webfonter som blokkerer visning av tekst

Fiks LCP ved å senke TTFB med caching, legge kritisk CSS inline, forhåndslaste LCP-bildet og bruke fetchpriority="high" på hero-elementet.

#Hvordan redusere CLS

CLS måler visuell stabilitet, altså hvor mye layouten flytter seg uventet under lasting. Målet er under 0,1.

Vanlige årsaker til dårlig CLS:

Bilder og iframes uten eksplisitte attributter width og height
Innhold som settes inn dynamisk (annonser, innbygginger, cookie-bannere)
Webfonter som får teksten til å flyte om (FOUT)
CSS som lastes sent og endrer størrelsen på elementer

Sett alltid dimensjoner på medieelementer. Bruk aspect-ratio i CSS for responsive beholdere. Reserver plass til annonser og dynamisk innhold med plassholdere med min-height.

#Hvordan forbedre INP

INP erstattet FID i mars 2024 og måler responsivitet gjennom hele sidens levetid, ikke bare ved første interaksjon. Målet er under 200 ms.

Vanlige årsaker til dårlig INP:

Lange JavaScript-oppgaver som blokkerer hovedtråden
Tunge hendelseshåndterere for klikk, rulling eller inndata
For stor DOM (over 1500 noder)
Tredjepartsskript som konkurrerer om tid på hovedtråden

Del lange oppgaver opp i mindre biter med requestIdleCallback eller scheduler.yield(). Bruk event delegation i stedet for å feste lyttere på hundrevis av enkeltelementer. Gå hardt gjennom tredjepartsskriptene: hvert skript du fjerner, gir tid tilbake på hovedtråden.

// Del opp lange oppgaver med yield-punkter
async function processItems(items) {
    for (const item of items) {
        processItem(item);
        // Gi kontrollen tilbake til nettleseren mellom elementene
        await scheduler.yield();
    }
}

#Sjekkliste for hastighetsoptimalisering av WordPress

Bruk denne sjekklisten steg for steg i hvert WordPress-prosjekt. Rekkefølgen betyr noe: start på serveren og jobb deg utover mot nettleseren.

#Serverlaget

Oppgrader til PHP 8.3+ med OPcache og JIT slått på
Konfigurer MySQL/MariaDB med riktig størrelse på buffer pool
Slå på HTTP/2 (eller HTTP/3 hvis det støttes)
Sett opp Redis eller Memcached som objektcache
Flytt fra delt hosting til administrert hosting eller VPS

#Databaselaget

Begrens innleggsrevisjoner til 5
Slett utløpte transients og foreldreløse metadata
Gå gjennom autoloadede innstillinger (hold dem under 800 KB)
Legg til indekser for egne meta-spørringer

#Ressurslaget

Konverter bilder til WebP/AVIF med riktige reserveløsninger
Legg til width, height og fetchpriority="high" på LCP-bilder
Fjern loading="lazy" fra bilder over folden
Host fonter selv i woff2-format med font-display: swap
Forhåndslast kritiske fonter og LCP-bilder

#Kodelaget

Legg kritisk CSS inline (under 14 KB)
Bruk defer eller async på all JavaScript som ikke er kritisk
Fjern ubrukt CSS/JS fra plugins på sider der de ikke trengs
Fjern ubrukt CSS med PurgeCSS
Minifiser og komprimer alle ressurser med Brotli

#Cachelaget

Slå på helsidecache for besøkende som ikke er innlogget
Konfigurer CDN med riktige cache-headere
Sett Cache-Control: immutable for versjonerte statiske ressurser
Bruk stale-while-revalidate for HTML-svar

#Overvåking

Følg trender i feltdata over 28 dager i CrUX Vis
Overvåk Core Web Vitals i Search Console
Kjør Lighthouse CI i deploy-prosessen
Sett ytelsesbudsjetter (sidevekt, antall forespørsler, LCP-mål)

#Hvordan holde WordPress raskt over tid

Ytelsesoptimalisering er ikke et engangsprosjekt. Det er en løpende praksis. Hver ny plugin, hver temaoppdatering og hvert tredjepartsskript kan gi en regresjon. Mål kontinuerlig, optimaliser systematisk og behandle hastighet som en sentral del av produktet, ikke som noe du tar til slutt.

Cache, CDN og bildehåndtering gir mest når de settes opp i riktig rekkefølge og måles etterpå. Vil du ha en WPO-gjennomgang av din egen side, se WordPress-utvikling og ytelsesarbeid.