Oppnå 100/100 Core Web Vitals på WordPress

WordPress 7.1 på PHP 8.4 kan levere grønne vitals. Det gjør det ikke av seg selv. Et tema med Elementor, et samtykkebanner som skyver heroen, og en Vipps-knapp som hydrerer 200 KB på klikk, tapte INP før LCP i det hele tatt var ferdig. Målet i denne guiden er to lag: felt (CrUX) som skal ligge i Googles grønne soner, og lab (Lighthouse mobil) der vi internt jakter 100/100 fordi det tvinger frem disiplin i bilder, CSS og tredjepart.

Googles publiserte «good» for LCP er 2,5 sekunder på p75 i felt. Det er ikke endret i denne teksten, og vi later ikke som det finnes et 2026-dokument som har senket den offisielle listen. Når vi sier at heroen bør males nærmere ett sekund, er det vårt interne labmål, ikke Googles terskel. INP «good» er 200 ms. CLS «good» er 0,1. Labscoren 100/100 krever strammere tall enn det, fordi Lighthouse straffer TTFB, ubrukt CSS og hovedtråd i en simulert kjøring.

Resten av teksten er norsk hosting, norsk vinter-UI og norske betalingswidgets. Uten dem er en CWV-guide oversatt, ikke brukt.

#Felt mot lab: CrUX er ikke Lighthouse

CrUX er feltdata fra Chrome-brukere som har samtykket til telemetri. Vinduet er 28 dager. Metrikken som teller, er 75-prosentilen for URL-en eller opprinnelsen. Lighthouse er lab: en enhet, en nettverksprofil, én last, ofte uten innlogging, uten Vipps, uten det samtykkebanneret som bare vises i EØS.

Konsekvens:

• En side kan ha LCP 1,1 s i lab og 2,8 s i felt fordi 30 prosent av treffene kommer på 4G i utkanten av dekning, eller fordi origin i København treffes uten HTML-cache.
• En side kan ha 100 i lab og rød INP i felt fordi Klarna-widgeten bare injiseres for .no-besøkende.
• PageSpeed Insights viser begge. Les feltfanen først. Lab er diagnose, ikke dommen.

Egne RUM-målinger med web-vitals (onLCP, onINP, onCLS) sendt med sendBeacon gir dere p75 før CrUX har rullet 28 dager. Det er intern styring. Det erstatter ikke CrUX i Search Console. Rapporter aldri et Lighthouse-tall som om det var CrUX.

#Norsk hosting: Domeneshop, Simply.com og Cloudflare foran

Delt norsk og nordisk hosting er bra på faktura og dårlig som eneste kant. Domeneshop og Simply.com (og liknende) kjører PHP på delt maskin, ofte med et begrenset antall workers, uten Redis, med object cache i filer. TTFB på 400 til 800 ms fra Oslo er vanlig når siden er uncached og wp-cron treffer samtidig. LCP i felt arver den TTFB-en. Ingen AVIF-pipeline i temaet redder det.

Mønsteret som virker:

1. Origin blir hos Domeneshop eller Simply.com hvis det er der domenet og e-posten allerede bor, eller flyttes til en VPS med PHP 8.4, Opcache og Redis når trafikk og plugins krever det.
2. Cloudflare foran (oransje sky) med HTML-cache for anonyme GET, bypass på /wp-admin, /wp-login.php, preview=true, handlekurv og wordpress_logged_in.
3. Origin-IP skjult. WAF på. HTTP/3 mot klienten. Early Hints (103) for hero-preload der plattformen støtter det.

Fallgruver vi ser om igjen:

• Plugin-cache (LiteSpeed Cache, WP Super Cache) og Cloudflare HTML-cache uten felles ugyldiggjøring. Redaktøren lagrer, origin oppdateres, kanten serverer gårsdagens forside i to timer.
• Cloudflare «cache everything» på en WooCommerce-butikk. Pris og kurv lekker mellom sesjoner, eller kassen blir et cache-lotteri. Butikk-HTML er privat. Produktlister kan caches med tag.
• PHP-oppdatering til 8.4 glemt på delt hosting mens WordPress 7.1 forventer moderne runtime. 7.0 kom 20. mai 2026. Origin som blir hengende på 8.1, koster TTFB og sikkerhet samtidig.

TTFB er ikke en Core Web Vital, men den spiser LCP. Et LCP-bilde kan ikke males før første byte. På norsk delt hosting er Cloudflare den billigste måten å få første byte under 200 ms for anonyme sider. Uten den jakter du millisekunder i CSS mens origin bruker et halvt sekund.

