Kort svar: Brug feltdata til at finde den berørte URL-type, og reproducer derefter den konkrete interaktion i browserens Performance-panel. Del forsinkelsen i input delay, processing duration og presentation delay. Reducér den længste del: bryd lange JavaScript-opgaver op, gør event handlers lettere, undgå gentagne layoutberegninger og begræns DOM-arbejde. Delay JavaScript er kun en løsning, hvis den ikke forsinker selve menuen eller formularen.
Interaction to Next Paint måler, hvor hurtigt siden reagerer visuelt på brugerens klik, tryk og tastaturinput gennem hele besøget. En god INP ligger for de fleste brugere på højst 200 millisekunder ved 75-percentilen. En side kan derfor se færdig ud hurtigt og stadig opleves tung, når brugeren prøver at gøre noget.
WordPress har ikke én “INP-indstilling”. Problemet kan ligge i temaets menu, en builder-widget, en produktvariant, en formular, et samtykkescript eller en stor main-thread-opgave, som tilfældigvis kører lige før inputtet.
Sådan er guiden afgrænset: WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151 er arbejdsgrundlaget pr. 28. august 2026. Egne sager skal beskrive URL, interaktion, enhed, browser, cache og samtykketilstand. En enkelt laboratorieinteraktion kan forklare en blokering, men må ikke præsenteres som et websites felt-INP.
På denne side
Feltdata er afgørende, fordi INP vurderer interaktioner over sidens levetid. Start med at afgrænse:
Origin-data kan vise, at sitet samlet har et problem, uden at fortælle hvilken side eller handling der skaber det. Brug derfor egne anonymiserede real-user-målinger, hvis de er korrekt implementeret, eller prioritér repræsentative sider ud fra Search Console/analytics og supporthenvendelser. Gæt ikke en specifik knap ud fra origin-gennemsnittet alene.
| Signal i trace eller brugerflow | Sandsynlig flaskehals | Næste sikre kontrol |
|---|---|---|
| Event handleren starter sent, og en lang opgave ligger lige før inputtet | Input delay fra et andet script eller planlagt main-thread-arbejde | Åbn opgaven før eventet, find dens ejer og gentag på staging med kun den kandidat isoleret |
| Event callbacken fylder størstedelen af interaktionen | Tung handler, synkron validering eller for meget databehandling | Brug Bottom-up/Call tree til at finde den dyreste funktion og test samme input med et mindre datasæt |
| Handleren slutter hurtigt, men næste frame kommer sent | Style calculation, layout, paint eller et stort DOM-update | Åbn rendering-sporene og noter de noder, som bliver genberegnet, før du ændrer JavaScript-loading |
| Kun første klik er langsomt; de næste er hurtige | Forsinket initialisering eller kode, der først hentes ved interaktion | Optag en helt frisk navigation sammen med Network og script-evaluering, og test derefter idle/defer på staging |
| Problemet opstår kun på mobil eller i et stort produktfilter | Langsommere CPU kombineret med for mange DOM-noder eller data | Gentag samme interaktion ved samme viewport med reduceret indholdsmængde; behold funktion og inputtype ens |
| Knappen reagerer hurtigt, men serverresultatet kommer sent | Netværks- eller backendventetid, ikke nødvendigvis dårlig INP | Sammenlign tidspunktet for næste paint med requestens varighed, og flyt backendfejlen til det relevante diagnoseflow |
Åbn den valgte side i en ren privat session med samme samtykketilstand som sagen. I Performance-panelet:
Brug både touch og tastatur, hvis elementet skal understøtte dem. En menu kan reagere hurtigt med mus, men langsomt eller forkert med touch, fordi andre handlers aktiveres.
Article Lab 1.4 på staging har en kontrolleret interaktion, hvor et klik blev målt til 450 millisekunder. Tallet er bevidst fremkaldt og viser, hvordan en lang opgave kan holde main thread, mens brugeren venter på næste paint. Det er ikke en Lighthouse-kørsel, ikke CrUX og ikke produktionsbevis for hostious.io's aktive website.
Brug illustrationen som øvelse: find klikkets event, se hvilken opgave der ligger før og under callbacken, og marker det første paint efter handlingen. Gør derefter det samme på den virkelige problem-URL. Hvis den virkelige menu har 40 millisekunders handler, men 300 millisekunders input delay fra et andet script, er det forkert at omskrive menuens callback. Hvis handleren selv bygger 500 DOM-noder ved hvert klik, er forsinket scriptloading heller ikke den primære løsning.
Før/efter bør derfor vise tre værdier – input delay, processing og presentation – samt samme funktionsresultat. Skriv eksempelvis “menu åbner ved første tryk, fokus flyttes til første punkt, Escape lukker og fokus returnerer”. Så kan en teknisk forbedring ikke godkendes, hvis tilgængeligheden samtidig går tabt.
Tiden fra brugerens input til event handleren starter. Lang input delay betyder ofte, at main thread allerede er optaget af en anden lang opgave: script-evaluering, timer, analytics, DOM-arbejde eller layout.
Se på opgaven umiddelbart før handleren. Det er ikke nødvendigvis menuens egen kode, der er skyld i forsinkelsen.
Tiden i event callbacks. Her kan du se:
Åbn call tree/bottom-up-visningen og find den funktion, der bruger mest tid. Et minificeret filnavn er et spor, ikke altid den oprindelige ejer; brug sourcemaps på staging, hvis de findes.
Tiden fra handlerne er færdige, til browseren viser næste frame. Lang presentation delay kan komme fra style calculation, layout, paint eller et stort DOM, der skal opdateres.
Se efter tvungne synkrone layoutberegninger: JavaScript læser layoutmål, ændrer DOM og læser igen i en gentaget sekvens. Saml læsninger og skrivninger, reducer berørte elementer og undgå at genbygge hele komponenten ved hvert input.
En lang JavaScript-opgave holder main thread og blokerer input. Den sikreste løsning er at reducere eller opdele arbejdet:
En timer, der flytter arbejdet 100 millisekunder, løser ikke nødvendigvis problemet; den kan blot kollidere med et andet input.
Delay JavaScript kan reducere det arbejde, der sker ved indlæsning. Men hvis menuens, formularens eller samtykkets nødvendige script først startes af brugerens første klik, kan klikket både skulle initialisere koden og udføre funktionen. Det kan gøre interaktionen langsommere eller få den til at fejle.
Test tre tilstande på staging:
Behold kun ændringen, hvis den konkrete interaktion bliver bedre og stadig virker med mus, touch og tastatur. Følg guiden til menu eller formular efter Delay JavaScript ved FlyingPress.
Store mega-menuer, skjulte modalers fulde indhold og filtre med hundreder af elementer kan gøre hver klasseændring dyr. Kontroller i trace, om style/layout fylder mest.
Mulige målrettede ændringer:
Tilgængelighed er en del af funktionen. Fokusmarkering, Escape-lukning, tabrækkefølge og fejlmeddelelser må ikke forsvinde for at vinde millisekunder.
Find scriptets ejer gennem filsti, script-id, stack trace og den komponent, der registrerer handleren. Deaktivér kun den mistænkte funktion på staging og gentag samme trace.
Hvis problemet forsvinder, så undersøg om:
Deaktivér ikke alle plugins og kald et hurtigere tomt site en løsning. Du skal bevise den mindste komponent og bevare siden funktionelt sammenlignelig.
En INP-rettelse er først dokumenteret, når:
Gem også den langsomste af de gentagne interaktioner, ikke kun den bedste.
Hvis en bred exclusion reducerer første klik kraftigt, men indlæser et stort scriptsæt på alle sider, kan en mindre forbedring med en smal komponentændring være bedre. Sammenlign derfor både den målrettede interaktion og konsekvensen ved indlæsning. En løsning skal være stabil på svag mobil-CPU, fungere efter frisk navigation og ikke afhænge af, at brugeren allerede har klikket et andet sted.
Sæt en acceptregel før testen: samme handling skal virke tre gange fra en frisk side, den dominerende fase skal være reduceret i mere end én optagelse, og der må ikke komme nye konsolfejl. Feltdata vurderes senere over en passende periode; de erstattes ikke af den lokale trace.
Gendan den senest ændrede delay-, exclusion-, komponent- eller scriptindstilling, purge den berørte URL og bekræft den oprindelige eventkæde. Hvis en kodeændring er nødvendig, skal den have en afgrænset commit eller filbackup.
Kontakt plugin-/temaudvikleren med den minimale side, den konkrete interaktion, trace og funktionsstack. Kontakt hosting kun hvis inputforsinkelsen hænger sammen med netværksrequests eller originresponser, der dokumenteret blokerer handlingen. Hostious WordPress-support kan hjælpe med at oversætte trace til en ansvarlig komponent.
Gem performance trace, eventtype, varighed pr. fase, call tree, DOM-nodeantal for den relevante komponent og netværks-HAR. Mærk syntetiske stagingoptagelser tydeligt, og fjern brugerdata, tokens og formularindhold.
Interaction to Next Paint måler, hvor hurtigt siden reagerer visuelt på klik, tastetryk og touch. Under 200 ms er godt, over 500 ms er dårligt – målt på 75-percentilen i feltdata.
Tunge tredjepartsscripts (sporing, chat, samtykke), store JavaScript-bundter fra page builders og lange opgaver på main thread. Få scripts væk, delay dem – eller split de lange opgaver.
Optag i DevTools’ Performance-panel, klik på det element brugerne bruger (menu, filter, læg-i-kurv), og læs de længste blokke. Feltdata i CrUX viser, hvilke sider du skal starte med.
