INP vs FID

Hvis du har arbejdet med Core Web Vitals i et stykke tid, har du sikkert oplevet denne situation:

• PageSpeed Insights/Lighthouse ser “ok” ud
• men rigtige brugere oplever stadig at siden føles tung ved klik og input

Det er netop den type problem, INP er designet til at fange. Artiklen her forklarer hvorfor Google skiftede fra FID til INP, hvad du konkret skal optimere, og hvordan du debugger uden at gætte. Den spiller sammen med guiden om INP og JavaScript og Lighthouse vs CrUX - især fordi INP ofte er værre i felt end i lab.

Fem klassiske årsager til dårlig INP

1. Store JavaScript-bundter der parser og kører længe på main thread (framework, alt-for-mange dependencies).
2. Lange tasks (>50 ms) der blokerer input - ofte ét script, én handler eller én tredjepartsbatch.
3. Tunge event handlers (filter, søgning, keypress) der opdaterer for meget DOM per tick.
4. Tredjeparts-scripts (analytics, A/B, chat, consent) der initialiserer tidligt eller reagerer på samme tid som brugerklik.
5. Hydration og store re-renders efter interaktion - især på komplekse menuer og produktlister.

Hvad er skiftet?

Skiftet fra FID til INP lyder som en lille teknisk detalje, men i praksis ændrer det hvad man skal optimere for, hvis man vil have en side der føles hurtig og responsiv.

FID (First Input Delay) målte primært hvor lang tid der gik, fra brugeren interagerede første gang, til browseren kunne starte med at håndtere interaktionen. Det var nyttigt, men det havde to store svagheder:

1. Det handlede kun om “første interaktion”.
2. Det sagde ikke meget om hvad der sker, når siden er fuld af komponenter, scripts og løbende interaktioner.

INP (Interaction to Next Paint) ser bredere på interaktioner og er mere brugernært: det måler hvor lang tid der går fra en interaktion til næste visuelle opdatering. Det er sværere at “optimere på papiret”, men bedre til at afspejle den reelle oplevelse.

Hvorfor skiftede Google fra FID til INP?

Der er en meget praktisk grund: Mange sites kunne have “fin” FID, men stadig føles langsomme og irriterende ved brug.

Eksempel:

• Første klik på “menu” sker hurtigt (FID ser fint ud)
• Men efterfølgende klik, filtrering, formular-input og scrolling er hakker og forsinket (brugeren oplever langsomhed)

INP fanger den slags problemer.

En hurtig sammenligning: FID vs INP

Her er den praktiske forskel, uden marketing:

• FID: “Hvor længe gik der før browseren kunne begynde at håndtere første input?”
• INP: “Hvor lang tid tog det fra input til næste synlige opdatering – på tværs af interaktioner?”

Det betyder, at INP er tættere på det brugeren oplever som “respons”.

Hvad måler INP mere konkret?

En interaktion består groft af:

• input (klik/tap/keydown)
• event handler-kode (JavaScript der kører)
• layout/style (browseren regner layout ud)
• paint (browseren tegner næste frame)

INP bliver høj, når der opstår ventetid i en eller flere af de faser. I praksis er synderen ofte: for meget JavaScript på main thread.

Hvad giver typisk høj INP i virkeligheden? (eksempler)

For mange sites er det ikke “en stor fejl”, men mange små ting der tilsammen gør UI tungt.

Eksempel 1: Menu åbner langsomt

Typisk årsag:

• klik handler triggere et stort state update
• navigation re-renderer mange komponenter
• et stort script kører samtidig (tredjepart)

Eksempel 2: Formular-input “lagger”

Typisk årsag:

• hver keypress triggere validering og DOM-opdatering
• for meget arbejde i input handler

Eksempel 3: Filter/produktgrid føles tungt

Typisk årsag:

• filter opdaterer mange elementer
• layout beregnes ofte
• billeder/komponenter loader samtidig

Hvad er “god” INP?

Tommelregler:

• God: under ca. 200 ms
• Skal forbedres: 200–500 ms
• Dårlig: over 500 ms

På mobil er det typisk sværere at ramme 200 ms, især hvis du har mange tredjeparts scripts eller tunge UI-komponenter.

Hvad optimerer man så?

Her er de områder der næsten altid flytter mest.

1) Reducér JavaScript-arbejde på main thread

Hvis main thread er travl, kan browseren ikke reagere hurtigt.

Konkrete greb:

• fjern unødvendige features og scripts
• reducer bundle-størrelse (dependencies er ofte det største problem)
• undgå at initialisere alt ved første load

2) Fjern long tasks

Long tasks (typisk >50 ms) gør interaktioner “sticky”. Når en lang task kører, kan input events ikke håndteres i tide.

Konkrete greb:

• bryd store loops op
• batch DOM reads og DOM writes (undgå layout thrashing)
• debounce/throttle input og scroll handlers

3) Minimer tredjeparts scripts

Tracking, chat, consent og AB-testing kan være store INP-dræbere, især hvis de loader tidligt.

Konkrete greb:

• load efter consent eller efter load
• kun på sider hvor det er nødvendigt
• skift tunge løsninger ud med lettere alternativer

En konkret debug-proces (så du ikke gætter)

Hvis du vil løse INP effektivt, så undgå at “optimere alt”. Gør i stedet dette:

