WordPress-ytelse i 2026: Core Web Vitals, cache og bildeoptimalisering

I 2026 handler “hastighet” ikke bare om lastetid. Det handler om Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), og å holde serverkostnadene lave ved trafikktopper.

Mange “hastighetsguider” forteller deg å installere en plugin og be. Denne guiden er annerledes. Den er et kart over hele stacken: tersklene Google måler siden med, datakildene, serverlaget, databasen, frontend, caching og det WordPress allerede gjør selv i kjernen. Detaljerte instruksjoner for enkelttemaer finnes i egne artikler, som vi lenker til der de hører hjemme.

#Hva er terskelverdiene for Core Web Vitals i 2026

Tersklene publiseres av Chrome-teamet på web.dev og har ikke endret seg siden INP erstattet FID. Ifølge siden Web Vitals ble INP en stabil Core Web Vitals-metrikk i 2024. Grensene for “god” og “dårlig” er beskrevet i artikkelen Defining the Core Web Vitals metrics thresholds:

To detaljer endrer hvordan tallene skal leses. Den første: vurderingen beregnes på 75. persentil av sidevisningene, separat for mobil og desktop. En side består altså først når minst tre av fire besøk ligger innenfor grensen. Ifølge web.dev er 75. persentil “mindre utsatt for påvirkning fra ekstremverdier” (egen oversettelse, kilde: web.dev, Defining the Core Web Vitals metrics thresholds). Den andre: mobil og desktop er to separate resultater. En nettbutikk kan ha grønn desktop og rød mobil, og Google indekserer mobilversjonen. Dette utdypes i artikkelen om mobile-first-ytelse.

Web.dev presiserer også at stabile metrikker “ikke nødvendigvis er permanente” og kan erstattes. Det skjedde med FID. Derfor lønner det seg å optimalisere årsakene (treg server, tung JavaScript, bilder uten dimensjoner) heller enn et bestemt tall.

#Påvirker Core Web Vitals rangeringen i Google

Ja, men svakere enn tilbud om “100/100 i PageSpeed” antyder. Dokumentasjonen fra Google Search Central om page experience sier det rett ut:

“Core Web Vitals brukes av rangeringssystemene våre.”

Google Search Central, Understanding page experience in Google Search results (egen oversettelse)

I det samme dokumentet legger Google til at gode resultater i rapporten “ikke garanterer at sidene rangeres øverst i søkeresultatene”, og at søkemotoren “alltid prøver å vise det mest relevante innholdet, selv om sideopplevelsen er svakere” (egen oversettelse). Det finnes heller ikke ett enkelt “page experience”-signal.

Den praktiske konklusjonen: ytelse løfter ikke svakt innhold, men blant flere like relevante resultater kan den avgjøre rekkefølgen. Den største gevinsten av hastighet ser man vanligvis i brukeratferd: i handlekurven, i filtrene, i kontaktskjemaet.

#Hvor skal dataene komme fra: lab eller felt

Lighthouse og “Diagnostikk”-delen i PageSpeed Insights er laboratoriedata. Dokumentasjonen for PageSpeed Insights beskriver forskjellen slik: labdata er nyttige til feilsøking fordi de samles inn i et kontrollert miljø, mens feltdata gjenspeiler den faktiske opplevelsen til brukerne (egen oversettelse).

Feltdata i PSI kommer fra Chrome User Experience Report (CrUX) og dekker de foregående 28 dagene. Det gir tre konsekvenser for WordPress:

• En endring som rulles ut i dag, vises fullt ut i feltdata først etter omtrent fire uker.
• En ny eller lite besøkt underside har ofte ingen egne data. PSI viser da data for hele domenet (origin), og mangler også de, vises ingen brukerdata i det hele tatt.
• En Lighthouse-score fra en bærbar PC på rask linje sier ingenting om 75. persentil av brukerne på mobil.

Derfor står måling av Real User Metrics (RUM) på sjekklisten til slutt. CrUX gir et bilde med forsinkelse, mens egen RUM (biblioteket web-vitals eller et analyseverktøy) viser effekten av en endring raskere og per mal.

#Hvordan bygge server-stacken for rask WordPress