Feltet i Norge er ikke Lighthouse sin simulerte kabelprofil. CrUX på .no inneholder Telenor, Telia og Ice på 4G, gjerne med CPU-struping på eldre Android. En labkjøring fra Mac mot localhost med 100/100 sier ingenting om p75 i Tromsø. Derfor: HTML-cache nærmest brukeren, små JS-øyer, og ingen synkron Vipps på forsiden. Hvis DNS fortsatt peker A-record til origin uten Cloudflare, er «vi har HTTP/3» bare en setning i panelet hos Domeneshop.

#LCP: Googles 2,5 s og vårt interne labmål

Largest Contentful Paint er tiden til det største innholdselementet i visningsporten er malt. På WordPress er det nesten alltid hero-bildet, av og til en H1 over et bakgrunnsbilde som aldri blir LCP fordi teksten vinner.

Google, felt, p75: 2,5 s eller bedre er grønt. Mellom 2,5 og 4,0 s er «needs improvement». Over 4,0 s er rødt. Det er listen. Internt, i Lighthouse-mobil, jakter vi ofte LCP under 1,2 s fordi 100/100 krever det, og fordi det gir margin når feltet er tøffere enn lab. Det er vårt mål. Det er ikke Googles nye terskel.

LCP-tiden er summen av TTFB, last-forsinkelse, nedlasting og render-forsinkelse. Typisk WordPress-feil:

1. Hero med loading="lazy". Kjernen og mange temaer lazy-laster alt. Lazy på LCP-bildet utsetter starten på nedlastingen til etter layout. Fjern lazy på første bilde. Sett fetchpriority="high". Preload i <head> med imagesrcset og imagesizes som matcher det som faktisk vises.

2. WebP der AVIF er billigere i byte. AVIF er standarden vi koder til i 2026. WebP er fallback. JPEG er originalen i mediebiblioteket, ikke leveransen. En hero på 1800 px trenger ikke 3 MB PNG fra Byråets siste kampanjeeksport.

3. Font som blokkerer maleriet. Hvis LCP er tekst, er webfonten i kritisk sti. Subset til latin-ext (norske tegn: æ ø å), font-display: optional eller et metric-justert fallback. Se fontavsnittet.

4. Origin uten cache. Se hostingavsnittet. Preload hjelper ikke hvis HTML kommer etter 700 ms.

<?php
declare(strict_types=1);

add_action('wp_head', static function (): void {
    if (!is_singular()) {
        return;
    }
    $id = (int) get_the_ID();
    if (!has_post_thumbnail($id)) {
        return;
    }
    $thumb = (int) get_post_thumbnail_id($id);
    $url = wp_get_attachment_image_url($thumb, 'large');
    if (!is_string($url) || $url === '') {
        return;
    }
    printf(
        '<link rel="preload" as="image" href="%s" fetchpriority="high" />' . "\n",
        esc_url($url)
    );
}, 1);

På Astro 7 og Next.js 16 skjer preload i malen, ikke i wp_head. Origin leverer URL og dimensjoner via GraphQL. Frontend skriver <link rel="preload"> og <img> med width, height og AVIF-srcset. Ikke la WordPress og rammeverket begge gjette.

#INP: 200 ms, Vipps og Klarna

Interaction to Next Paint erstattet FID i 2024. FID målte første klikk. INP måler klikk, tap og tast gjennom hele økten. Grønn INP i felt er 200 ms eller bedre på p75. Mellom 200 og 500 ms er «needs improvement». Over 500 ms er rødt. 100/100 i lab krever ofte godt under 200 ms fordi Lighthouse straffer lange oppgaver hardt.

INP er input delay + behandling + presentasjon. På norske sider er behandlingen nesten alltid tredjepart, ikke deres toggleMenu().

Vipps. Vipps Login og Vipps Checkout laster eksterne skript, åpner modal eller redirect, og registrerer håndtere på knapper i hero eller kasse. Hvis skriptet lastes synkront i <head>, eier Vipps hovedtråden før første klikk på menyen. Last Vipps når kassen er i viewport (client:visible i Astro 7, dynamisk import i Next.js 16), eller på idle. Knappen kan være HTML med href til en tynn kasserute. Hydrer widgeten der, ikke på forsiden.

Klarna. On-site messaging (pris splittet i tre, badge under kjøp-knappen) injiserer iframe og skript per produktkort. Ti kort på et arkiv er ti potensielle long tasks. Ett badge under den synlige kjøp-knappen, lazy for resten. Ikke GTM-tag som sprayer Klarna på alle maler.

Øvrig:

