En god INP-score er 200 millisekunder eller mindre, målt ved 75. percentil af reelle besøg. Mellem 200 og 500 ms “skal siden forbedres”, og over 500 ms vurderes den som dårlig. Google anvender disse grænseværdier separat for mobil og desktop, så en side kan bestå på den ene og dumpe på den anden.
Interaction to Next Paint (INP) måler, hvor hurtigt en side reagerer visuelt, efter at nogen klikker, trykker eller taster. Den blev en Core Web Vital den 12. marts 2024 og erstattede First Input Delay (FID), som kun målte forsinkelsen, før den første interaktion blev håndteret. INP ser på interaktionerne gennem hele besøget og rapporterer en af de langsomste.
I praksis betyder “god” tre ting: mindst 75 % af de reelle besøg får en reaktion inden for 200 ms, du måler med feltdata frem for en enkelt labtest, og du har en vis margin under grænsen, så et nyt script eller en travl udsalgsuge ikke skubber dig over.
Denne guide forklarer, hvordan scoren beregnes, hvor du finder din, hvorfor nogle værktøjer ikke viser noget, og hvordan du diagnosticerer og retter en langsom INP uden at gætte.
Hvad er grænseværdierne for INP?
Google bruger tre intervaller, og grænseværdierne er vigtige. Tabellen nedenfor afspejler web.dev’s dokumentation om INP og rapporten Core Web Vitals i Search Console.
| Vurdering | INP-værdi | Hvad det betyder for brugerne |
|---|---|---|
| God | 200 ms eller mindre | Klik og tryk føles øjeblikkelige ved de fleste besøg |
| Skal forbedres | Over 200 ms og op til 500 ms | Mærkbar forsinkelse på menuer, filtre, formularer eller læg i kurv |
| Dårlig | Over 500 ms | Brugerne klikker igen, tror siden er i stykker, eller forlader den |
Er præcis 200 ms godt? Ja. web.dev definerer godt som “below or at” 200 ms, så 200 består, og 201 gør ikke. Samme logik gælder ved 500 ms: præcis 500 tæller stadig som skal forbedres, og alt derover er dårligt.
Til sammenligning bruger de to andre Core Web Vitals i Search Console grænseværdier for LCP på 2,5 s og 4 s og for CLS på 0,1 og 0,25. INP er den eneste, der måles i millisekunders reaktionsevne i stedet for indlæsning eller visuel stabilitet.
Hvordan beregnes din INP-score egentlig?
INP beregnes først pr. besøg og opsummeres derefter på tværs af besøg ved 75. percentil. Når du forstår begge trin, forklarer det det meste af den forvirring, folk har om tallet.
Under et besøg tager browseren tid på hvert klik, tryk og tastetryk. Hver interaktion har tre dele:
- Input delay: ventetiden, før dine event handlers starter, typisk fordi hovedtråden er optaget af andet arbejde.
- Processing duration: den tid, dine event handlers tager om at køre.
- Presentation delay: tiden fra handlerne er færdige, til browseren tegner det næste frame.
Besøgets INP er den længste af disse interaktioner, med én undtagelse for travle sider: web.dev oplyser, at én af de højeste interaktioner ignoreres for hver 50 interaktioner, så en enkelt usædvanlig spids i en lang session ikke definerer scoren. Hover, scroll og zoom tælles ikke som interaktioner.
Derefter samles værdierne fra alle besøg, og 75. percentil rapporteres. Det er “75 %-reglen”: din side er god, hvis mindst tre ud af fire besøg havde en INP på 200 ms eller mindre. Den resterende fjerdedel kan være langsommere, uden at siden dumper, og derfor er det vigtigere at rette din typiske langsomste interaktion end at jagte et sjældent særtilfælde.
Et besøg, hvor brugeren aldrig klikker, trykker eller skriver, giver slet ingen INP-værdi. Sider, som folk for det meste læser, som lange artikler, har ofte færre INP-data end sider, folk betjener, som kategorifiltre eller checkout.
Er en god INP-score forskellig på mobil og desktop?
Grænsen er den samme, 200 ms, men resultaterne er meget forskellige. Telefoner har langsommere processorer, så den samme JS-kode tager længere tid at køre, og Google rapporterer mobil og desktop separat i både PageSpeed Insights og Search Console.
HTTP Archives Web Almanac 2024, kapitlet om performance, viste, at 74 % af websites på mobil og 97 % af websites på desktop havde god INP. Med andre ord er INP primært et mobilproblem. Hvis din desktoprapport er grøn og din mobilrapport gul, er det det normale mønster, ikke en målefejl.
Prioritér den enhed, der giver din trafik og omsætning. For de fleste forbrugersites er det mobil, hvilket også betyder, at du skal teste på en Android-telefon i mellemklassen eller med CPU-throttling i Chrome DevTools, ikke på en hurtig bærbar. Vores guide til mobil SEO dækker det bredere mobilbillede.
Hvor kan du tjekke din INP-score?
Brug feltdata til at vide, om du består, og labværktøjer til at finde ud af, hvorfor du ikke gør. Hvert værktøj besvarer et andet spørgsmål.
| Værktøj | Datatype | Bedst til |
|---|---|---|
| Search Console, rapporten Core Web Vitals | Felt (CrUX), grupperede URL’er | At se, hvilke grupper af sider der dumper på mobil eller desktop, og at validere rettelser |
| PageSpeed Insights | Felt (CrUX, de seneste 28 dage) plus labtest i Lighthouse | Hurtigt tjek af én URL eller hele domænet |
| CrUX API, BigQuery eller CrUX Vis | Felt (CrUX) | Udvikling over tid og sammenligning med konkurrenter |
| Real user monitoring (RUM), for eksempel JS-biblioteket web-vitals | Felt, dine egne besøgende | At finde ud af, hvilket element og hvilken interaktion der gav en langsom INP |
| Performance-panelet i Chrome DevTools | Lab | At optage en interaktion og se, hvilken opgave der blokerede den |
| Lighthouse (navigationstilstand) | Lab | Total Blocking Time som en grov indikator; måler ikke INP under en test af sideindlæsning |
Googles egen dokumentation er klar om hierarkiet: feltdata fra reelle brugere er den bedste måde at måle INP på. Total Blocking Time kan antyde problemer, men web.dev beskriver det som en rimelig indikator, “not a substitute for INP”. En perfekt Lighthouse-score betyder ikke, at du består INP.
Hvorfor viser PageSpeed Insights ingen INP-score for nogle sider?
Som regel fordi der ikke er nok data fra reelle brugere for den URL. PageSpeed Insights henter feltdata fra Chrome UX Report (CrUX), som kun omfatter sider, der er offentligt tilgængelige og har nok besøgende. Google offentliggør ikke den præcise trafikgrænse.
Når en enkelt URL mangler data, forsøger PageSpeed Insights at falde tilbage på data for hele domænet (origin). Hvis domænet heller ikke har data, viser feltsektionen “No Data”, og kun Lighthouses labresultater er tilbage. Andre almindelige årsager:
- Siden er ny og har endnu ikke samlet 28 dages besøg
- Siden ligger bag et login eller er blokeret for indeksering, så CrUX medtager den ikke
- De besøgende interagerer sjældent med siden, så der er få INP-målinger, selv med god trafik
Den praktiske løsning er at tilføje din egen RUM. Funktionen onINP i biblioteket web-vitals rapporterer INP fra hvert besøg, og attribution-versionen fortæller dig, hvilket element der var involveret, og hvor lang tid hver af de tre faser tog. Det giver dig data på sider med lav trafik og, endnu vigtigere, konteksten til at fejlfinde.
Hvordan finder du ud af, hvad der gør INP langsom?
Diagnosticér først fasen, derefter årsagen. Hver fase peger på en anden type løsning.
| Langsom fase | Typisk årsag | Hvor du skal kigge |
|---|---|---|
| Input delay | Hovedtråden er optaget af andre scripts: tag managers, chatwidgets, A/B-test, tung hydrering under indlæsning | Lange opgaver i DevTools omkring tidspunktet for klikket |
| Processing duration | Event handleren laver for meget: filtrering af en stor produktliste, analysekald, synkron lagring, gen-rendering af hele komponenter | Handleren for click eller keydown i Performance-panelet |
| Presentation delay | Stor DOM, dyr genberegning af stil og layout, rendering af store bidder HTML med JS | Posterne “Recalculate Style” og “Layout” efter handleren |
En enkel arbejdsgang:
- Find i Search Console de URL-grupper, der har “INP issue” på mobil.
- Åbn én eksempel-URL, og identificér de interaktioner, folk faktisk udfører: menuen, et filter, størrelsesvælgeren, læg i kurv, et formularfelt.
- Sæt CPU-throttling i Chrome DevTools, start en Performance-optagelse, udfør interaktionen, og stop.
- Kig efter lange opgaver, som web.dev definerer som opgaver over 50 ms, og notér, hvilket script de kommer fra.
- Gentag interaktionen, mens siden stadig indlæses. Hovedtråden har ofte travlest dér, og det er netop dér, reelle brugere klikker.
Hvordan forbedrer du en dårlig INP-score?
Lav mindre arbejde på hovedtråden i interaktionsøjeblikket, og giv browseren mulighed for at tegne hurtigere. Løsningerne nedenfor er nogenlunde ordnet fra nemmest til mest teknisk.
Gennemgå tredjepartsscripts først
På mange marketingsites er den største INP-omkostning ikke din egen kode. Chatwidgets, heatmaps, samtykkeværktøjer, anmeldelseswidgets og flere analysetags konkurrerer alle om hovedtråden. List alle scripts i din tag manager, fjern det, ingen bruger, og udskyd ikke-nødvendige tags, til siden er indlæst, eller til efter den første interaktion.
Vis feedback først, og gør resten bagefter
Opdatér grænsefladen med det samme (åbn menuen, vis spinneren, markér knappen som trykket), og kør derefter det langsommere arbejde i en separat opgave. Det kaldes at give hovedtråden fri (yielding). En lille hjælpefunktion som den nedenfor bruger scheduler.yield(), hvor browseren understøtter det, og falder tilbage på setTimeout andre steder:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Ifølge web.dev understøttes scheduler.yield() i Chrome og Edge fra version 129 og i Firefox fra version 142, men ikke i Safari, og derfor er fallbacken vigtig.
Del lange opgaver op
Enhver opgave over 50 ms blokerer input. Del lange løkker, for eksempel behandling af hundredvis af produkter, op i bidder med en yield imellem. Bed din udvikler om at gennemgå hydreringen i JS-frameworks, som ofte kører som én stor opgave under indlæsningen.
Hold DOM’en slank
Hvert ekstra element gør genberegningen af stil og layout langsommere. Sideinddel eller virtualisér lange lister, fjern skjulte dublerede menuer til mobil og desktop, og brug CSS-egenskaben content-visibility til at springe rendering af sektioner uden for skærmen over.
Undgå layout thrashing
Når du læser en layoutværdi, for eksempel et elements højde, lige efter at have ændret stilarter, tvinger du browseren til at beregne layoutet med det samme. Gruppér læsninger før skrivninger i dine event handlers.
Tjek igen efter hver ændring
Feltdata tager tid om at flytte sig. CrUX i PageSpeed Insights dækker de seneste 28 dage, og valideringen i Search Console kører med et overvågningsvindue på 28 dage. Brug din egen RUM til at bekræfte rettelsen inden for få dage, og lad derefter Googles rapporter indhente det.
Påvirker INP placeringerne i SEO?
INP er en del af Core Web Vitals, som ifølge Google flugter med det, Googles centrale rankingsystemer søger at belønne, men det er ikke en genvej til toppen af resultaterne. Google anbefaler “highly” gode Core Web Vitals for at få succes i Søgning, mens relevans og indholdskvalitet fortsat er afgørende.
Det stærkeste argument for at rette INP er kommercielt. Langsomme filtre, forsinkede læg i kurv-knapper og formularer, der ikke reagerer, koster direkte konverteringer, især på mobil. Se en god INP-score som et grundniveau for et brugbart site, og læg derefter hovedparten af din SEO-indsats i indhold og struktur. Vores guide til SEO til e-handel viser, hvor performance passer ind i en webshops prioriteter.
Hvad bør du sigte efter?
Sigt efter en INP ved 75. percentil, der ligger komfortabelt under 200 ms på mobil, ikke bare lige under. En side på 190 ms består i dag, men kan dumpe efter ét nyt marketingtag eller en trafiktop fra langsommere enheder. En buffer på flere titals millisekunder giver dit team plads til at tilføje funktioner.
Sæt mål pr. skabelon frem for pr. URL: kategorisider, produktsider, artikler, formularer og checkout. Ret først den skabelon, der har mest trafik og dårligst INP, og gør INP til en del af tjeklisten ved releases, så nye scripts gennemgås, før de går live.
Hvor passer Marketer Coffee ind?
Marketer Coffee er et AI SEO- og GEO-bureau; vi behandler performance som en del af teknisk SEO sammen med arkitektur, strukturerede data og indhold. Resultater fra andre brancher:
- Aldi.pl (detailhandel). Organiske klik steg fra 367.127 til 852.724 om måneden på 12 måneder (+132 %) med produktindhold, Product-schema, en slankere arkitektur og samlede butiksdata. Læs kundecasen om Aldi.
- IDG-Online (videoovervågning og affiliate). Fra 500 til over 30.000 månedlige klik på 16 måneder i konkurrence med Ceneo, MediaExpert og MediaMarkt med rankingsider, Q&A-indhold og schema. Læs kundecasen om IDG-Online.
Hvem vi passer til: sites, hvor hastighed, struktur og indhold kræver én samlet plan, ofte webshops eller internationale sites. Hvem vi ikke passer til: teams, der kun har brug for en performance-ingeniør til en enkeltstående omskrivning af et frontend-framework; hyr en specialiseret udvikler til det. Hvis du vil se, hvordan dit site klarer sig i AI-søgning såvel som i Google, så start med vores gratis analyse af AI-synlighed.
Ofte stillede spørgsmål om INP-scoren
Hvad er en god INP-score?
200 millisekunder eller mindre ved 75. percentil af reelle sidebesøg, målt separat for mobil og desktop. Over 200 ms og op til 500 ms skal forbedres; over 500 ms er dårligt.
Hvornår erstattede INP FID?
INP blev en Core Web Vital den 12. marts 2024 og erstattede First Input Delay. Search Console fjernede FID samme dag.
Hvorfor er min INP god på desktop, men dårlig på mobil?
Telefoner har langsommere processorer, så de samme scripts tager længere tid at køre. Web Almanac 2024 fandt god INP på 97 % af websites på desktop, men kun på 74 % af websites på mobil.
Kan Lighthouse måle INP?
En standardtest af sideindlæsning i Lighthouse omfatter ikke brugerinteraktioner, så den kan ikke rapportere INP. Den viser Total Blocking Time, som er en grov indikator. Brug feltdata fra CrUX eller din egen RUM til at vurdere INP.
Hvor lang tid går der, før en INP-rettelse vises i Search Console?
Feltdata dækker et løbende vindue på 28 dage, og valideringen i Search Console overvåger i 28 dage, så regn med omkring fire uger, før rapporterne fuldt ud afspejler en rettelse. Din egen RUM kan bekræfte den hurtigere.
Hvad er den korte version?
God INP er 200 ms eller mindre for mindst 75 % af de reelle besøg på hver enhedstype. Find de skabeloner, der dumper, i Search Console, optag de langsomme interaktioner i DevTools, afgør hvilken fase der er langsom, og ret årsagen: færre tredjepartsscripts, hurtigere feedback, kortere opgaver og en mindre DOM. Giv dig selv en buffer bagefter.
Hvis du vil have en second opinion på, hvor performance ligger blandt dine SEO-prioriteter, så book en gratis konsultation.
Kilder: web.dev, “Interaction to Next Paint (INP)” (grænseværdier, 75. percentil, interaktionsfaser, regel for afvigere, TBT som indikator); web.dev, blogindlæg af Jeremy Wagner og Rick Viscomi om INP som Core Web Vital den 12. marts 2024; web.dev, “Optimize Interaction to Next Paint” og “Optimize long tasks” (lange opgaver på 50 ms, understøttelse af scheduler.yield); Google Search Console Hjælp, rapporten Core Web Vitals (grænseværdier, validering over 28 dage); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, CrUX-metodik og CrUX i PageSpeed Insights (berettigelse, vindue på 28 dage, fallback til origin); HTTP Archive, Web Almanac 2024, kapitlet om performance; Marketer Coffee, kundecases om Aldi og IDG-Online (andre brancher).