Du kan ikke fikse en treg server med en plugin. Hvis din Time To First Byte (TTFB) er > 500ms, vil ingen mengde CSS-minifisering redde deg. TTFB er ikke en av de tre Core Web Vitals-metrikkene, men den inngår i LCP: nettleseren kan ikke tegne noe før den har fått HTML.

#1. PHP 8.3 eller nyere

Sørg for at du kjører PHP 8.3 eller 8.4. Siden med WordPress-krav anbefaler PHP versjon 8.3 eller høyere, og MySQL 8.0+ eller MariaDB 10.11+.

• Handling: Sjekk php -v. Hvis du ser 7.4, oppdater umiddelbart.

JIT (Just-In-Time)-kompilatoren introdusert i PHP 8.0 kompilerer deler av PHP-kode direkte til maskinkode, og går utenom Zend VM for CPU-intensive oppgaver. For en typisk WordPress-side er dette likevel ikke hovedgevinsten. JIT-RFC-en oppgir at JIT gjorde bench.php over dobbelt så rask (0,140 s mot 0,320 s), men at den “ikke ser ut til å forbedre virkelige applikasjoner som WordPress nevneverdig” (egen oversettelse): 326 forespørsler per sekund med JIT mot 315 uten. WordPress bruker mesteparten av tiden på databasespørringer og I/O, så en oppdatert PHP-versjon og aktivert OPcache betyr mer.

#2. Nginx i stedet for Apache

Apache er flott for kompatibilitet (.htaccess), men Nginx håndterer samtidighet bedre. Nginx bruker en hendelsesdrevet arkitektur. Ifølge nginx.org bruker 10 000 inaktive keep-alive-tilkoblinger omtrent 2,5 MB minne, mens Apache i klassiske moduser (prefork) håndterer hver tilkobling med en egen prosess eller tråd.

#3. Object cache (Redis/Valkey)

Dette er den største enkelte “opplåsningen” for dynamiske nettsteder (WooCommerce). WordPress spør naturlig databasen om alt (alternativer, brukere, innleggsmeta). Redis lagrer disse spørringsresultatene i RAM.

• Uten Redis: objekter som caches under én forespørsel forsvinner når den er ferdig, så hver sidevisning spør databasen på nytt om de samme alternativene og metadataene.
• Med Redis: objektcachen overlever mellom forespørsler. Databasen får bare spørringer som ennå ikke ligger i cachen, og dem WordPress ikke cacher.
• Konfigurasjon: Den mest brukte drop-in-en er pluginen Redis Object Cache av Till Krüss (over 500 000 aktive installasjoner), som fungerer med klientene PhpRedis, Predis og Relay. Tilkoblingsstatus sjekker du med wp redis status.

#Hvordan optimalisere frontend og Core Web Vitals

Googles Core Web Vitals er referansepunktet for hele frontend. I 2026 er metrikken flest WordPress-nettsteder sliter med INP (Interaction to Next Paint).

#Hvordan forbedre INP i WordPress

INP måler hvor raskt nettleseren reagerer etter at en bruker klikker, trykker eller taster. Web.dev deler i artikkelen Optimize INP hver interaksjon i tre faser: inndataforsinkelse (fra brukerens handling til hendelsesbehandlingen starter), behandlingstid (kjøring av callbacks) og presentasjonsforsinkelse (tiden til neste ramme tegnes). Hver fase har en annen årsak og en annen løsning. Hvis hovedtråden er blokkert av JavaScript-kjøring, lider din INP.

• Synderen: Tunge sidebyggere, uoptimaliserte tredjepartsskripter (chat-widgets, sporingspiksler).
• Løsningen:
  1. Vik for hovedtråden (yield to main thread): Utsett (defer) ikke-vesentlig JS og del lange oppgaver opp i mindre.
  2. Web Workers: Flytt tung logikk (f.eks. komplekse beregninger) ut av hovedtråden.
  3. Debouncing: Ikke send en PHP-søkeforespørsel ved hvert tastetrykk; vent til brukeren slutter å skrive i 300ms.

Web.dev påpeker også at rendring vanligvis går raskt med en liten DOM, mens et stort DOM-tre krever mer arbeid. Tunge sidebyggere rammer derfor INP to ganger: med skript og med antall noder. Detaljene, fra scheduler.yield() til måling i Chrome DevTools, står i guiden til optimalisering av INP. Tredjepartsskript er et eget tema, dekket i artikkelen om å redusere påvirkning fra tredjepartsskripter.

