Indhold
  1. Hvad INP dækker, og hvad det ikke dækker
  2. Find jeres tal
  3. De tre dele af ventetiden
  4. Det, der typisk er galt på en WordPress-side
  5. Hvad I kan forvente
  6. Tjekliste
  7. Kilder

INP, Interaction to Next Paint, er tiden, fra en besøgende trykker på noget, til siden viser, at den har forstået det. Menuen åbner, filteret skifter, knappen ændrer farve. Google regner et INP på højst 200 millisekunder for godt. Over 500 millisekunder er dårligt.

Det er det af de tre Core Web Vitals, der er sværest at se i en almindelig hastighedstest, fordi testen ikke trykker på noget. Og det er det, der oftest skyldes noget, I ikke selv har lagt på siden. Her er, hvordan I finder jeres tal, hvad der typisk gør en WordPress-side langsom til at svare, og hvad I gør ved det.

Hvad INP dækker, og hvad det ikke dækker

Browseren noterer hver gang, den besøgende klikker, trykker eller taster, hvor lang tid der går, til det næste billede er tegnet på skærmen. Scroll, zoom og det at holde musen over noget tæller ikke. INP er i praksis det langsomste af alle trykkene i hele besøget. På sider med rigtig mange interaktioner ses der bort fra ét af de langsomste tryk for hver 50 interaktioner, men de fleste besøg har færre end 50, så det er som regel det dårligste tryk, der tæller. Én langsom menu er altså nok.

Tallet, Google bruger, kommer fra rigtige besøg: den 75. percentil over 28 dage, opgjort for mobil og desktop hver for sig. INP afløste FID den 12. marts 2024. FID så kun på det første tryk og kun ventetiden, før siden begyndte at reagere. INP ser på alle tryk og hele tiden, til svaret kan ses. Grænserne står hos web.dev.

INP siger ikke noget om, hvor hurtigt siden loader. En side kan vise overskriften på et sekund og stadig bruge et halvt sekund på at åbne menuen. Det første er LCP. Det andet er INP.

Find jeres tal

Start i Search Console under Core Web Vitals. Rapporten viser, hvilke grupper af sider der fejler på INP på mobil og desktop. Det er feltdata fra rigtige besøg. Har siden for få besøg, er der ingen data, og det er ikke det samme som et godt tal.

Åbn derefter én side fra gruppen i PageSpeed Insights, fx gennem vores hastighedstest. Øverst står INP fra feltdata, hvis der er nok. Laboratorietesten nedenunder kan ikke give et INP-tal, fordi den ikke trykker på noget. Den viser i stedet Total Blocking Time, som er den tid, siden under indlæsning er for optaget til at svare. Et højt TBT er et varsel om et dårligt INP, men ikke det samme.

Vil I se de konkrete tryk, så åbn siden i Chrome, start en optagelse i udviklerværktøjets Performance-fane, og brug siden, som en kunde ville: åbn menuen, brug et filter, udfyld et felt, læg i kurv. Optagelsen viser hvert tryk og hvor lang tid det tog. Performance-panelet viser også jeres lokale INP sammen med LCP og CLS, så snart I begynder at bruge siden, og en liste over de tryk, det har fanget. Test på en almindelig telefon eller med CPU-drøvling slået til. Jeres egen computer er hurtigere end jeres kunders telefoner. I HTTP Archives Web Almanac 2025 havde 97 % af websites et godt INP på desktop, men kun 77 % på mobil.

De tre dele af ventetiden

Et tryk, der tager 600 millisekunder, er ikke ét problem. web.dev deler tiden i tre, og det er værd at vide, hvilken del der fylder:

  1. Ventetid, før trykket behandles: browseren er optaget af noget andet, typisk et script, der stadig kører. Trykket står i kø.
  2. Selve behandlingen: den kode, der kører som svar på trykket. Åbner menuen med tre linjer, eller kører den et helt script?
  3. Ventetid, før det tegnes: browseren skal regne layoutet igennem og tegne det nye billede. Det tager længere, jo mere der ændrer sig, og jo større siden er.

På de fleste WordPress-sider er det den første del, der fylder. Siden er stadig i gang med at køre scripts, når den besøgende trykker, og trykket må vente.

Hovedtråden som en række scripts, hvor et tryk venter i kø, til scriptet er færdigt. Under den de tre dele af ventetiden: venter, behandler, tegner.
Browseren gør én ting ad gangen. Trykket står i kø, til det script, der kører, er færdigt. Det er typisk dér, det meste af INP ligger. Illustration i fuld størrelse.

Det, der typisk er galt på en WordPress-side

For mange scripts, der kører for længe

