En rød INP-score er ikke et performanceproblem, før du ved, hvilken af tre faser der spiser tiden. De fleste teams springer dette trin over, køber et caching-plugin eller udsætter et script og ser den 75. percentil nægte at bevæge sig. Denne guide er det beslutningstræ, vi kører i stedet: syv grene, der fører dig fra et fejlende Chrome UX-rapportnummer til den specifikke handler, script eller tredjepartstag, der er ansvarlig, med en angivet tærskel ved hver fork. Den er skrevet til front-end leads og vækstteams, der ejer et konverteringsnummer såvel som en Lighthouse-score.
Kløften er reel. I webalmanakken fra 2025, 77% af mobile oprindelseslande havde en god INP mod 97% på desktop, og kun 48 % af mobiloprindelserne bestod alle tre Core Web Vitals (HTTP-arkivDet, der stadig er i stykker på mobilen, er for det meste interaktionslatens, og det kan for det meste diagnosticeres.
Hvad INP måler, og hvad den i al hemmelighed ignorerer
Interaktion med Next Paint rapporterer én interaktionslatenstid pr. sidebesøg, kl. 75. percentil på tværs af din oprindelse. Godt er 200 ms eller mindre, behov for forbedring er over 200 ms og op til 500 ms, dårlig er over 500 ms (web.devTre ting ved den definition ændrer, hvordan du fejlsøger den:
- Kun klik, tryk og tastetryk tæller. Hold musen over skærmen, zoom og rulning måles ikke, så en ustabil rulning kan få en side til at føles ødelagt, mens INP forbliver grøn.
- På sider med mange interaktioner, INP ignorerer én interaktion med den højeste værdi for hver 50, så en sjælden katastrofal interaktion kan gemme sig på en side med højt engagement og dukke op på en side med lavt engagement.
- Enhver interaktion opdeles i indgangsforsinkelse (før dine handlere løber), behandlingsvarighed (dine handlere kører) og præsentationsforsinkelse (efter dine håndtag, før rammen males). Disse tre har næsten intet til fælles som tekniske problemer (web.dev).
Det sidste punkt er hele metoden. Du fejlfinder ikke "INP". Du fejlfinder en af tre faser, og hver har en forskellig løsning.
Gren 0: Bekræft at nummeret er rigtigt, før du berører koden
Åbn PageSpeed Insights, og læs feltsektionen, ikke laboratoriescoren. Laboratorieværktøjer kan ikke måle INP, fordi INP kræver, at en rigtig bruger trykker på noget. Hvis oprindelsen ikke har feltdata, har du et trafikproblem, ikke et ydeevneproblem, og intet af nedenstående gælder endnu. Træk derefter mobil og desktop separat – globalt set var der en forskel på 20 procentpoint i 2025. Hvis mobil er rød, og desktop er grøn, skal du stoppe med at teste på din bærbare computer.
Gren 1: Sker den langsomme interaktion under indlæsning eller efter den?
Instrumentér feltet med web-vitals Attributionsopbygning. Fire linjer giver dig dataene:
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
Læs attribution.loadState først. Hvis de fleste dårlige interaktioner har en belastningstilstand på lastning or dom-interaktiv, brugerne trykker, mens dine scripts stadig evalueres: et leveringsproblem, løst i bundtet og tagmanageren, ikke i handleren. Hvis dårlige interaktioner er spredt på tværs af fuldt indlæste sider, skal du gå til gren 2.
Gren 2: hvilken underafdeling ejer tiden?
Log inputDelay, processingDuration og presentationDelay for hver prøve. Vores arbejdsregel: en underdel ejer interaktionen, når den tager højde for mere end 50 % af det samlede INPHvis ingen opnår 50%, skal det først behandles som et tilfælde af inputforsinkelse — diffus overbelastning af hovedtråden er normalt det, der forværrer de to andre.
| Dominerende underafsnit | Undersøg først | Typisk årsag | Første løsning |
|---|---|---|---|
| Indgangsforsinkelse > 50% | longAnimationFrameEntries påkaldertype | Scriptevaluering under indlæsning; timere; en tidligere interaktion kører stadig | Udskyd eller fjern tredjepartsscripts; opdel bundter; flyt periodisk arbejde ud af tråden |
| Behandlingsvarighed > 50% | longestScript og totalScriptDuration | En dyr hændelseshåndterer; en tilstandsopdatering, der udløser en fuld gengivelse | Vigtig inden for handleren; flyt ikke-visuelt arbejde efter næste maling |
| Præsentationsforsinkelse > 50% | totalStyleAndLayoutDuration | Stor DOM; layout-thrasing; tung requestAnimationFrame arbejde | Reducer DOM-størrelsen; anvend content-visibility; batch-stil læser og skriver |
| Intet underafsnit > 50% | Alle de ovenstående | Generel overbelastning af hovedtråden | Behandl som inputforsinkelse, mål igen, og forgren dig derefter igen |
Gren 3: Navngiv scriptet
Attributionsopbygningen indeholder Long Animation Frame-poster sammen med hver INP-eksempel. attribution.longestScript giver dig invokeren, funktionen og kildefilen for det værste script i interaktionen; totalScriptDuration aggregerer alt over 5 ms. Det er her, at en vag "React er langsom" bliver til en filsti. Tjek invoker-typen: classic-script or module-script point ved evaluering af indlæsningstiden, mens user-callback or event-listener peger på noget, der kører efter indlæsning — en observatør, en timer, en analyselytter (web.dev).
Gren 4: Er det din eller en tredjeparts?
Sortér din scriptattribution efter oprindelse. Tagmanagers, samtykkeplatforme, værktøjer til sessionsoptagelse og chatwidgets installerer globale lyttere, der kører før din ved hvert klik. Hvis en tredjepartsoprindelse vises i mere end en fjerdedel af dine værste eksempler, er løsningen kommerciel, før den er teknisk: reducer taggets omfang, indlæs det ved interaktion, eller flyt det til serversiden. Refaktorér ikke din handler for at købe 40 ms tilbage, som en chatwidget bruger.
Gren 5: reproducer det i laboratoriet, og reparer derefter rammen
Tag vælgeren fra attribution.interactionTarget, åbn Chrome DevTools med CPU-begrænsning, der er tilpasset din enhedsmix i felten, og optag interaktionen. Led efter en opgave over 50 ms, tærsklen for lang opgave (web.dev), og opdel den ved at give vigeri.
Forsendelse scheduler.yield() med en reservefunktion. Chrome og Edge understøtter det fra 129 og Firefox fra 142, men Safari gør det ikke, hverken på computer eller iOS, og MDN markerer det som begrænset tilgængelighed i stedet for Baseline (DND, kan jeg bruge). For et tyrkisk eller golfstatsligt publikum med en stor iOS-andel, en setTimeout Fallback er ikke valgfrit.
Gren 6: Mål det marked, du rent faktisk sælger til
Globale CrUX-gennemsnit skjuler det marked, der betaler dig. CrUX BigQuery-datasættet offentliggør landetabeller — chrome-ux-report.country_tr.YYYYMM For Tyrkiet gælder det samme mønster for enhver landekode med to bogstaver – opdateres månedligt med enhedens formfaktor og effektiv forbindelsestype som dimensioner (Chrome for udviklereDen offentlige CrUX API eksponerer ikke land, så dette udsnit er kun til BigQuery.
Sammenlign din oprindelse med landetabellen for hvert marked, du sælger til. En detailhandler, der betjener Tyrkiet, Tyskland og Golfstaterne, finder rutinemæssigt tre forskellige INP-fordelinger fra én kodebase, fordi enhedsmix og netværksforhold er forskellige. Ret markedet ud fra omsætningen, ikke det, hvor dit kontor er placeret.
Gren 7: bevis at den flyttede noget
Betragt rettelsen som et eksperiment, ikke en implementering. Trendyol, en tyrkisk markedsplads, sporede en 963 ms mobil INP til en 700-900 ms lang opgave forårsaget af et IntersectionObserver-tilbagekald i en React-komponent, udsatte tilstandsopdateringen med scheduler.yield()og reducerede 75. percentil INP fra cirka 1,400 ms til cirka 650 ms over seks måneder. Dens A/B-test viste en 1% stigning i klik fra annoncer til produktdetaljer pr. session (web.dev). Redbus øgede lazy-load-interaktioner fra 870-900 ms til 350-370 ms, forbedrede tekstinput-interaktion med 72 % og rapporterede en 7% stigning i det samlede salg (web.dev).
Bemærk den ærlige skala: 1%, ikke 40%. Hvilket bringer os til et tal, der er værd at korrigere.
Tallet på 8.4 % fortjener et forbehold
Det mest citerede tal inden for dette felt er, at en forbedring på 0.1 sekunder i mobilhastigheden øger detailkonverteringen med 8.4 % og rejseaktiviteten med 10.1 %. Det stammer fra en reel undersøgelse — 55 og Deloitte, bestilt af Google, 37 brands, over 30 millioner sessioner (web.dev). Men den målte indlæsningsmålinger såsom sideindlæsningstid og serverforsinkelse, ikke INP; dataene dækker 30 dage ved udgangen af 2019; og der var ingen kontrolgruppe, så det er en observeret korrelation, ikke en årsagssammenhæng. Brug det til at åbne en budgetdiskussion, ikke til at forudsige afkastet af en interaktionslatensrettelse.
[INTERNE DATA NØDVENDIGE: Switas før/efter p75 INP og konverteringsdelta fra et klientengagement for at erstatte de offentlige casestudier med førstepartsdokumentation.]
Hvor dette beslutningstræ opdeles
- Oprindelse med lav trafik. Med tyndt feltdata er den 75. percentil støj. Under cirka 1,000 interaktioner pr. skabelon pr. uge, skal du profilere i laboratoriet og acceptere, at du ikke kan verificere gevinsten i CrUX.
- Safari- og Firefox-brugere er usynlige. CrUX er kun tilgængelig for Chrome. Hvis en betydelig andel af din omsætning kommer fra iOS Safari, beskriver dine INP-data en population, du ikke fuldt ud måler.
- Scroll-jank er uden for rækkevidde. INP ignorerer scrolling, så dette træ vil aldrig finde problemet i en uendelig-scroll-liste, der føles forfærdelig, men tester grøn.
- Den finder latenstid, ikke designgæld. En interaktion på 180 ms på et forvirrende filterpanel er et UX-problem, som dette træ ikke kan se.
Ofte stillede spørgsmål
Er INP det samme som First Input Delay?
Nej. FID målte kun forsinkelsen, før den første interaktions handlere kørte. INP dækker den fulde latenstid for en repræsentativ interaktion på tværs af besøget, inklusive handlerudførelse og den efterfølgende maling.
Hvorfor ser min Lighthouse-score fin ud, mens INP er rød?
Lighthouse er et laboratorieværktøj og kan ikke måle INP: der er ingen reel bruger, der trykker på noget. Proxyer som Total Blocking Time korrelerer løst. Læs i stedet feltafsnittet i PageSpeed Insights.
Hvor lang tid tager det, før en rettelse dukker op i CrUX?
CrUX rapporterer om et rullende vindue på 28 dage, og BigQuery-tabellerne offentliggøres månedligt. Forvent et delvist signal efter cirka fire uger og en ren aflæsning efter to månedlige udgivelser.
Kan jeg rette INP uden at røre rammeværket?
Ofte ja. Trendyols løsning var et yield inden for ét callback på React 16.9, uden opgradering. Udsættelse af tredjepartstags er også framework-uafhængig.
Påvirker et samtykkebanner INP?
Det kan det på to måder: bannerets eget script konkurrerer om hovedtråden under indlæsning, og samtykkebeslutningen udløser ofte en eksplosion af tagindlæsning umiddelbart bagefter. Mål den første interaktion efter samtykke separat.
Har jeg brug for en RUM-leverandør, eller er web-vitals-biblioteket nok?
Attributionsopbygningen plus et beacon-slutpunkt er nok til at køre dette træ. En leverandør køber fastholdelse, segmentering og dashboards, ikke bedre attributionsdata.
Skal jeg optimere INP til SEO eller til konvertering?
Beslut dig for konvertering. Core Web Vitals er et rangeringssignal, men de dokumenterede business cases – 1% hos Trendyol, 7% hos redBus – er interaktionskvalitetseffekter, der i sig selv retfærdiggør arbejdet.
Kør dette på din egen annonceside
Tag din skabelon med den højeste trafik, instrumentér den med attributionsopbygningen, og gå gennem grene 0 til 7 i rækkefølge. Hvis du hellere vil have træet kørt mod dine egne feltdata, inklusive landeudsnittet og eksperimentdesignet, er vores webperformanceteam udfører præcis dette engagement.
Kilder
- Interaktion med Next Paint (INP) — web.dev
- Optimer interaktion til næste maling — web.dev
- Find langsomme interaktioner i marken — web.dev
- Optimer lange opgaver — web.dev
- Ydeevne — Webalmanak 2025, HTTP-arkiv
- Sådan reducerede Trendyol INP med 50% — web.dev
- Hvordan redBus forbedrede INP og øgede salget med 7% — web.dev
- Millisekunder tjener millioner — web.dev / 55 / Deloitte
- CrUX på BigQuery — Chrome til udviklere
- Planlægger: yield() — MDN
- Scheduler API: udbytte — caniuse
- JavaScript-bibliotek for web-vitals — GoogleChrome/web-vitals
