Optimalisering av Interaction to Next Paint i WordPress

I 2026 handler en «rask» nettside om mer enn hvor fort det første bildet dukker opp. I dag defineres hastighet også av responsivitet.

Når en bruker klikker på en knapp på WordPress-siden din, reagerer den umiddelbart, eller merker man et lite hikk? Det gapet, tiden mellom brukerens handling og nettleserens visuelle respons, er det Interaction to Next Paint (INP) måler. INP er én av de tre Core Web Vitals, og Google Search oppgir at Core Web Vitals brukes av rangeringssystemene deres. Den samme dokumentasjonen legger til at det ikke finnes ett samlet signal for sideopplevelse, og at relevans kommer først. INP avgjør altså mellom nyttige sider, men løfter ikke en side forbi dem. Den sterkeste grunnen til å fikse INP er den besøkende: en treg meny eller en frossen «Legg i handlekurven»-knapp merkes ved hver eneste sidevisning.

Denne guiden hører sammen med vår guide til Core Web Vitals 2026 og tar for seg hvordan INP beregnes, hva som bremser hver fase av en interaksjon på en typisk WordPress-side, hvordan du finner skriptet som har skylden med Long Animation Frames, og hvilke WordPress-API-er som hjelper.

#Hva er INP og når erstattet det FID

INP ble en stabil Core Web Vital 12. mars 2024 og erstattet First Input Delay (FID). Lanseringsinnlegget på web.dev ga utviklere frist til 9. september 2024 med å flytte all kode som leste FID fra CrUX- eller PageSpeed Insights-API-ene. Etter den datoen var FID ikke lenger garantert tilgjengelig. PageSpeed Insights vurderer nå INP i stedet for FID i sin Core Web Vitals-vurdering.

Forskjellen mellom de to målingene ligger i omfanget. FID målte bare input-forsinkelsen på den første interaksjonen på en side. INP følger hele forsinkelsen (input-forsinkelse, behandling og presentasjon) for hvert klikk, trykk og tastetrykk gjennom hele besøket. En side som laster godt, men hakker på den tredje interaksjonen, består dermed ikke lenger.

#Hvordan beregnes INP

web.devs definisjon av INP setter tre grenser, vurdert ved 75. persentil av sideinnlastinger og delt opp på mobil og desktop:

For hver sidevisning registrerer nettleseren forsinkelsen for hver observert interaksjon. Rapportert INP er den lengste av dem, med én regel for svært travle sider: én av de høyeste interaksjonene ignoreres for hver 50. interaksjon. De fleste sidevisninger har færre enn 50 interaksjoner, så i praksis blir den verste interaksjonen som regel INP for det besøket. Samler du inn INP selv med JavaScript, foreslår web.dev å ta 98. persentil av interaksjonene når siden lukkes, noe som tilnærmer den samme regelen.

Bare museklikk, trykk på berøringsskjerm og tastetrykk teller. Hovring, scrolling og zooming observeres ikke, men et klikk eller tastetrykk inne i disse bevegelsene kan bli det. Det har en praktisk konsekvens: en side kan mangle INP-verdi helt. Det skjer når den besøkende aldri klikker, trykker eller skriver, når de bare scroller, eller når besøket kommer fra en bot, for eksempel en søkemotorcrawler som ikke er programmert til å samhandle med siden. Et blogginnlegg der de fleste lesere bare scroller, vil ofte ha tynnere INP-data enn en produktside med variantvelger.

#Hva er de tre fasene i INP

Hver interaksjon som INP måler, er summen av tre deler, slik web.devs guide til optimalisering av INP beskriver:

1. Input-forsinkelse (input delay): fra brukeren starter interaksjonen til den første callbacken i hendelseshåndtereren begynner å kjøre. Den vokser når hovedtråden er opptatt med noe annet, for eksempel et skript som parses, en timer som utløses, eller en tidligere interaksjon som fortsatt håndteres.
2. Behandlingstid (processing duration): tiden alle callbacks i hendelseshåndtererne for interaksjonen bruker på å kjøre.
3. Presentasjonsforsinkelse (presentation delay): fra callbackene er ferdige til nettleseren tegner neste ramme, inkludert ny stilberegning, layout og tegning.