#Nye bildeformater (AVIF vs WEBP)

AVIF er i 2026 det best komprimerte formatet WordPress støtter i kjernen, og WebP er fortsatt et fornuftig reservealternativ. Ifølge kunngjøringen fra WordPress-teamet kan AVIF-bilder være opptil 50 % mindre enn JPEG med samme kvalitet.

• WordPress 6.5+ støtter AVIF naturlig, så lenge bildebiblioteket på serveren (Imagick eller GD) har AVIF-støtte. Det ser du under Verktøy, Nettstedshelse, Info, seksjonen “Mediehåndtering”.
• Handling: Sørg for at din bildeoptimaliserings-pipeline (eller CDN) lager AVIF-versjoner automatisk. I WordPress selv brukes filteret image_editor_output_format, som lar deg lagre miniatyrer av opplastede JPEG-filer som AVIF.

#Hva optimaliserer WordPress selv i kjernen

En del av arbeidet som plugins gjorde for noen år siden, gjør kjernen nå. Det er verdt å vite hva som allerede virker før man installerer enda en plugin som gjør det samme en gang til.

Prioritet for LCP-bildet (WordPress 6.3). Ifølge notatet fra WordPress-teamet legger kjernen til fetchpriority="high" på bildet den anser som det mest sannsynlige LCP-elementet. Bildet må være i visningsområdet og ha minst 50 000 piksler i areal (bredde ganger høyde). Det samme bildet får aldri samtidig loading="lazy". Standardverdien for filteret wp_omit_loading_attr_threshold økte fra 1 til 3, så de første bildene på siden lastes ikke lat. Et tema eller en plugin som tvinger lazy loading på alt, ødelegger denne mekanismen og forsinker LCP.

AVIF (WordPress 6.5). Beskrevet ovenfor: opplasting av AVIF-filer og konvertering via image_editor_output_format.

Autoload av alternativer (WordPress 6.6). Beskrevet nedenfor i databasedelen: store alternativer uten eksplisitt autoload-flagg lastes ikke lenger ved hver forespørsel.

Speculative loading (WordPress 6.8). Ifølge utviklernotatet slår kjernen som standard på spekulativ lasting i frontend på alle nettsteder, unntatt for innloggede brukere og nettsteder uten pene permalenker. Den bruker prefetch (ikke prerender) med iverhet conservative, altså starter hentingen når brukeren begynner å klikke på en lenke. Adresser med spørreparametere utelates automatisk. Speculation Rules API støttes av Chrome, Edge og Opera, andre nettlesere ignorerer det. Konfigurasjonen endres med filteret wp_speculation_rules_configuration (returnerer du null, slås funksjonen av for forespørselen), og stier utelates med wp_speculation_rules_href_exclude_paths. En enkelt blokk kan utelates med CSS-klassen no-prefetch eller no-prerender. En nettbutikk der lenker utfører handlinger (legg i handlekurv, logg ut) bør utelate slike stier.

Performance Lab. De neste kjernefunksjonene testes i pluginen Performance Lab, som drives av WordPress Performance Team. Den administrerer egne funksjonsplugins, blant annet Modern Image Formats, Image Prioritizer, Embed Optimizer, Enhanced Responsive Images, Image Placeholders, Instant Back/Forward, Performant Translations, Speculation Rules og den eksperimentelle View Transitions. Den legger også til tester i Nettstedshelse, blant annet for headeren Cache-Control: no-store som blokkerer bfcache, utløpsheadere på statiske ressurser og AVIF-støtte. På staging er dette en billig måte å sjekke om server og tema er klare for de neste WordPress-versjonene.

#Hvordan tune WordPress-databasen uten å gjette

En oppblåst wp_options-tabell kan tvinge en server i kne.

#1. Autoload-opsjoner i wp_options

WordPress laster hvert alternativ som er merket for autoload ved hver sidevisning. Hvis en plugin lagrer en 1MB JSON-blob i alternativer og setter den til autoload, laster du 1MB bortkastede data fra DB til RAM ved hver visning.