Trin 1: Vælg 1–2 kritiske interaktioner

Eksempler:

• åbne menu
• submit formular
• ændre filter

Trin 2: Optag en Performance trace mens du gør interaktionen

I DevTools:

• start optagelse
• udfør interaktionen 2–3 gange
• stop optagelse

Trin 3: Find hvor tiden går

Kig efter:

• long tasks omkring interaktionen
• scripts der bruger meget tid (scripting)
• layout og style recalculations

Trin 4: Fjern den største årsag først

Typisk giver det størst effekt at:

• fjerne/udskyde tredjepart
• reducere bundles
• optimere den konkrete handler

Trin 5: Mål igen

INP-arbejde uden “mål → ændring → mål” ender ofte i tilfældige forbedringer.

En praktisk “INP-first” prioritering

Hvis målet er at få bedre INP uden at overoptimere:

1. Identificér de vigtigste interaktioner (menu, søgning, filter, formular)
2. Optag en performance trace i DevTools under interaktionen
3. Find long tasks og hvad der kører (ofte tredjepart eller stor app-kode)
4. Fjern/udskyd/erstat den værste årsag
5. Gentag – og mål effekten

Hvordan hænger INP sammen med LCP og resten af performance?

INP og LCP har ofte samme rod: for meget arbejde tidligt på main thread.

• Høj TTFB betyder at alt starter sent - inklusive parsing af HTML og hentning af scripts - men INP bliver først et problem når brugeren faktisk interagerer. Du kan derfor have “ok” LCP efter første load og stadig dårlig INP, hvis tunge scripts venter og kører omkring klik.
• Hvis du loader store JS-bundles, kan både LCP og INP blive dårligere.
• Hvis du udskyder alt JS for at “score” i LCP, kan interaktiviteten blive dårlig, hvis UI’et stadig kræver JS og hydration fylder.

Derfor er en god strategi at:

• minimere JS ved første load
• men stadig sikre at kritiske interaktioner er lette og hurtige
• måle INP i felt eller med realistisk RUM, ikke kun Lighthouse

Mobil vs desktop

Desktop-Lighthouse kan se pæn ud fordi CPU og køling er bedre, og du ofte tester uden rigtige extensions. Mobil-felt strammer INP: langsommere CPU, mere JavaScript relativt set, og touch-interaktioner der rammer de samme handlers. Prioritér derfor mobil-DevTools (CPU-throttling) og feltdata i Search Console - ikke kun én grøn desktop-kørsel.

Typiske symptomer på dårlig INP

• klik registreres, men UI opdaterer sent
• input felt “lagger” når man skriver
• scroll hakker når komponenter opdaterer
• dropdowns og modals åbner langsomt

Debug-checkliste (hurtig)

• Vælg 1–2 flows (menu, filter, kurv) og gentag dem i Performance-profilering.
• Marker long tasks omkring klik - notér filnavn/script (ofte tredjepart eller én stor chunk).
• Sammenlign mobil og desktop (throttling + langsom 4G) - samme kode, forskellig realitet.
• Tredjepart: midlertidigt blokér i DevTools eller staging og mål INP igen.
• WordPress/buildere: tjek om ét plugin injicerer globale scripts på alle sider; brug beting indlæsning hvor muligt.
• Bundle: kør coverage/lighthouse bundle-audit og split det der ikke behøves ved første interaktion.

Relateret på sitet

• Ordbog: INP og long task
• Guide: Forbedr INP ved at reducere JavaScript
• Blog: Hvad er Core Web Vitals?

Relaterede blogindlæg

Hvordan tredjeparts scripts gør din hjemmeside langsom

2026-03-26

Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.

Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse

2026-03-24

Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.

5 grunde til at din hjemmeside er langsom og hvad du gør ved det

2025-11-14

Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.

Sådan prioriterer du hastighedsoptimering uden at spilde tid

2026-03-27

Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.

Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt

2026-03-20

Få en praktisk forklaring på LCP, INP og CLS. Lær hvad Core Web Vitals måler, hvorfor de betyder noget, og hvordan du kommer i gang.

Lighthouse vs CrUX: hvorfor tallene ikke matcher og hvad du gør

2026-02-28

Forstå forskellen på Lighthouse og CrUX. Lær hvorfor labdata og feltdata kan vise noget forskelligt, og hvordan du bruger dem rigtigt.

FAQ

Kan man “fikse” INP uden at ændre kode?

Nogle gange kan du flytte INP ved at fjerne/udskyde tredjepart eller ændre load-strategi. Men ofte kræver det også oprydning i frontend-koden, bundles og de konkrete event handlers.

Skal man altid skifte framework for at få god INP?

Nej. Start med at reducere hvor meget JavaScript der sendes, og hvad der kører under kritiske interaktioner. Code splitting, færre dependencies og mindre hydration flytter ofte mere end et framework-skift.

Hvordan ved jeg hvilken interaktion der trækker INP ned?

Brug feltdata (Search Console/CrUX eller RUM) til at se om INP er et problem, og optag derefter en DevTools Performance-trace på de vigtigste flows (menu, filter, formular) for at finde long tasks og tunge handlers.

Næste skridt i samme emne

Fortsæt fra forklaring til handling med guides, emner og ordbog.

Se relaterede guidesGå til emneoversigtSlå begreb op i ordbogLæs om metode og kilder