For å få vurderingen «god» må hver interaksjon, fra et klikk i navigasjonsmenyen til et tastetrykk i et søkefelt, være visuelt ferdig på 200 ms eller mindre. Når du fikser én treg interaksjon, dukker ofte den neste opp, så se på INP-optimalisering som en løkke du går gjennom flere ganger, ikke som én enkelt oppgave.

#Hvordan redusere input-forsinkelse i WordPress

Input-forsinkelse skyldes som regel at hovedtråden er opptatt når brukeren prøver å klikke. På WordPress-sider er de vanligste kildene evaluering av skript under innlasting (parsing, kompilering og kjøring av JavaScript fra utvidelser og tema) og tredjepartsskript som kjører periodisk arbeid uten hensyn til brukerens input.

#Hvordan gi fra seg hovedtråden med scheduler.yield()

web.devs artikkel om lange oppgaver definerer en lang oppgave som enhver oppgave over 50 ms. Løsningen er å dele langt JavaScript-arbeid opp i mindre oppgaver, slik at nettleseren kan håndtere en interaksjon innimellom. scheduler.yield() returnerer et promise som løses i en ny oppgave, og fortsettelsen får prioritet: resten av arbeidet ditt fortsetter før andre køede oppgaver av samme type, så et tredjepartsskript kan ikke snike seg inn mellom bitene dine.

Støtte er viktig her. scheduler.yield() finnes i Chrome 129, Edge 129 og Firefox 142, mens Safari ikke støtter det. web.dev anbefaler en reserveløsning med setTimeout(), som også gir fra seg tråden, bare uten den prioriterte fortsettelsen:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processLargeList(items) {
  for (const item of items) {
    expensiveOperation(item);
    await yieldToMain();
  }
}

Eldre veiledninger lar yielding avhenge av navigator.scheduling.isInputPending(). web.dev anbefaler ikke lenger dette API-et: det kan returnere false rett etter en brukerinteraksjon, og input er ikke den eneste grunnen til å gi fra seg tråden, siden animasjoner og andre oppdateringer av visningen også trenger hovedtråden. Gi fra deg tråden uansett om det venter input eller ikke.

#Hvordan fjerne ubrukt JavaScript i WordPress

Bare JavaScript som trengs for den gjeldende visningen, skal lastes. Leser brukeren et blogginnlegg, er det ingen grunn til at et bibliotek for kassen ligger på siden. Betinget lasting av ressurser, per mal eller per blokk, er det første vi sjekker i en INP-revisjon av WordPress, fordi kode som aldri lastes, aldri kan blokkere en interaksjon. Mer om dette i vår guide til hastighetsoptimalisering av WordPress.

#Hvordan utsette skript med lastestrategien i WordPress 6.3

WordPress 6.3 la til en lastestrategi i wp_register_script() og wp_enqueue_script(), dokumentert i Make WordPress Core-notatet om async og defer. Den femte parameteren tar nå imot en array med to nøkler, strategy (defer eller async) og in_footer:

wp_enqueue_script(
  'wppoland-filters',
  get_theme_file_uri( 'assets/filters.js' ),
  array(),
  '1.4.2',
  array(
    'strategy'  => 'defer',
    'in_footer' => true,
  )
);

Strategien er en forespørsel, ikke en garanti. WordPress sjekker avhengighetstreet: et utsatt skript som et blokkerende skript er avhengig av, blir også blokkerende, for å bevare kjørerekkefølgen. Et inline-skript lagt til med posisjonen after tvinger også foreldreskriptet tilbake til blokkerende, og den endringen kan forplante seg gjennom treet. Etter at du har satt et tema eller en utvidelse til defer, bør du derfor se på kildekoden til siden og bekrefte at attributtet faktisk er der. Det samme notatet anbefaler å erstatte gamle triks med filteret script_loader_tag med dette API-et.

#Hvordan redusere behandlingstiden i INP

Her testes hvor effektiv din egen kode er. Det generelle rådet fra web.dev er å gjøre så lite arbeid som mulig i callbacks for hendelser.

#Hvordan holde hendelseshåndterere lette

Unngå kompleks logikk inne i klikkhåndterere. Oppdater den delen av grensesnittet brukeren venter på, gi fra deg tråden, og kjør alt annet i en senere oppgave. Eksempelet fra web.dev bruker en tekstboks: det innskrevne tegnet vises med en gang, mens ordtelling, stavekontroll og lagring utsettes med requestAnimationFrame() og en setTimeout() inni den, slik at de kjører etter at neste ramme er tegnet.