WordPress 6.6 endret reglene. Ifølge notatet fra WordPress-teamet tar kolonnen autoload nå fem verdier: on, off, auto, auto-on og auto-off. Et alternativ uten eksplisitt true som er større enn 150 000 byte, lastes ikke lenger automatisk (terskelen endres med filteret wp_max_autoloaded_option_size, som ikke bør økes). Fra versjon 6.6 varsler Nettstedshelse når den samlede størrelsen på autoloadede alternativer overstiger 800 KB.

• Handling: Spør bruken din: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto'); Hvis det er > 800KB, har du et problem. Eldre alternativer kan fortsatt ha verdien yes, derfor dekker spørringen begge settene av verdier.

#2. Rydde utløpte transients

Transients er midlertidige hurtigbufferdata (f.eks. “Twitter Feed-resultater”). De skal utløpe og forsvinne. Men hvis en cron-jobb savner dem, hoper de seg opp for alltid.

• Handling: Bruk WP-CLI for å rense dem: wp transient delete --expired.

Med en aktiv vedvarende objektcache (Redis) havner transients i Redis og ikke i wp_options, så dette problemet gjelder hovedsakelig nettsteder uten objektcache.

#3. InnoDB i stedet for MyISAM

Sørg for at tabellene dine bruker InnoDB (eller MyRocks for massive datasett). Bruk aldri MyISAM (den låser hele tabellen for hver skriving, og dreper samtidighet).

#Hvordan bygge caching-strategien for WordPress

1. Nettleser-cache: Den raskeste cachen er den du aldri lager. Sett lange Cache-Control-headere (1 år) for statiske ressurser.
2. CDN / Edge Cache: Cloudflare eller Fastly som serverer HTML-en din fra en server nær brukeren. Bruk Stale-While-Revalidate-strategier.
3. Page Cache (Server): Nginx FastCGI Cache eller Varnish. Serverer HTML fra RAM.
4. Object Cache: Redis. Detaljert ovenfor.
5. OpCache: PHP-kode kompilert til bytekode i RAM.

Unngå headeren Cache-Control: no-store på vanlige HTML-sider: Performance Lab melder den i Nettstedshelse fordi den slår av tilbake/fram-cachen (bfcache), altså øyeblikkelig retur til forrige side. Oppsettet av hvert lag steg for steg står i den omfattende guiden til WordPress-optimalisering (WPO).

#I hvilken rekkefølge bør WordPress-ytelse optimaliseres

Delene i denne guiden virker best når de brukes i rekkefølge og én om gangen, med en måling før og etter hver endring.

Begynn med serveren. Noter TTFB for de viktigste undersidene og versjonen php -v returnerer. Så lenge TTFB er over 500ms, kan ingen frontend-optimalisering veie opp for forsinkelsen.

I databasen kjører du spørringen for størrelsen på autoload-alternativer og noterer resultatet. Etter at du har ryddet alternativer og kjørt wp transient delete --expired, gjentar du spørringen for å bekrefte at verdien har gått ned.

I frontend er INP metrikken du skal følge med på. Skriv opp hvilke tredjepartsskript som lastes på hver side, for eksempel chat-widgets og sporingspiksler, og utsett de ikke-vesentlige ett om gangen, slik at du vet hvilket som faktisk veide mest.

I cachen slår du på ett lag om gangen og sjekker at HTML-en som serveres, oppdateres etter at nytt innhold er publisert.

På alle lag gjelder samme regel som i sjekklisten: Lighthouse-score er en pekepinn, og den endelige avgjørelsen tas på RUM-data fra ekte brukere. Husk 28-dagersvinduet i CrUX: vurderingen i Search Console kommer etter noen uker.

#Hvilken sjekkliste for WordPress-ytelse gjelder i 2026

• Server kjører PHP 8.3+ med OPcache aktivert.
• Database bruker InnoDB, og autoloadede alternativer holder seg under 800 KB.
• Object Cache (Redis) er aktiv.
• Bilder serveres som AVIF, og LCP-bildet har ikke loading="lazy".
• JavaScript er utsatt (deferred) for å fikse INP.
• Spekulativ lasting fra WordPress 6.8 omfatter ikke lenker som utfører handlinger.
• Du måler Real User Metrics (RUM), ikke bare Lighthouse-score, separat for mobil og desktop.

Ytelse er brukeropplevelse. Et raskt nettsted respekterer brukerens tid.

Se vår WordPress-hastighetsoptimalisering.