En rød INP-poengsum er ikke et ytelsesproblem før du vet hvilken av tre faser som spiser opp tiden. De fleste team hopper over det trinnet, kjøper en caching-plugin eller utsetter et skript, og ser at den 75. persentilen nekter å bevege seg. Denne veiledningen er beslutningstreet vi kjører i stedet: syv grener som tar deg fra et Chrome UX-rapportnummer som ikke fungerer til den spesifikke behandleren, skriptet eller tredjepartstaggen som er ansvarlig, med en angitt terskel ved hver forgrening. Den er skrevet for front-end-leads og vekstteam som eier et konverteringstall samt en Lighthouse-poengsum.
Gapet er reelt. I nettalmanakken for 2025, 77 % av mobilopprinnelsene hadde en god INP mot 97 % på datamaskiner, og bare 48 % av mobilopprinnelsene besto alle tre Core Web Vitals (HTTP-arkiv). Det som fortsatt er ødelagt på mobil er for det meste interaksjonsforsinkelse, og den er for det meste diagnostiserbar.
Hva INP måler, og hva den i stillhet ignorerer
Interaksjon med Next Paint rapporterer én interaksjonsforsinkelse per sidebesøk, kl. 75. persentil på tvers av din opprinnelse. Godt er 200 ms eller mindre, trenger forbedring er over 200 ms og opptil 500 ms, dårlig er over 500 ms (web.devTre ting ved den definisjonen endrer hvordan du feilsøker den:
- Bare klikk, trykk og tastetrykk teller. Hold musepekeren over, zoom og rulling måles ikke, så en hakkete rulling kan få en side til å føles ødelagt mens INP forblir grønn.
- På sider med mange interaksjoner, INP ignorerer én høyeste interaksjon for hver 50, slik at en sjelden katastrofal interaksjon kan gjemme seg på en side med høyt engasjement og dukke opp på en side med lavt engasjement.
- Hver interaksjon deler seg opp i inngangsforsinkelse (før håndterne dine løper), behandlingsvarighet (håndtererne dine kjører) og presentasjonsforsinkelse (etter håndtakene dine, før rammen males). Disse tre har nesten ingenting til felles som tekniske problemer (web.dev).
Det siste punktet er hele metoden. Du feilsøker ikke «INP». Du feilsøker én av tre faser, og hver har en annen løsning.
Gren 0: bekreft at nummeret er ekte før du berører koden
Åpne PageSpeed Insights og les feltdelen, ikke lab-poengsummen. Lab-verktøy kan ikke måle INP, fordi INP trenger en ekte bruker som trykker på noe. Hvis opprinnelsen ikke har feltdata, har du et trafikkproblem, ikke et ytelsesproblem, og ingenting nedenfor gjelder ennå. Trekk deretter mobil og datamaskin separat – globalt skilte de seg med 20 prosentpoeng i 2025. Hvis mobil er rød og datamaskin er grønn, slutt å teste på den bærbare datamaskinen din.
Gren 1: skjer den langsomme interaksjonen under lasting eller etter den?
Instrumenter feltet med web-vitals attribusjonsbygging. Fire linjer gir deg dataene:
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
Lese attribution.loadState først. Hvis de fleste dårlige interaksjoner har en lastetilstand på lasting or dom-interaktiv, brukere trykker mens skriptene dine fortsatt evalueres: et leveringsproblem, løst i pakken og tagbehandleren, ikke i behandleren. Hvis dårlige interaksjoner er spredt over fullastede sider, gå til gren 2.
Gren 2: hvilken underdel eier tiden?
Overnatting inputDelay, processingDuration og presentationDelay for hver prøve. Vår arbeidsregel: en underdel eier interaksjonen når den tar hensyn til mer enn 50 % av total INPHvis ingen klarer 50 %, behandle det først som et tilfelle av input-delay – diffus overbelastning av hovedtråden er vanligvis det som gjør de to andre verre.
| Dominerende underdel | Undersøk først | Typisk årsak | Første løsning |
|---|---|---|---|
| Inngangsforsinkelse > 50 % | longAnimationFrameEntries påkallertype | Skriptevaluering under lasting; tidtakere; en tidligere interaksjon kjører fortsatt | Utsett eller fjern tredjepartsskript; del opp bunter; flytt periodisk arbeid utenfor tråden |
| Behandlingsvarighet > 50 % | longestScript og totalScriptDuration | Én dyr hendelsesbehandler; en tilstandsoppdatering som utløser en fullstendig ny gjengivelse | Gi etter inne i håndtereren; flytt ikke-visuelt arbeid etter neste maling |
| Presentasjonsforsinkelse > 50 % | totalStyleAndLayoutDuration | Stor DOM; layout-krasjing; tung requestAnimationFrame arbeid | Reduser DOM-størrelsen; bruk content-visibility; batch-stil leser og skriver |
| Ingen underdel > 50 % | Alle de ovennevnte | Generell overbelastning i hovedtråden | Behandle som inngangsforsinkelse, mål på nytt, og forgren deg deretter på nytt |
Gren 3: navngi skriptet
Attribusjonsbyggingen inneholder lange animasjonsrammeoppføringer ved siden av hvert INP-eksempel. attribution.longestScript gir deg invokeren, funksjonen og kildefilen for det verste skriptet i interaksjonen; totalScriptDuration aggregerer alt over 5 ms. Det er her en vag "React is slow" blir en filsti. Sjekk invoker-typen: classic-script or module-script poeng ved lastetidsevaluering, mens user-callback or event-listener peker på noe som kjører etter lasting – en observatør, en timer, en analyselytter (web.dev).
Gren 4: er den din eller en tredjeparts?
Sorter skriptattribusjonen din etter opprinnelse. Tag-behandlere, samtykkeplattformer, verktøy for øktopptak og chat-widgeter installerer globale lyttere som kjører før din på hvert klikk. Hvis en tredjeparts opprinnelse vises i mer enn en fjerdedel av de verste eksemplene dine, er løsningen kommersiell før den er teknisk: reduser taggens omfang, last den inn ved interaksjon, eller flytt den til serversiden. Ikke omstrukturer behandleren din for å kjøpe tilbake 40 ms en chat-widget bruker uansett.
Gren 5: reproduser det i laboratoriet, og fiks deretter rammen
Ta velgeren fra attribution.interactionTarget, åpne Chrome DevTools med CPU-begrensning tilpasset enhetsmiksen i felten, og registrer interaksjonen. Se etter en oppgave over 50 ms, terskelen for lang oppgave (web.dev), og del den med viker.
Ship scheduler.yield() med en reserve. Chrome og Edge støtter det fra 129 og Firefox fra 142, men Safari gjør det ikke, verken på datamaskin eller iOS, og MDN markerer den som begrenset tilgjengelighet i stedet for Baseline (DND, kan jeg bruke). For et tyrkisk eller gulfpublikum med en stor iOS-andel, en setTimeout Reserve er ikke valgfritt.
Gren 6: mål markedet du faktisk selger til
Globale CrUX-gjennomsnitt skjuler markedet som betaler deg. CrUX BigQuery-datasettet publiserer landstabeller – chrome-ux-report.country_tr.YYYYMM for Tyrkia, samme mønster for enhver landskode med to bokstaver – oppdateres månedlig, med enhetens formfaktor og effektiv tilkoblingstype som dimensjoner (Chrome for utviklereDet offentlige CrUX API-et eksponerer ikke land, så denne delen er kun for BigQuery.
Kjør opprinnelseslandene dine mot landstabellen for hvert marked du selger til. En forhandler som betjener Tyrkia, Tyskland og Gulfen finner rutinemessig tre forskjellige INP-distribusjoner fra én kodebase, fordi enhetsmiks og nettverksforhold er forskjellige. Fiks markedet med inntektene, ikke det med kontoret ditt i.
Gren 7: bevis at den flyttet noe
Behandle fiksen som et eksperiment, ikke en utrulling. Trendyol, en tyrkisk markedsplass, sporet en 963 ms mobil INP til en 700–900 ms lang oppgave forårsaket av et IntersectionObserver-tilbakekall i en React-komponent, utsatte tilstandsoppdateringen med scheduler.yield(), og kuttet 75. persentil INP fra omtrent 1,400 ms til omtrent 650 ms over seks måneder. A/B-testen viste en 1 % økning i klikk fra oppføringer til produktdetaljer per økt (web.dev). Redbus økte lazy-load-interaksjoner fra 870–900 ms til 350–370 ms, forbedret tekstinndata-interaksjon med 72 % og rapporterte en 7 % økning i totalt salg (web.dev).
Legg merke til den ærlige skalaen: 1 %, ikke 40 %. Noe som bringer oss til et tall som er verdt å korrigere.
Tallet på 8.4 % fortjener et forbehold
Det mest siterte tallet på dette feltet er at en forbedring på 0.1 sekunder i mobilhastighet øker konverteringen i detaljhandelen med 8.4 % og reiser med 10.1 %. Det kommer fra en reell studie – 55 og Deloitte, bestilt av Google, 37 merkevarer, over 30 millioner økter (web.dev). Men den målte innlastingsmålinger som sideinnlastingstid og serverforsinkelse, ikke INP; dataene dekker 30 dager ved utgangen av 2019; og det var ingen kontrollgruppe, så det er en observert korrelasjon, ikke en årsakssammenheng. Bruk den til å åpne en budsjettsamtale, ikke til å forutsi avkastningen på en interaksjonsforsinkelsesfiksering.
[INTERNE DATA SOM TRENGES: Switas før/etter p75 INP og konverteringsdelta fra et klientengasjement, for å erstatte de offentlige casestudiene med førstepartsdokumentasjon.]
Hvor dette beslutningstreet brytes ned
- Opprinnelsessteder med lav trafikk. Med tynne feltdata er den 75. persentilen støy. Under omtrent 1,000 interaksjoner per mal per uke, profiler i laboratoriet og aksepter at du ikke kan bekrefte gevinsten i CrUX.
- Safari- og Firefox-brukere er usynlige. CrUX er kun for Chrome. Hvis en betydelig andel av inntektene dine kommer inn på iOS Safari, beskriver INP-dataene dine en populasjon du ikke måler fullt ut.
- Scroll-jank er utenfor rekkevidde. INP ignorerer rulling, så dette treet vil aldri finne problemet i en uendelig rull-liste som føles forferdelig, men tester grønt.
- Den finner latens, ikke designgjeld. En interaksjon på 180 ms på et forvirrende filterpanel er et UX-problem dette treet ikke kan se.
FAQ
Er INP det samme som første inngangsforsinkelse?
Nei. FID målte bare forsinkelsen før den første interaksjonens behandlere kjørte. INP dekker hele latensen til en representativ interaksjon gjennom besøket, inkludert utførelse av behandleren og malingen som følger.
Hvorfor ser Lighthouse-poengsummen min fin ut, mens INP er rød?
Lighthouse er et laboratorieverktøy og kan ikke måle INP: det er ingen reell bruker som trykker på noe. Proxyer som Total Blocking Time korrelerer løst. Les feltdelen av PageSpeed Insights i stedet.
Hvor lang tid tar det før en løsning dukker opp i CrUX?
CrUX rapporterer om et rullerende vindu på 28 dager, og BigQuery-tabellene publiseres månedlig. Forvent et delvis signal etter omtrent fire uker og en ren avlesning etter to månedlige utgivelser.
Kan jeg fikse INP uten å berøre rammeverket?
Ofte ja. Trendyols løsning var en yield innenfor én callback på React 16.9, uten oppgradering. Utsettelse av tredjeparts tagger er også rammeverksuavhengig.
Påvirker et samtykkebanner INP?
Det kan det på to måter: bannerets eget skript konkurrerer om hovedtråden under lasting, og samtykkebeslutningen utløser ofte en serie tag-lasting umiddelbart etterpå. Mål den første interaksjonen etter samtykke separat.
Trenger jeg en RUM-leverandør, eller er web-vitals-biblioteket nok?
Attribusjonsbyggingen pluss et beacon-endepunkt er nok til å kjøre dette treet. En leverandør kjøper retensjon, segmentering og dashboards, ikke bedre attribusjonsdata.
Bør jeg optimalisere INP for SEO eller for konvertering?
Bestem deg for konvertering. Core Web Vitals er et rangeringssignal, men de dokumenterte forretningssakene – 1 % hos Trendyol, 7 % hos redBus – er effekter av interaksjonskvalitet som rettferdiggjør arbeidet i seg selv.
Kjør dette på din egen oppføringsside
Ta malen for høyest trafikk, instrumenter den med attribusjonsbyggingen, og gå gren 0 til 7 i rekkefølge. Hvis du heller vil at treet skal kjøres mot dine egne feltdata, inkludert landsdelen og eksperimentdesignet, vil vår webytelsesteam gjør nettopp dette engasjementet.
Kilder
- Interaksjon med neste maling (INP) — web.dev
- Optimaliser interaksjonen til neste maling — web.dev
- Finn trege interaksjoner i feltet — web.dev
- Optimaliser lange oppgaver — web.dev
- Ytelse — Webalmanakk 2025, HTTP-arkiv
- Hvordan Trendyol reduserte INP med 50 % — web.dev
- Hvordan redBus forbedret INP og økte salget med 7 % — web.dev
- Millisekunder tjener millioner — web.dev / 55 / Deloitte
- CrUX på BigQuery – Chrome for utviklere
- Planlegger: yield() — MDN
- Scheduler API: yield — caniuse
- JavaScript-bibliotek for web-vitals — GoogleChrome/web-vitals