• Google Tag Manager, Meta Pixel, Hotjar, chat: Partytown eller last etter requestIdleCallback. Aldri i kritisk sti.
• Lange lister (filter i butikk, mega-meny): scheduler.yield() mellom biter, eller virtualiser. En querySelectorAll over 2000 noder i klikk-handleren er et INP-brudd.
• Mobilmeny og trekkspill på små skjermer: første tap på hamburgeren er ofte den INP-en CrUX fanger. Hvis klikket venter på at hele navigasjonstreet skal hydreres, inkludert ikonfont og dropdown-logikk, er 200 ms brukt opp. Server-rendret meny som åpnes med en <details>-element, eller en øy som bare eier menyen, er nok. Ikke hydrer hele headeren som én React-øy.
• Astro 7: hold øyer små. En øy som importerer hele designsystemet, er en React-app med ekstra ledd. Next.js 16: Server Components som standard, klientkomponenter bare der det fins onClick.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Mål INP i felt per mal, ikke som snitt for hele domenet. En blogg kan være grønn mens kassen er rød. CrUX på origin-nivå skjuler det. URL-nivå i Search Console og egen RUM per page_type viser det.

#CLS: samtykkebanner og mørk modus om vinteren

Cumulative Layout Shift summerer uventede hopp. Grønn CLS i felt er 0,1 eller bedre. 100/100 i lab vil ha nær 0,00. De to norske kildene som slår width og height på bilder, er samtykke og tema.

Samtykkebanner (ePrivacy + GDPR). Cookie Information, Cookiebot, Usercentrics og hjemmesnekrede barer injiseres ofte etter hydrering. Banneret tar 80 til 120 px i topp eller bunn. Heroen, som allerede er LCP, skyves. Det er CLS, og det treffer nesten alle første-gangs-besøk i EØS. CrUX p75 merker det, Lighthouse uten banner merker det ikke.

Fiks: reserver plassen i CSS før skriptet kjører. Fast min-height på en wrapper som alltid er i malen. Ikke animer høyden fra 0 til 96 px. Hvis banneret er overlay (modal), reserver ingenting i flyt, men lås scroll uten å endre padding-top på <body> etter måling. Last samtykkeskriptet så det ikke vinner over LCP, men la wrapperen ligge i første HTML.

Mørk modus om vinteren. Norske brukere har prefers-color-scheme: dark mer av året enn en labprofil i California. Hvis tema-klassen (dark på <html> eller <body>) settes i en klient-script etter første maleri, hopper bakgrunn, tekst og skygger. Det er CLS og ofte en flash. Fiks: sett klassen i en liten synkron <script> i <head> før CSS, les localStorage og matchMedia, og hold fargevariabler slik at byttet ikke endrer geometri. Bytt farge, ikke font-størrelse og lining. En filter: invert på hele body er et CLS- og kontrastproblem, ikke et tema.

Øvrig CLS:

• Bilder og iframe: width, height eller aspect-ratio. YouTube-embed i 16/9-boks.
• Fonter: size-adjust, ascent-override på fallback, så Arial og Geist tar samme linjeboks.
• Annonse- og relaterte-blokker: min-høyde, ikke «vi vet ikke før API svarer».

.consent-slot {
  min-height: 96px;
}

