INP

Kort fortalt: INP handler om hvor hurtigt et klik/tap “føles” responsivt.

Hvad måler det?

• Tiden fra en brugerinteraktion til næste visuelle opdatering.

Hvorfor betyder det noget?

• Langsom respons giver friktion og gør UX tung.

Hvilken indflydelse har INP?

INP rammer især den del af oplevelsen der sker efter siden er “kommet frem”: menuen åbner, en knap reagerer, en formular validerer, en accordion folder ud, eller et filter opdaterer et produktgrid.

Når INP er dårlig, opleves siden typisk som:

• “tung” på mobil, selvom den måske loader hurtigt
• hakkende ved scroll/klik
• uforudsigelig (klik registreres, men UI opdaterer sent)

Det kan påvirke:

• engagement (folk gider ikke interagere)
• konvertering (formularer og checkout føles træge)
• support/tiltro (oplevelsen virker “buggy”)

Hvornår blev INP indført?

INP blev introduceret som en mere brugernær måling end FID, fordi FID i praksis kun målte en lille del af interaktioner (første input). Over tid blev INP den primære interaktivitetsmåling i Core Web Vitals.

Det vigtige praktisk set er: INP kræver at man tænker i samlet interaktion og ikke kun “første klik”.

Hvad er “god” INP?

Tommelregler:

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

For sites med tunge UI’er, meget tredjepart eller store JS-bundles kan det være svært at ramme 200 ms konsekvent på lav-end mobil. Derfor er prioritering og måling vigtig.

Hvordan måler man INP?

INP kan måles på to niveauer:

Feltdata (rigtige brugere)

• Search Console (Core Web Vitals rapport)
• CrUX (Chrome UX Report) via værktøjer

Feltdata er “facit” for hvordan brugere oplever dit site, men det er ofte svært at debugge direkte.

Lab og debugging

• Chrome DevTools Performance (find long tasks og event handlers)
• Lighthouse (indikatorer og hints)
• Real User Monitoring (RUM) hvis du instrumenterer selv

Det man typisk vil finde er:

• lange tasks før/under interaktionen
• tunge event handlers (klik/scroll/input)
• layout thrashing (måling/DOM writes i forkert rækkefølge)

Typiske årsager

• For meget JavaScript på main thread
• Lange tasks (tunge event handlers)
• Tredjeparts scripts

Typiske forbedringer

• Reducér/udskyd JavaScript
• Split bundler og fjern unødvendige biblioteker
• Flyt arbejde væk fra main thread hvor muligt

Praktiske optimeringer (det der oftest flytter mest)

1) Reducér JavaScript i “critical path”

Hvis du sender meget JS ved første load, får du ofte både dårlig INP og dårlig LCP.

Konkrete greb:

• fjern features der ikke bruges
• byt tunge biblioteker ud med små alternativer
• undgå at initialisere widgets før de er synlige

2) Code splitting og lazy loading af UI

Konkrete greb:

• split per route og per feature (filter, søgning, editor)
• load komponenter ved interaktion (fx når modal åbnes)

3) Tredjepart: mål og skær hårdt

Tredjepart (tracking, chat, consent, AB-test) er en klassisk INP-killer.

Konkrete greb:

• udskyd scripts til efter consent eller efter load
• load kun på sider der har behov
• erstat tunge scripts med server-side tracking eller lettere alternativer

4) Find og fjern long tasks

Konkrete greb:

• bryd store loops op
• debounce/throttle input events
• undgå at gøre tungt arbejde på hver scroll

5) DOM-arbejde: undgå layout thrashing

Typisk fejl:

• læs layout (getBoundingClientRect) og skriv styles i skiftevis rækkefølge

Konkrete greb:

• batche DOM reads, derefter DOM writes
• brug CSS til animationer når det er muligt (transform/opacity)

Tjekliste

• Fjernet/udskudt tredjepart i critical path
• Code splitting implementeret
• Ingen tydelige long tasks under interaktioner
• Input/scroll events er throttle/debounce hvor relevant
• Store UI-områder initialiseres først når de bruges