button.addEventListener('click', () => {
  const price = calculatePrice(product, variant);
  priceElement.textContent = formatPrice(price);

  requestAnimationFrame(() => {
    setTimeout(() => {
      sendAnalytics('price_calculated', price);
      saveCartDraft(product, price);
    }, 0);
  });
});

Den synlige endringen skjer i håndtereren, mens analyse og lagring venter til rammen med den nye prisen er tegnet.

#Hvordan unngå layout thrashing

Layout thrashing, også kalt tvunget synkron layout, oppstår når kode endrer stiler og deretter leser en layoutegenskap som offsetWidth i samme oppgave. Nettleseren må da beregne layout med en gang i stedet for én gang på slutten av rammen, og i en løkke skjer det i hver iterasjon. Les alle verdiene først, skriv deretter:

// Tvinger layout i hver iterasjon: unngå
elements.forEach((el) => {
  const width = el.offsetWidth;
  el.style.width = width + 10 + 'px';
});

// Leser først, skriver deretter
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + 'px';
});

#Hvordan flytte tredjepartsskript bort fra hovedtråden

Tredjepartsskript som ikke er strengt nødvendige, for eksempel chatwidgeter og analysetagger, kan flyttes til en Web Worker med et bibliotek som Partytown, slik at de ikke lenger konkurrerer med hendelseshåndtererne på hovedtråden. Det passer ikke for alle skript, fordi noen tagger trenger synkron tilgang til DOM. Vi går gjennom avveiningene, blant annet hvilke tagger som slutter å virke i en worker, i vår guide til å redusere påvirkningen fra tredjepartsskript i WordPress.

#Hvordan håndtere lange lister

På sider med lange lister, som bloggarkiver, kategorisider i WooCommerce eller datatabeller, betyr det at hundrevis av elementer gjengis på forhånd, at hver senere interaksjon må betale for en stor DOM. Virtualisering gjengir bare elementene nær det synlige området, og oppretter og fjerner elementer mens brukeren scroller. Paginering eller «Last inn flere»-knapper når samme mål med mindre JavaScript.

#Hvordan fikse presentasjonsforsinkelse

Selv om koden din blir raskt ferdig, kan nettleseren fortsatt slite med å tegne resultatet når DOM-en er stor eller stilene er dyre å beregne på nytt.

#Hvordan DOM-størrelse påvirker INP

web.dev påpeker at gjengivelsesarbeidet vokser med DOM-størrelsen, men ikke lineært, og at en stor DOM gjør både den første gjengivelsen og gjengivelsen etter hver interaksjon tregere. To muligheter er å gjøre DOM-en flatere, noe som i WordPress som regel betyr færre omsluttende elementer fra temaet eller sidebyggeren, og å legge til noder først når en interaksjon trenger dem, i stedet for å gjengi hver fane, modal og megameny på forhånd.

#Hvordan bruke content-visibility og contain

content-visibility: auto lar nettleseren hoppe over layout og tegning for et element til det nærmer seg det synlige området. Ifølge web.devs artikkel om content-visibility falt den innledende gjengivelsestiden i demoen med reisebloggen fra 232 ms til 30 ms, og egenskapen har vært Baseline newly available siden 15. september 2025 (Chrome 85, Firefox 125, Safari 18). Kombiner den med contain-intrinsic-size, slik at seksjonene som hoppes over, beholder en plassholderhøyde. Nøkkelordet auto får nettleseren til å huske den sist gjengitte størrelsen:

.comments-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 2000px;
}

.sidebar {
  contain: layout style paint;
}

Egenskapen contain på uavhengige seksjoner, som en sidekolonne eller en kommentarblokk, forteller nettleseren at en endring inne i dem ikke påvirker resten av siden. Det begrenser hvor mye av siden som må beregnes på nytt før neste tegning.

#Hvorfor HTML-gjengivelse på klientsiden øker presentasjonsforsinkelsen

