Treg WordPress-side: Slik fikser du det

WordPress-siden din føles treg. Refleksen er å kjøpe dyrere hosting. Det er sjelden det første som faktisk flytter målene.

Mål først. Deretter kutt det som genererer arbeid på hver forespørsel: plugins, bilder, databasespørringer og tredjeparts-skript. Hosting bytter du når TTFB allerede er dårlig etter at du har fjernet det åpenbare.

#Core Web Vitals-terskler for WordPress i 2026

Google vurderer feltedata via Core Web Vitals:

INP erstattet FID i mars 2024. Gamle artikler som snakker om FID alene er utdaterte. Bruk PageSpeed Insights for lab, Search Console eller CrUX for det brukerne faktisk opplever.

Lastes betalingswidgets som Vipps eller Klarna synkront i headeren på produktsider, kan LCP der være dårlig selv om forsiden ser «grei» ut i en syntetisk kjøring fra et annet kontinent. Mål mobil fra regionen brukerne faktisk er i, ikke bare desktop fra et CDN-nært lab-sted.

#Hjelper bedre hosting på treg WordPress

Serverbytte kan senke TTFB. Det fikser ikke:

• 40 aktive plugins der tre gjør «hastighet», to gjør sikkerhetsskanning hver time, og én synkroniserer hele kataloget mot ERP hvert femte minutt
• JPEG på 3 MB i hero uten srcset eller moderne format
• et tema som kjører en WP_Query uten no_found_rows på hver undersiderender
• Google Fonts hentet fra fonts.googleapis.com uten font-display og uten self-hosting

Bytt hosting når TTFB på en nesten tom PHP-side fortsatt er over ~1 s, eller når CPU-throttling er synlig under Black Friday-trafikk. Ikke før.

#Slik måler du hastigheten på WordPress-siden

1. Åpne Search Console, rapporten Core Web Vitals (mobil).
2. Kjør Query Monitor på staging. Sortér etter tid og antall spørringer på forsiden og én tung mal.
3. I DevTools, fanen Network: noter vannfall for dokumentet, største bilde, og hoved-CSS.
4. Skriv ned tre tall: TTFB, LCP-element, antall JS-kilobyte før interaktivitet.

Uten disse tallene optimaliserer du på magefølelse.

#Slik leser du feltdata i PageSpeed Insights for en WordPress-side

PageSpeed Insights viser to ulike typer tall på samme skjerm, og blander man dem, ser en WordPress-rettelse ofte ut til å ikke ha virket. Feltdata-delen kommer fra Chrome User Experience Report (CrUX): ekte Chrome-brukere som har samtykket, samlet over de foregående 28 dagene og rapportert ved 75. persentil (dokumentasjonen for PageSpeed Insights). Lab-delen er én simulert innlasting på én enhet med faste nettverksforhold, så de to settene med verdier kan avvike.

Tre konsekvenser for diagnosen:

• Sjekk hvilket nivå dataene gjelder. Når en URL ikke har nok egne data, faller PSI tilbake til data for hele opprinnelsen. På et blogginnlegg med lite trafikk kan felt-LCP da beskrive hele domenet, ikke den siden.
• Prioriter med feltdata, feilsøk med labdata. web.dev anbefaler at feltdata styrer prioriteringen når begge finnes, og at labdata brukes til feilsøking (web.dev: hvorfor lab- og feltdata er forskjellige). Labtester laster siden med tom cache og kan ikke forutsi når en ekte besøkende klikker, derfor er Total Blocking Time bare en lab-tilnærming til INP, ikke en erstatning.
• Regn med forsinkelse. Fordi vinduet er 28 dager, vises en rettelse fra i dag fullt ut i feltdataene først rundt fire uker senere. En labscore som blir bedre over natten er et godt tegn, ikke et bevis.

#Slik sjekker du om TTFB peker mot serveren

TTFB er der spørsmålet om hostingen har skylden får et målbart svar. web.dev definerer TTFB som summen av omdirigeringstid, oppstart av service worker, DNS-oppslag, tilkobling og TLS-forhandling, og forespørselen frem til første byte i svaret. Som grov rettesnor regnes 0,8 sekunder eller mindre som bra og over 1,8 sekunder som dårlig (web.dev: Optimize Time to First Byte).

