Spåra en felaktig INP tillbaka till kodraden i sju grenar

En röd INP-poäng är inte ett prestandaproblem förrän du vet vilken av tre faser som äter upp tiden. De flesta team hoppar över det steget, köper ett caching-plugin eller skjuter upp ett skript och ser den 75:e percentilen vägra att röra sig. Den här guiden är det beslutsträd vi kör istället: sju grenar som tar dig från ett felaktigt Chrome UX-rapportnummer till den specifika hanteraren, skriptet eller tredjepartstaggen som är ansvarig, med ett angivet tröskelvärde vid varje fork. Den är skriven för front-end-leads och tillväxtteam som äger ett konverteringsnummer såväl som ett Lighthouse-poäng.

Gapet är verkligt. I 2025 års webbalmanacka, 77 % av mobila ursprung hade en bra INP mot 97 % på datorer, och endast 48 % av mobila ursprung klarade alla tre Core Web Vitals (HTTP-arkiv). Det som fortfarande är trasigt på mobilen är främst interaktionslatens, och den är oftast diagnostiserbar.

Vad INP mäter och vad den i tysthet ignorerar

Interaktion med Next Paint rapporterar en interaktionslatens per sidbesök, vid 75: e percentilen över ditt ursprung. Bra är 200 ms eller mindre, behöver förbättras är över 200 ms och upp till 500 ms, dålig är över 500 ms (web.devTre saker med den definitionen förändrar hur du felsöker den:

• Endast klick, tryckningar och tangenttryckningar räknas. Håll muspekaren över skärmen, zoomning och rullning mäts inte, så en slarvig scrollning kan få en sida att kännas trasig medan INP förblir grön.
• På sidor med många interaktioner, INP ignorerar en högsta interaktion för varje 50, så en sällsynt katastrofal interaktion kan dölja sig på en sida med högt engagemang och dyka upp på en sida med lågt engagemang.
• Varje interaktion delas upp i ingångsfördröjning (innan dina hanterare springer), bearbetningstid (dina hanterare körs) och presentationsfördröjning (efter dina hanterare, innan ramen målas). Dessa tre har nästan ingenting gemensamt som tekniska problem (web.dev).

Den sista punkten är hela metoden. Du felsöker inte "INP". Du felsöker en av tre faser, och varje fas har en annan lösning.

Gren 0: bekräfta att numret är riktigt innan du trycker på koden

Öppna PageSpeed ​​Insights och läs fältavsnittet, inte labresultatet. Labverktyg kan inte mäta INP, eftersom INP kräver att en riktig användare trycker på något. Om ursprunget inte har några fältdata har du ett trafikproblem, inte ett prestandaproblem, och inget nedan gäller ännu. Dra sedan separat från mobil och dator – globalt skilde de sig med 20 procentenheter år 2025. Om mobil är röd och dator är grön, sluta testa på din bärbara dator.

Gren 1: sker den långsamma interaktionen under laddning eller efter den?

Instrumentera fältet med web-vitals attributionsbyggande. Fyra rader ger dig informationen:

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

Läsa attribution.loadState först. Om de flesta dåliga interaktioner har ett belastningstillstånd av läser in or dom-interaktiv, användare trycker medan dina skript fortfarande utvärderas: ett leveransproblem, åtgärdat i paketet och tagghanteraren, inte i hanteraren. Om dåliga interaktioner är spridda över helt inlästa sidor, gå till gren 2.

Gren 2: vilken underavdelning äger tiden?

Logga inputDelay, processingDuration och presentationDelay för varje prov. Vår arbetsregel: en deldel äger interaktionen när den tar hänsyn till mer än 50 % av den totala INPOm ingen klarar 50 %, behandla det först som ett fall av ingångsfördröjning — diffus överbelastning i huvudtråden är vanligtvis det som förvärrar de andra två.

Gren 3: namnge skriptet

Attributionsbygget innehåller poster för lång animationsbild tillsammans med varje INP-exempel. attribution.longestScript ger dig anroparen, funktionen och källfilen för det sämsta skriptet i interaktionen; totalScriptDuration aggregerar allt över 5 ms. Det är här ett vagt "React is slow" blir en filsökväg. Kontrollera anropartypen: classic-script or module-script poäng vid utvärdering av laddningstid, medan user-callback or event-listener pekar på något som körs efter laddning — en observatör, en timer, en analyslyssnare (web.dev).

Gren 4: är den din eller en tredje parts?

Sortera din skriptattribution efter ursprung. Tagghanterare, samtyckesplattformar, verktyg för sessionsinspelning och chattwidgetar installerar globala lyssnare som körs före din vid varje klick. Om ett tredjepartsursprung förekommer i mer än en fjärdedel av dina sämsta exempel är lösningen kommersiell innan den är teknisk: minska taggens omfattning, ladda den vid interaktion eller flytta den till serversidan. Omstrukturera inte din hanterare för att köpa tillbaka 40 ms som en chattwidget förbrukar ändå.

Gren 5: reproducera det i labbet, fixa sedan ramen

Ta väljaren från attribution.interactionTarget, öppna Chrome DevTools med CPU-begränsning anpassad till din fältenhetsmix och spela in interaktionen. Leta efter en uppgift över 50 ms, tröskelvärdet för långa uppgifter (web.dev), och dela den genom att ge avkastning.

Ship scheduler.yield() med en reservfunktion. Chrome och Edge stöder det från 129 och Firefox från 142, men Safari fungerar inte, vare sig på datorer eller iOS, och MDN markerar den som begränsad tillgänglighet snarare än Baseline (MDN, kan jag användaFör en publik i Turkiet eller Gulfstaterna med en stor iOS-andel, en setTimeout reservfunktion är inte valfri.

Gren 6: mät den marknad du faktiskt säljer till

Globala CrUX-medelvärden döljer marknaden som betalar dig. CrUX BigQuery-datasetet publicerar landstabeller — chrome-ux-report.country_tr.YYYYMM för Turkiet, samma mönster för alla tvåbokstäver av landskod – uppdateras varje månad, med enhetens formfaktor och effektiv anslutningstyp som dimensioner (Chrome för utvecklareDet offentliga CrUX API:et exponerar inte land, så den här delen är endast för BigQuery.

Jämför ditt ursprung mot landstabellen för varje marknad du säljer till. En återförsäljare som betjänar Turkiet, Tyskland och Gulfstaterna hittar rutinmässigt tre olika INP-distributioner från en kodbas, eftersom enhetsmix och nätverksförhållanden skiljer sig åt. Fixera marknaden med intäkterna, inte den med ditt kontor i.

Gren 7: bevisa att den flyttade något

Behandla korrigeringen som ett experiment, inte en driftsättning. Trendyol, en turkisk marknadsplats, spårade en 963 ms mobil INP till en 700–900 ms lång uppgift orsakad av ett IntersectionObserver-återanrop i en React-komponent, och sköt upp tillståndsuppdateringen med scheduler.yield()och sänkte 75:e percentilen av INP från ungefär 1 400 ms till ungefär 650 ms under sex månader. Dess A/B-test visade en 1 % ökning av klickfrekvens från listningar till produktinformation per session (web.dev). redBus ökade lazy-load-interaktioner från 870–900 ms till 350–370 ms, förbättrade textinmatningsinteraktionen med 72 % och rapporterade en 7 % ökning av den totala försäljningen (web.dev).

Observera den ärliga skalan: 1 %, inte 40 %. Vilket leder oss till ett tal som är värt att korrigera.

Siffran 8.4 % förtjänar ett förbehåll

Den mest citerade siffran inom detta område är att en förbättring av mobilhastigheten på 0.1 sekunder höjer konverteringen i detaljhandeln med 8.4 % och resandet med 10.1 %. Det kommer från en riktig studie – 55 och Deloitte, beställd av Google, 37 varumärken, över 30 miljoner sessioner (web.dev). Men den mätte belastningsstatistik som sidladdningstid och serverlatens, inte INP; data täcker 30 dagar i slutet av 2019; och det fanns ingen kontrollgrupp, så det är en observerad korrelation, inte en kausal effekt. Använd den för att inleda en budgetdiskussion, inte för att prognostisera avkastningen på en interaktionslatensfix.

[INTERNA DATA BEHÖVS: Switas före/efter p75 INP och konverteringsdelta från ett klientengagemang, för att ersätta de offentliga fallstudierna med förstapartsbevis.]

Var detta beslutsträd bryts ner

• Ursprung med låg trafik. Med data från tunna fält är den 75:e percentilen brus. Under ungefär 1 000 interaktioner per mall per vecka, profilera i labbet och acceptera att du inte kan verifiera vinsten i CrUX.
• Safari- och Firefox-användare är osynliga. CrUX är endast tillgängligt för Chrome. Om en betydande andel av dina intäkter kommer från iOS Safari, beskriver dina INP-data en population som du inte mäter fullt ut.
• Scroll-jank ligger utanför räckvidden. INP ignorerar rullning, så det här trädet kommer aldrig att hitta problemet i en lista med oändlig rullning som känns hemsk men testar grönt.
• Den hittar latens, inte designskuld. En interaktion på 180 ms på en förvirrande filterpanel är ett UX-problem som det här trädet inte kan se.

FAQ

Är INP samma sak som första ingångsfördröjning?
Nej. FID mätte bara fördröjningen innan den första interaktionens hanterare kördes. INP täcker hela latensen för en representativ interaktion under besöket, inklusive hanterarens körning och den efterföljande målningen.

Varför ser mitt Lighthouse-resultat bra ut medan INP är rött?
Lighthouse är ett labbverktyg och kan inte mäta INP: det finns ingen riktig användare som trycker på något. Proxyservrar som Total Blocking Time korrelerar löst. Läs fältavsnittet i PageSpeed ​​Insights istället.

Hur lång tid tar det innan en fix dyker upp i CrUX?
CrUX rapporterar om ett rullande fönster på 28 dagar, och BigQuery-tabellerna publiceras månadsvis. Förvänta dig en partiell signal efter cirka fyra veckor och en ren avläsning efter två månatliga publiceringar.

Kan jag fixa INP utan att röra ramverket?
Ofta ja. Trendyols lösning var en yield inom ett callback på React 16.9, utan uppgradering. Att skjuta upp tredjepartstaggar är också ramverksoberoende.

Påverkar en samtyckesbanner INP?
Det kan det på två sätt: bannerns eget skript konkurrerar om huvudtråden under laddning, och samtyckesbeslutet utlöser ofta en snabb taggladdning omedelbart efteråt. Mät den första interaktionen efter samtycke separat.

Behöver jag en RUM-leverantör, eller räcker webbbiblioteket med vitala data?
Attribueringsbygget plus en beacon-slutpunkt räcker för att köra det här trädet. En leverantör köper retention, segmentering och dashboards, inte bättre attributionsdata.

Bör jag optimera INP för SEO eller för konvertering?
Bestäm dig för konvertering. Core Web Vitals är en rankningssignal, men de dokumenterade affärsmässiga resultaten – 1 % på Trendyol, 7 % på redBus – är effekter av interaktionskvalitet som i sig själva motiverar arbetet.

Kör detta på din egen listningssida

Ta din mall för högst trafik, instrumentera den med attributionsbygget och gå igenom grenarna 0 till 7 i ordning. Om du hellre vill att trädet körs mot dina egna fältdata, inklusive landssegmentet och experimentdesignen, så är vår webbprestandateam gör just detta engagemang.

Källor

• Interaktion med nästa färg (INP) — web.dev
• Optimera interaktionen till nästa målning — web.dev
• Hitta långsamma interaktioner i fältet — web.dev
• Optimera långa uppgifter — web.dev
• Prestanda — Webbalmanacka 2025, HTTP-arkiv
• Hur Trendyol minskade INP med 50 % — web.dev
• Hur redBus förbättrade INP och ökade försäljningen med 7% — web.dev
• Millisekunder ger miljoner — web.dev / 55 / Deloitte
• CrUX på BigQuery — Chrome för utvecklare
• Schemaläggare: yield() — MDN
• Scheduler API: yield — caniuse
• JavaScript-bibliotek för web-vitals — GoogleChrome/web-vitals