Når HTML strømmes fra serveren, parser nettleseren den i biter og gir fra seg tråden mellom dem. Når et skript bygger store mengder HTML på klienten, gir ikke nettleseren fra seg tråden før den HTML-en er parset og gjengitt, og det kan forsinke neste ramme. I WordPress ser man dette i AJAX-filtre og «Last inn flere»-knapper som setter inn en stor HTML-streng på én gang. Setter du inn mindre porsjoner med en yield mellom hver, holdes rammen etter klikket kort.

#Hva gir dårlig INP i WordPress

Dette er synderne vi oftest møter når en WordPress-side ikke består INP. Ingen av dem er unike for WordPress, men utvidelser gjør det lett å installere dem uten å merke det.

#Tunge sidebyggere

Divi og Elementor legger ofte til dyp nesting i DOM-en, med flere omsluttende elementer rundt hver widget, og det gjør ny layoutberegning etter en interaksjon tregere. Sjekk dybden i Elements-panelet i DevTools før og etter at du erstatter en seksjon med native blokker.

#Chatwidgeter

De fleste skript for live-chat er store forbrukere av hovedtråden som lastes og starter arbeidet sitt på hver side. Et klikk-for-å-laste-mønster, der en lett knapp laster den ekte widgeten først når brukeren ber om hjelp, fjerner det arbeidet fra sider der ingen chatter.

#Karuseller som roterer automatisk

Overganger som utløses med noen sekunders mellomrom, kan falle sammen med brukerens klikk. Er nettleseren midt i en overgang i karusellen når brukeren trykker på en menylenke, må interaksjonen vente på det arbeidet, og det viser seg som input-forsinkelse.

#WooCommerce-skript utenfor butikken

Handlekurvfragmenter og andre butikkskript kan ende opp på sider uten noen butikkfunksjoner, for eksempel blogginnlegg. Sjekk hvilke WooCommerce-skript hver mal legger i kø, og se vår guide til WooCommerce-ytelse for butikkspesifikke løsninger.

#Innebygd Google Maps

Et innebygd Google Maps-kart laster en betydelig mengde JavaScript og holder hendelseslyttere aktive. Et statisk bilde som laster det interaktive kartet ved klikk, sparer den kostnaden for besøkende som aldri bruker kartet.

#Beste verktøy for å måle INP i 2026

For å fikse INP trenger du data fra ekte brukere og en måte å gjenskape den trege interaksjonen i laben.

#CrUX API og PageSpeed Insights

Dokumentasjonen for CrUX API beskriver dataene som et rullerende gjennomsnitt over 28 dager, oppdatert daglig rundt kl. 04:00 UTC og omtrent to dager bak dagens dato. Hver måling kommer med et histogram og en p75-verdi, og du kan filtrere på PHONE, DESKTOP eller TABLET. Bare Chrome-brukere på desktop og Android som har samtykket, bidrar, så Chrome på iOS og andre Chromium-nettlesere som Edge er ikke med i dataene. Sider med lite trafikk har ofte ingen registrering på sidenivå og faller tilbake til data for hele opprinnelsen. PageSpeed Insights og Core Web Vitals-rapporten i Search Console viser de samme feltdataene.

#Hvordan finne det trege skriptet med Long Animation Frames (LoAF)

Long Animation Frames API kom i Chrome 123. Det rapporterer hver ramme der oppdateringen av gjengivelsen forsinkes med mer enn 50 ms, og i motsetning til Long Tasks API grupperer det arbeidet per ramme, noe som stemmer med hvordan INP oppleves. Long Tasks forsvinner ikke: Chrome sier at det ikke finnes planer om å avvikle det, men LoAF gir langt bedre attribusjon. Hver oppføring har duration, blockingDuration, renderStart, styleAndLayoutStart og en scripts-array. Skript som varer lenger enn 5 ms, får attribusjon med sourceURL, sourceFunctionName, invokerType og forcedStyleAndLayoutDuration, og det er ofte nok til å peke ut utvidelsen som har skylden.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('LoAF', entry.duration, entry.blockingDuration,
      entry.scripts.map((s) => ({
        sourceURL: s.sourceURL,
        sourceFunctionName: s.sourceFunctionName,
        duration: s.duration,
        forcedLayout: s.forcedStyleAndLayoutDuration,
      })));
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

LoAF støttes i Chrome og Edge. Firefox og Safari eksponerer det ikke, så attribusjonsdata fra feltovervåking kommer bare fra Chromium-nettlesere.

#Feltdata med attribusjonsbygget av web-vitals