Den oppdelingen er viktig for WordPress fordi ikke alt er PHP. En besøkende som lander på http://, sendes videre til https:// og så til www-verten, betaler for hvert hopp før WordPress i det hele tatt begynner. Network-panelet i DevTools viser hver omdirigering som en egen forespørsel, og rettelsen hører hjemme i server- eller CDN-konfigurasjonen, ikke i databasen. I felt kommer TTFB fra CrUX eller JavaScript-biblioteket web-vitals, i lab fra Network-panelet i DevTools eller WebPageTest.

Grensen på rundt 1 s for en nesten tom PHP-side i hosting-delen nedenfor er denne artikkelens egen arbeidsterskel for når serveren er flaskehalsen. web.dev sine 0,8 s gjelder hele siden i feltdata. Ligger en side fra page cache godt over 0,8 s, er det en grunn til å sjekke om page cache faktisk treffes.

#Slik bruker du Nettstedshelse til å finne hastighetsproblemer i WordPress

WordPress har innebygde sjekker under Verktøy, Nettstedshelse, og noen av dem handler om hastighet. Siden WordPress 6.1 sjekker Nettstedshelse om en full page cache finnes og om serverens responstid er akseptabel, med 600 ms som standard terskel som hostingleverandører kan endre med filteret site_status_good_response_time_threshold. Den anbefaler også en persistent object cache når nettstedets data passerer terskler som hosten kan overstyre med site_status_persistent_object_cache_thresholds (Make WordPress Core, cache-sjekker i 6.1). Begge sjekkene kjører bare i produksjon, så en staging-kopi viser dem ikke.

WordPress 6.6 la til en sjekk for autoloadede options: den melder et problem når options som lastes på hver forespørsel til sammen er over 800 KB. Samme versjon sluttet å autoloade enkelt-options større enn 150 000 byte med mindre koden ber om det eksplisitt, en grense som kan justeres med filteret wp_max_autoloaded_option_size (Make WordPress Core, autoload-endringer i 6.6). En autoload-advarsel fører som regel tilbake til foreldreløse plugin-options, beskrevet i databasedelen lenger ned.

#Slik finner du den trege pluginen med Query Monitor

Query Monitor gjør “WordPress er treg” om til en navngitt komponent. Databasepanelet markerer trege, dupliserte og feilende spørringer og grupperer dem etter type, komponent eller kallende funksjon, så en spørring som én plugin gjentar på hver forespørsel dukker opp under den pluginens navn (Query Monitor på GitHub). To andre paneler er lette å overse:

• HTTP API-kall: hver forespørsel på serversiden gjort via WordPress HTTP API, med feilende forespørsler og svar som ikke er 200 uthevet. En plugin som kontakter en ekstern server mens siden genereres, legger den rundturen til TTFB.
• Hooks og actions: hver hook som kjøres under forespørselen, med callbacks, prioriteter og komponenter. Det viser hvor en plugin henger seg på sider der den ikke har noen synlig jobb.

Kjør den på en staging-kopi der det går. Query Monitor viser utdata til innloggede administratorer, og innloggede forespørsler går vanligvis forbi page cache, så tallene beskriver tilfellet uten cache: arbeidet serveren gjør for hver besøkende cachen ikke dekker.

#Gjør for mange plugins WordPress treg

Hver plugin er en potensiell plugins_loaded-hook, et REST-kall og en cron. Før du installerer «nok en cache-plugin»:

1. Deaktiver alt som ikke er i produksjonskritisk sti.
2. Mål LCP og spørringsantall på nytt.
3. Aktiver tilbake én og én. Behold bare det som beveger en forretningsmetrikk.

To «speed»-plugins samtidig er en klassiker: begge minifiserer, begge deferred JS, begge skriver kritiske CSS-filer, og ingen av dem er enige om rekkefølgen. Resultatet er dobbelt arbeid og ødelagt CSS.

Plugins som ofte koster mer enn de gir:

