INP-optimering — Interaction to Next Paint og Core Web Vitals
INP måler tiden fra brugerinteraktion til næste visuelle opdatering. Det afløste FID som CWV-metrik i 2024 og kræver JavaScript-optimering for at forbedre.
INP — Interaction to Next Paint — er Core Web Vitals-metrikken der måler, hvor hurtigt en side reagerer visuelt på brugerinteraktioner. Det afløste FID i marts 2024 og er det tredelte mål der nu definerer en god brugeroplevelse sammen med LCP og CLS.
Kort fortalt: brugeren klikker, skriver eller trykker — og INP måler, hvornår browseren viser den næste visuelle ændring som svar. Jo kortere tid, jo bedre.
Hvad INP måler — og hvad FID ikke målte
FID (First Input Delay) målte kun forsinkelsen fra brugerens første interaktion til browseren begyndte at behandle den. Det var en snæver metrik der missede to ting: hvad der sker under behandlingen, og alle efterfølgende interaktioner.
INP måler hele interaktionsforløbet — input delay, processing time og presentation delay — og rapporterer den 75th percentil af alle interaktioner på siden. En side med tung JavaScript-processing kan have lavt FID men højt INP, fordi main thread er optaget efter det første klik.
Hvad der forårsager dårlig INP
Størstedelen af INP-problemer stammer fra long tasks på main thread — JavaScript-eksekvering der blokerer browseren i over 50ms. Mens en long task kører, kan browseren ikke behandle brugerinput eller rendere opdateringer. Brugeren ser en frossen side.
De hyppigste årsager:
- Tunge event handlers der gør for meget synkront arbejde (DOM-manipulation, beregninger, API-kald i ét hug)
- Third-party scripts der fylder main thread med analytics, chatwidgets og ad-scripts
- Store JavaScript-bundler der parser og kompilerer lang tid ved load
- Synchronous layout reads og writes (layout thrashing) der tvinger browseren til gentagen reflow
Tre håndtag til at forbedre INP
Bryd long tasks op. JavaScript-opgaver over 50ms bør opdeles — brug setTimeout, requestIdleCallback eller Scheduler API til at fordele arbejde over flere frames. Browseren kan behandle input imellem.
Defer third-party scripts. Analytics, chattools og reklamescripts er hyppige INP-syndere. Indlæs dem asynkront og, hvis muligt, efter load-eventet. Vurder om hvert third-party script er indsatsen værd.
Optimer event handlers. En click-handler der laver 50 DOM-operationer synkront er et INP-problem. Reducer arbejdet i handleren — flyt tunge beregninger ud, batching DOM-ændringer, brug Web Workers til CPU-intensivt arbejde.
Mål altid field data
INP er en field data-metrik. Lighthouse simulerer interaktioner, men den fanger ikke den variation der opstår med rigtige brugere på forskellige enheder og netværksforbindelser. Low-end Android-enheder viser markant dårligere INP end desktop — og det er dem der tæller i CrUX-data.
Brug GSC’s Core Web Vitals-rapport og PageSpeed Insights field data til at se reel INP. Lighthouse er nyttigt til at identificere long tasks og tunge scripts, men ikke til at validere om din INP faktisk er forbedret for rigtige brugere. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
Ofte stillede spørgsmål
- Hvad er en god INP-score?
- Google definerer god INP som under 200ms. 200-500ms er 'needs improvement'. Over 500ms er dårlig. INP er en percentil-metrik — den rapporterer 75th percentile af alle interaktioner på siden, ikke gennemsnittet.
- Hvad afløste INP?
- INP afløste FID (First Input Delay) som Core Web Vitals responsivitetsmetrik i marts 2024. FID målte kun forsinkelsen til første interaktion og kun input delay — ikke processing time eller render delay. INP måler alle interaktioner og hele interaktionsforløbet, hvilket giver et mere retvisende billede.
- Kan et godt Lighthouse-score skjule dårlig INP?
- Ja. Lighthouse måler INP i lab-miljø, ikke field data. INP er svær at simulere i lab fordi den afhænger af rigtige brugerinteraktioner. CrUX (Chrome User Experience Report) og GSCs Core Web Vitals-rapport viser field-INP. Mange sider har grønt Lighthouse-score men rød INP i field data.
- Hvad er de tre faser i en INP-interaktion og hvilken er lettest at forbedre?
- En INP-interaktion består af tre faser: input delay (tid fra brugerhandling til browser begynder behandling), processing time (tid til at eksekvere event handlers) og presentation delay (tid til at rendere den visuelle ændring). Input delay reduceres ved at minimere Long Tasks der optager main thread. Processing time reduceres ved at optimere event handler-kode og undgå synchronous layout thrashing. Presentation delay reduceres ved at undgå style- og layout-intensive ændringer. Processing time er typisk den lettest målrettede fase fordi den er direkte kontrolleret af din kode.
- Hvad er scheduler.yield() og hvordan hjælper det INP?
- scheduler.yield() er en browser-API der giver main thread tilbage til browseren midtvejs i en lang task, så brugerinput kan behandles. Det er den primære teknik til at opdele lange JavaScript-tasks der blokerer INP. Uden scheduler.yield() kører et 200ms JavaScript-stykke som én uafbrudt Long Task — ingen brugerinput behandles i den periode. Med scheduler.yield() kan tasken pauses, brugerinput behandles, og tasken genoptages. Tilgængeligt i Chrome 115+, med setTimeout(fn, 0) som fallback.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning