Dårlig INP i WordPress: find lange JavaScript-opgaver

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.

Fagligt gennemgået: 2. oktober 2026

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.

Trin 1: Brug feltdata til at vælge en rigtig sag

Feltdata er afgørende, fordi INP vurderer interaktioner over sidens levetid. Start med at afgrænse:

• URL-gruppe eller skabelon;
• mobil eller desktop;
• tidspunkt og trafiksegment;
• sandsynlig interaktion: menu, søgning, filter, variation, accordion eller formular;
• om problemet opstår før eller efter samtykke;
• om en bestemt browser/enhed er overrepræsenteret.

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.

Diagnosematrix: læs sporet før du ændrer scripts

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

Trin 2: Reproducer interaktionen

Åbn den valgte side i en ren privat session med samme samtykketilstand som sagen. I Performance-panelet:

1. start optagelsen efter siden er stabil;
2. udfør én naturlig interaktion;
3. vent til det visuelle resultat er tegnet;
4. stop optagelsen;
5. gentag tre gange og sammenlign.

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.

Sådan læses den syntetiske illustration

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.

Trin 3: Del hændelsen i tre faser

Input delay

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.

Processing duration

Tiden i event callbacks. Her kan du se:

• tunge loops eller databehandling;
• mange handlers på samme input;
• synkron validering;
• script, der bygger store DOM-fragmenter;
• produktfiltre, der beregner for meget på klienten;
• tredjepartskode, som kører i samme event.

Å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.

Presentation delay

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.

Trin 4: Reducér lange opgaver

En lang JavaScript-opgave holder main thread og blokerer input. Den sikreste løsning er at reducere eller opdele arbejdet:

• fjern kode, der ikke bruges på den aktuelle skabelon;
• indlæs en tung widget først, når den er nødvendig;
• del store beregninger op, så browseren kan give plads til input og rendering;
• undgå at initialisere samme komponent flere gange;
• begræns data og DOM-noder, som et filter eller live search behandler;
• flyt ikke-kritisk arbejde væk fra den første interaktion.

En timer, der flytter arbejdet 100 millisekunder, løser ikke nødvendigvis problemet; den kan blot kollidere med et andet input.

Trin 5: Afgør om Delay JavaScript hjælper eller skader

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:

1. uden delay for den dokumenterede kandidat;
2. med en mindre aggressiv defer/idle-strategi;
3. med en minimal exclusion for det script, funktionen behøver.

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.

Trin 6: Reducér DOM- og layoutarbejde

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:

• render kun den aktive del af en stor liste;
• undgå globale class toggles, der invaliderer hele siden;
• brug CSS-transform til bevægelse frem for top/left, når designet tillader det;
• hold skjulte komponenter enklere;
• begræns live-validering til felter, der faktisk ændres;
• debounce hyppige inputevents uden at gøre feltet sløvt.

Tilgængelighed er en del af funktionen. Fokusmarkering, Escape-lukning, tabrækkefølge og fejlmeddelelser må ikke forsvinde for at vinde millisekunder.

Trin 7: Isoler tema, builder eller plugin

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:

• en opdatering retter det;
• widgetten kan erstattes af en lettere native komponent;
• scriptet kan begrænses til de sider, der bruger funktionen;
• komponentens data eller DOM kan reduceres;
• udvikleren kan bruge din minimale reproduktion.

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.

Verifikation

En INP-rettelse er først dokumenteret, når:

• den samme handling er optaget før og efter;
• den dominerende fase er reduceret i flere kørsler;
• menu/formular/filter giver det samme korrekte resultat;
• touch, mus og tastatur er eftertestet;
• der er ingen nye konsolfejl eller manglende requests;
• LCP og CLS ikke er blevet dårligere;
• feltdata følges over tid uden at blive blandet sammen med labresultatet.

Gem også den langsomste af de gentagne interaktioner, ikke kun den bedste.

Hvornår er en mindre forbedring den rigtige løsning?

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.

Rollback og eskalering

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.

Sådan dokumenterer du din egen INP-sag

1. Tegn de tre faser – input delay, processing og presentation – med de målte varigheder.
2. Gem et Performance-trace af den konkrete menu-, filter- eller formularhandling.
3. Vis Bottom-up eller Call tree med den dominerende funktion og en anonymiseret filsti.
4. Bevar layout-/paint-sporet før og efter, hvis rettelsen reducerer DOM-arbejde.
5. Før en testmatrix for mus, touch, tastatur og skærmbredde med forventet resultat.
6. Gem Network og Console ved en sikker formularindsendelse uden personoplysninger.

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.

Ofte stillede spørgsmål om INP

Hvad er INP, og hvad er et godt tal?

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.

Hvad skaber typisk dårlig INP på WordPress-sites?

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.

Hvordan finder jeg den langsomme interaktion?

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.

Læs også

• Hub: WordPress performance og cache
• Gør WordPress hurtigere
• Forbedr LCP
• Forbedr CLS
• Delay JavaScript bryder menu eller formular
• WordPress hosting hos Hostious – NVMe, LiteSpeed og Redis fra WP StartUp