• Page builders (Elementor, Divi) som laster sine assets på sider som ikke er bygget med dem.
• Plugins for deling i sosiale medier som laster skript på hver side.
• SEO-plugins med alle valgfrie moduler slått på.
• Statistikk-plugins som skriver hvert besøk til WordPress-databasen.

For WooCommerce: skru av cart-fragment-AJAX på sider som ikke trenger live handlekurv.

#Slik optimaliserer du bilder og LCP i WordPress

LCP er nesten alltid et bilde eller en stor heading-blokk.

• Sett eksplisitt width og height (eller aspect-ratio) på hero.
• Lever AVIF/WebP med JPEG-fallback. CDN-transformasjon kan i tillegg lage formatvarianter for deg.
• Bruk fetchpriority="high" kun på LCP-bildet, ikke på logoen i headeren.
• Unngå bakgrunnsvideo som autoplayer med lydspor i DOM før LCP.

En 1800 px bred PNG lagret som «transparent logo» i headeren er tung for et element som vises lite. Konverter til SVG eller en liten WebP.

#Redis object cache og databasespørringer i WordPress

Når Query Monitor viser 100+ spørringer på forsiden, hjelper ikke bildekomprimering.

Cache dyre WP_Query-resultater med object cache når Redis eller Memcached er tilgjengelig:

function wpp_cached_latest_posts(): WP_Query {
	$cache_key = 'wpp_latest_posts_v1';
	$cached    = wp_cache_get( $cache_key, 'wpp' );

	if ( $cached instanceof WP_Query ) {
		return $cached;
	}

	$query = new WP_Query(
		array(
			'posts_per_page' => 5,
			'post_status'    => 'publish',
			'no_found_rows'  => true,
		)
	);

	wp_cache_set( $cache_key, $query, 'wpp', HOUR_IN_SECONDS );

	return $query;
}

Uten Redis faller wp_cache_* tilbake til ikke-persistent cache per forespørsel. Da trenger du fortsatt page cache (nginx FastCGI, Cloudflare cache rules, eller en velkonfigurert cache-plugin) for anonyme besøkende.

Transients i wp_options som aldri slettes autoload-es på hver side. Rydd dem. Autoloaded options over noen hundre kilobyte er et stille TTFB-problem.

#Slik rydder du WordPress-databasen

Over tid samler WordPress-databasen data som gjør spørringer tregere:

• Innleggsrevisjoner: WordPress lagrer en revisjon hver gang du lagrer, så et innlegg som er redigert mange ganger drar med seg en lang hale av gamle kopier.
• Utløpte transients: de kan bli liggende i wp_options til noe rydder dem.
• Foreldreløse options: avinstallerte plugins etterlater ofte innstillingene sine, noen ganger med autoload slått på, slik at de lastes på hver forespørsel.
• Foreldreløse metadata: innleggs-, bruker- og kommentarmeta som peker til poster som ikke lenger finnes.

// Begrens innleggsrevisjoner i wp-config.php
define('WP_POST_REVISIONS', 5);

// Eller slå dem helt av (ikke anbefalt for nettsteder med flere redaktører)
define('WP_POST_REVISIONS', false);

Verktøy til jobben:

• WP-Optimize: planlagt opprydding av revisjoner, transients og foreldreløse data.
• phpMyAdmin: for manuelle spørringer når du vet nøyaktig hva du sletter.
• WP-CLI: wp transient delete --expired og wp db optimize fra kommandolinjen, det tryggeste valget på nettsteder med store tabeller.

Ta en databasebackup før all opprydding. En feil spørring mot wp_postmeta fikses ikke med en angreknapp.

#Slik forbedrer du INP og kutter JavaScript i WordPress

INP bryter når hovedtråden er opptatt under klikk.

• Last chat, heatmaps og A/B-verktøy etter interaksjon eller idle, ikke i <head>.
• Bytt ut jQuery-UI-widgets der native detaljer/dialog holder.
• Page builders: eksporter malen til blokker der det er realistisk, eller begrens builder-CSS til malene som trenger den.
• Unngå ob_gzhandler som «cache». Det er komprimering, ikke cache, og det kolliderer med moderne server-gzip/brotli.