Biblioteket web-vitals har et attribusjonsbygg som forteller deg hvorfor en interaksjon var treg. web.devs guide til å finne trege interaksjoner i felten lister opp feltene: interactionTarget (en CSS-selektor for elementet), interactionType, inputDelay, processingDuration, presentationDelay og, fra versjon 4, longAnimationFrameEntries. Send dem til analyseendepunktet ditt med sendBeacon:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  navigator.sendBeacon('/analytics', JSON.stringify({
    value,
    rating,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
});

Fordelingen på faser viser deg hvor du skal lete: stor input-forsinkelse peker på arbeid som kjører før klikket, lang behandlingstid på håndtererne dine, og stor presentasjonsforsinkelse på DOM-størrelse og gjengivelse.

#Web Vitals-utvidelsen og DevTools

Web Vitals-utvidelsen og Performance-panelet i Chrome DevTools viser INP for hver interaksjon mens du utfører den. Klikk på hver knapp, lenke og hvert skjemafelt i de viktigste malene dine og følg med på verdiene. Labtester på en rask bærbar PC undervurderer forsinkelsen på mobil, så bruk CPU-struping i DevTools når du gjenskaper en treg interaksjon som er rapportert fra felten. Begrensninger som gjelder mobil spesielt, går vi gjennom i vår guide til mobile-first-ytelsesstrategier.

#Hvordan forbedre INP i WordPress steg for steg

#Steg 1: grunnlinjerevisjon

Hent CrUX-data for opprinnelsen din og hovedmalene dine (forside, blogginnlegg, produkt, kategori), og noter INP separat for mobiler og desktop. Begynn med malene som har dårligst p75-verdi og nok trafikk til at det betyr noe.

#Steg 2: finn de trege interaksjonene

Legg attribusjonsbygget av web-vitals til på siden, eller bruk LoAF-observatøren over, og samle inn interactionTarget og fasefordelingen for trege interaksjoner. Da blir «siden føles treg» til en liste med konkrete elementer.

#Steg 3: oversikt over skript

List opp alle skript som lastes på hver mal. Noter for hvert av dem om det trengs på den malen, om det kan bruke strategien defer, om det kan lastes ved interaksjon, og om det kan flyttes til en worker eller fjernes.

#Steg 4: del opp lange oppgaver

For skriptene som LoAF knytter trege rammer til, deler du opp lange oppgaver med scheduler.yield() og reserveløsningen med setTimeout(). Begynn med arbeidet som kjører under eller rett etter en interaksjon.

#Steg 5: reduser kostnaden for DOM og gjengivelse

Gjør de dypeste seksjonene flatere, legg content-visibility: auto på lange områder under folden, og vurder å erstatte seksjoner fra sidebyggeren med native Gutenberg-blokker der DOM-en er dypest.

#Steg 6: kontinuerlig overvåking

La feltovervåkingen fortsette å kjøre etter rettelsene. CrUX trenger 28 dager før en endring vises fullt ut, så sammenlign dine egne feltdata uke for uke og sett opp et varsel når p75 for INP går over 200 ms.

#INP-optimalisering fra WPPoland

Hos WPPoland spesialiserer vi oss på ytelsesmålingen som setter mennesket først.

1. JavaScript-refaktorering: vi skriver om oppblåst kode i utvidelser til lette alternativer som beholder funksjonaliteten uten vekten.
2. LoAF-diagnostikk: vi bruker telemetri fra felten med LoAF-attribusjon for å peke ut skriptet og funksjonen som skaper forsinkelsen.
3. Design av interaktivitet: vi sørger for at den synlige responsen på et klikk kommer først, og at alt annet venter til etter tegningen.

#Konklusjon om INP i WordPress

Core Web Vitals handler om hvordan en bruker føler samhandlingen med merkevaren din. Interaction to Next Paint er tillitens måling. Når siden din svarer umiddelbart, føler brukerne at de har kontroll. Når den henger, føles den ødelagt, og på mobil blir en meny som ikke reagerer, ofte oppfattet som ødelagt. Ingen publisert studie knytter et INP-nivå til en fast prosentandel for fluktfrekvens eller konvertering, så mål dine egne tall før og etter.

Føles WordPress-siden din treg? Kontakt WPPoland for å diagnostisere INP og fikse interaksjonene som holder den tilbake.