.hero-media {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

@font-face {
  font-family: Geist-Fallback;
  src: local("Arial");
  size-adjust: 106%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

#Bilder og fonter uten å stjele LCP

Mediebiblioteket i WordPress lagrer originaler. Leveransen er AVIF i 400, 768, 1200 og 1920 bredder, med sizes som matcher layouten, ikke 100vw på en artikkel i en 680 px-kolonne. loading="lazy" på alt under fold. decoding="async". Ingen carousel i hero som laster fem LCP-kandidater.

Fonter: to vekter, ikke fem. Subset til latin og latin-ext. WOFF2. Self-host, ikke en Google Fonts-CSS som gjør to ekstra runder før @font-face. På Astro 7 og Next.js 16 ligger dette i bygg-pipen. På en monolitt: plugin eller build som skriver subset-filer, ikke «Elementor Custom Fonts» med TTF.

Kritisk CSS hører i første pakke. Målet er at header, typografi og hero-boks får stil i HTML-en, under omtrent 14 KB komprimert, slik at første maleri ikke venter på style.css fra temaet. Resten av arket lastes asynkront. Elementor- og Divi-bygg som sender 400 KB CSS til hver URL, taper LCP før bildet er nevnt. I headless skriver Astro og Next bare klassenavnene siden bruker. I monolitt: trekk ut above-the-fold per mal, eller bytt tema.

content-visibility: auto på kommentarer, relatert rutenett og bunntekst kutter stil- og layout-arbeid under første maleri. Sett contain-intrinsic-size så scrolbaren ikke hopper (det er CLS).

#Astro 7-øyer og Next.js 16 for vitals

To fronter, samme krav: første maleri uten unødvendig JavaScript.

Astro 7 er standarden for innhold. HTML og CSS ut. Øyer der det fins klikk. client:idle for søk. client:visible for kasse-widget. En artikkel uten øyer sender 0 KB JS og vinner lab. Det er derfor 100/100 er oppnåelig på magasin uten å snyte på design.

Next.js 16 er riktig når siden er en app. PPR: statisk skall, dynamiske hull. React Server Components for listen, klientkomponent for filteret. Hele App Router som "use client" på layout er å gi bort INP. Partial Prerendering hjelper LCP. Den hjelper ikke hvis useEffect i rot-layouten laster Tag Manager, Vipps og Klarna samtidig.

Monolitt på PHP 8.4 med et stramt tema, Redis og Cloudflare kan også bli grønn i felt. Den taper når redaktøren installerer «ett lite» popup-plugin. Headless taper når øya importerer hele ikonpakken. Arkitektur velger dere i headless-guiden. Vitals er utfallet av den arkitekturen, pluss tredjepart.

Speculation Rules (<script type="speculationrules"> med conservative prerender på interne lenker) kutter neste navigasjon mot null i støttede Chrome-klienter. Det forbedrer opplevd fart. Det endrer ikke LCP på landing fra Google, som er den URL-en CrUX bryr seg om.

#PHP 8.4, Redis og TTFB bak Cloudflare

Ucached HTML på delt hosting er LCP-taket. Redis object cache kutter SQL for innloggede og for cache-bom. Opcache på 8.4 kutter PHP-oppstart. En side-cache foran (Cloudflare, eller Nginx fastcgi_cache hvis dere eier VPS) kutter PHP helt for anonyme.

Prioritet:

1. HTML-cache for anonyme, med purge ved publisering.
2. Redis for WP_Query og transients.
3. Færre plugins i front. Hver wp_enqueue_script er INP.
4. Databaseindekser og autoload-opprydding. Autoload på 2 MB i wp_options er TTFB før temaet har startet.

WordPress 7.1 endrer ikke dette. Kjernen er ikke LCP-problemet. Køen av skript og origin-avstanden er det.

#RUM, budsjetter og regresjon

Lab i CI: Lighthouse-budsjett på PRs for malene som betyr noe (hjem, artikkel, produkt, kasse). Feil bygget hvis JS på artikkel malen overstiger noen titalls kilobyte, eller hvis LCP-elementet mangler dimensjoner. Det fanger regresjon fra et nytt plugin eller en ny øy.

Felt: web-vitals til deres endepunkt, aggregert p75 per mal per uke. Alarm når INP krysser 200 ms i felt, ikke når noen kjørte Lighthouse på fiber i Oslo. CrUX API ukentlig som fasit mot Search Console.

Budsjetter som overlever vinteren:

• Samtykke-wrapper har høyde i CSS.
• Tema-script i <head> er under 1 KB og rører ikke layout.
• Vipps og Klarna er ikke på forsiden.
• Hero er AVIF, preload, ikke lazy.

Uten budsjett er 100/100 et skjermbilde fra lanseringsuken.

Multisite endrer ikke tersklene. Den endrer origin-lasten. Ett Redis-instance per nettverk, HTML-cache per blogg-ID, og ingen felles all.min.js som laster WooCommerce-skript på magasinnettstedet. Med det kan Multisite ligge like grønt i CrUX som en enkeltinstallasjon. Uten det arver hver site den trege naboens enqueue.

#Revisjon og videre lesing

Core Web Vitals-revisjonen er felt pluss lab pluss en liste over tredjepart som skal ut av hovedtråden. Vi åpner CrUX og Search Console først, Lighthouse etterpå, og vi måler Vipps-kassen som egen mal.

Hastighetsarbeid på en eksisterende monolitt er beskrevet i hvordan gjøre en WordPress-nettside raskere. Frikobling som topologi, ikke som ytelsestroll, ligger i headless-arkitekturen.

#Konklusjon

Google har ikke senket LCP-listen til 1,2 s. Grønn LCP i felt er 2,5 s. Grønn INP er 200 ms. Grønn CLS er 0,1. 100/100 er labdisiplin. På norske WordPress-sider er det Cloudflare foran Domeneshop eller Simply.com, plass til samtykkebanneret, tema uten vinter-FOUC, og Vipps/Klarna vekk fra første interaksjon som skiller grønt felt fra et pent Lighthouse-skjermbilde.

Kontakt oss med URL og Search Console-tilgang hvis feltet er rødt og laben lyver.