// Ikke gjør dette som erstatning for ekte page cache.
add_action(
	'init',
	static function () {
		if ( ! is_admin() ) {
			ob_start( 'ob_gzhandler' );
		}
	}
);

#Når bør du bytte WordPress-hosting

Bytt eller oppgrader når:

• TTFB på en minimal index.php-test er over 1 s fra brukerens region
• PHP er låst på 7.4 mens du trenger 8.2+ for moderne plugins
• Disk er HDD, og media-biblioteket er på samme volum som databasen under tung Woo-trafikk
• Cron kjører bare når noen besøker siden, og køen aldri tømmes

For norske team som hoster hos etablerte delte leverandører: sjekk om object cache tilbys som tillegg før du flytter hele stacken. Flytting uten Redis-plan og uten staging er hvordan man bytter ett sett problemer med et annet.

#Plan for raskere WordPress på én uke

Feltedata henger etter. Ikke panikk på dag 2 fordi Search Console fortsatt viser den gamle URL-gruppen.

#Slik overvåker du WordPress-ytelsen over tid

Ytelsesarbeid er ikke en engangsjobb. WordPress-sider endrer seg hele tiden med nytt innhold, plugin-oppdateringer og konfigurasjonsendringer, og uten overvåking siger hastigheten sakte tilbake. For varsling og langsiktig oppsett på større nettsteder, se vår guide til ytelsesovervåking for WordPress.

Verktøy som er verdt å bruke:

• Google PageSpeed Insights: stikkprøver av Core Web Vitals for én URL.
• Google Search Console: feltdata fra ekte Chrome-brukere, gruppert etter URL-mønster.
• GTmetrix: et detaljert fossefall over alle forespørsler på siden.
• Query Monitor: feilsøking av database og hooks på en staging- eller utviklingskopi.

Tredjeparts-skript fortjener en egen sjekk. ePrivacy-direktivet (2002/58/EF, artikkel 5 nr. 3) krever samtykke før ikke-nødvendige informasjonskapsler lagres (teksten på EUR-Lex), så sporingsskript bør først lastes når den besøkende har sagt ja. Gjort riktig holder det dem også ute av første sidevisning for alle som ikke har klikket på banneret ennå.

#CDN-cache, cookies og Vipps-checkout i WooCommerce

Cloudflare eller annet CDN foran WordPress hjelper bare hvis HTML for anonyme brukere faktisk caches. Vanlige feil:

• Set-Cookie fra et «pop-up»-plugin på første treff gjør hele HTML-en uncacheable
• WooCommerce session-cookie satt for alle besøkende, også de som aldri åpner handlekurven
• Georedirect-plugin som kjører PHP før cache-laget

For Vipps / Klarna: last SDK etter at LCP-elementet er malt, eller begrens dem til checkout. En synkron Vipps-script i global footer er en hyppig INP-synder på norske produktlister.

Et fornuftig utgangspunkt i Cloudflare for WordPress:

1. Sett SSL/TLS til “Full (strict)” så trafikken er kryptert helt frem til serveren.
2. Legg inn cache-regler for statiske filer, og gå forbi cachen for /wp-admin/, innloggede brukere og handlekurv- og kassesidene i WooCommerce.
3. La Brotli-komprimering være på.
4. På betalte planer kan Polish ta seg av bildeoptimalisering, eller du fortsetter å gjøre det i WordPress hvis du allerede lager AVIF.

Self-host webfonter. fonts.googleapis.com + fonts.gstatic.com er to ekstra DNS-runder og ofte en CLS-kilde når fallback-fonten har annen metrik.

#Oppsummering

Treg WordPress er et måleproblem før det er et hostingproblem. Start med LCP, INP og TTFB, kutt plugin- og bildevekt, cache det dyre, og utsett serverbytte til tallene sier at maskinvaren er flaskehalsen.

Den fullstendige arbeidsflyten for optimalisering står i vår guide til WordPress-optimalisering, og helhetsbildet for 2026 i den definitive guiden til WordPress-ytelse.

Trenger du en gjennomgang av akkurat din stack (tema, Woo, CDN, Redis), gjør vi det som del av WordPress-utvikling og ytelsesarbeid.