Browseren kan kun gøre én ting ad gangen. Hver gang et script kører i mere end 50 millisekunder uden pause, kan den ikke svare på et tryk imens. Et tema, en page builder, en slider, et popup-plugin og en håndfuld sporingsscripts kan tilsammen holde browseren optaget i flere sekunder efter, at siden ser færdig ud. Åbn Performance-fanen, og se efter de lange, røde blokke. Det er dem, der står i vejen.

Det nemmeste er at fjerne det, siden ikke bruger. Et plugin, der kun bruges på én side, bør ikke loade på alle. Det, der skal blive, bør loade med defer, så det ikke blokerer, mens siden bygges.

Tredjeparter: chat, samtykke, sporing

Chatvinduet, cookiebanneret, Tag Manager og de tags, der ligger i den, er ofte det tungeste på siden, og de er ikke jeres kode. Kig i Tag Manager efter tags, ingen bruger længere. Lad chatten loade, når den besøgende har været på siden et par sekunder, eller når der scrolles, i stedet for med det samme. Flyt det, der kan flyttes, ud af hovedtråden, hvor det er muligt. Det, der ikke giver værdi, skal væk.

Menuen og knapperne venter på JavaScript

En menu, der åbner ved at et script tilføjer en klasse, svarer først, når scriptet er hentet og kørt. Til et simpelt klik er det unødvendigt. Brug CSS, hvor CSS kan: en menu kan åbne med :focus-within eller et details-element, en fane kan skifte uden et bibliotek. Så svarer siden, også mens scripts stadig loader. Det hænger sammen med semantisk HTML: et rigtigt button-element virker, før noget script er kørt.

Trykket gør for meget på én gang

Et filter, der ved hvert klik henter nye produkter, bygger hele listen om og opdaterer tre andre dele af siden, giver et langt tryk. Del arbejdet op: vis først, at trykket er registreret, fx ved at markere filteret, og lad resten følge efter. Browseren får så lov til at tegne imellem. Det samme gælder søgefelter, der søger ved hvert tastetryk. Vent, til der er en pause i indtastningen.

Siden er for stor

Jo flere elementer der er på siden, jo længere tid tager det at regne layoutet igennem, hver gang noget ændrer sig. En side bygget med en page builder kan nemt have 3.000–5.000 elementer, hvor 1.000 ville gøre det samme. Det ses i den tredje ventetid. Fjern indpakning, der kun er der for layoutets skyld. Store blokke, der er skjult med CSS, er stadig en del af siden og skal stadig hentes og bygges. web.dev foreslår i stedet at tilføje den slags indhold, når der er brug for det.

Hvad I kan forvente

De fleste WordPress-sider, vi ser med et INP på 300–500 millisekunder på mobil, kommer under 200 ved at rydde op i scripts og tredjeparter. Det kræver sjældent, at noget bygges om. De sider, der ligger over 500, har typisk ét konkret element, der er galt: en menu, et filter, en slider. Det er dét element, der skal findes og rettes.

Feltdata følger med over de næste 28 dage. Brug Performance-fanen til at se med det samme, om det konkrete tryk er blevet hurtigere, og Search Console til at bekræfte, at det gælder for de besøgende.

Tjekliste

  1. Find de sidegrupper, der fejler på INP, i Search Console. Tag mobil først.
  2. Optag et besøg i Chromes Performance-fane med CPU-drøvling, og brug siden som en kunde. Notér det langsomste tryk.
  3. Se, om tiden ligger før trykket behandles, i selve behandlingen, eller når det tegnes.
  4. Fjern plugins og scripts, siden ikke bruger, og udskyd resten med defer.
  5. Gennemgå Tag Manager, og udsæt chat og andre tredjeparter, til de behøves.
  6. Lad menu, faner og knapper virke med CSS og almindelige elementer, hvor det kan lade sig gøre.
  7. Del tunge tryk op, så siden først viser, at trykket er registreret.
  8. Test igen, og følg feltdata i Search Console den næste måned.

INP er det mål, der tydeligst handler om, hvordan siden føles at bruge, ikke bare at åbne. En side, der tøver, hver gang man trykker, føles i stykker, uanset hvor hurtigt den loadede. Hvor det hører til i den samlede gennemgang, står under teknisk SEO. Vil I vide, hvor jeres sider står, så start med hastighedstesten. Vil I have det gjort for jer, er det præcis det, vi laver under hastighedsoptimering.

Kilder

Skrevet af

Troels Kammer

Webudvikling, SEO & GEO hos Adbull

Troels har 5 års erfaring med SEO og hjælper til dagligt virksomheder med at bygge hjemmesider, der er hurtige, konverterer godt og bliver fundet på Google.

tk@adbull.dk