Punainen INP-pistemäärä ei ole suorituskykyongelma, ennen kuin tiedät, mikä kolmesta vaiheesta vie aikaa. Useimmat tiimit ohittavat tämän vaiheen, ostavat välimuistilaajennuksen tai lykkäävät skriptin käsittelyä ja katsovat, kuinka 75. persentiili kieltäytyy toimimasta. Tämä opas on sen sijaan käyttämämme päätöspuu: seitsemän haaraa, jotka vievät sinut epäonnistuneesta Chrome UX Report -numerosta tiettyyn käsittelijään, skriptiin tai kolmannen osapuolen tunnisteeseen, joka on vastuussa ongelmasta, ja jokaisessa haarassa on ilmoitettu kynnysarvo. Se on kirjoitettu front-end-liideille ja kasvutiimeille, joilla on sekä konversioluku että Lighthouse-pistemäärä.
Kuilu on todellinen. Vuoden 2025 verkkoalmanakassa 77 prosentilla mobiilialkuperämaista oli hyvä INP verrattuna 97 prosenttiin pöytätietokoneilla ja vain 48 % mobiilialkuperämaista läpäisi kaikki kolme ydinsisältömittaria (HTTP-arkisto). Mobiililaitteissa on edelleen ongelmia enimmäkseen vuorovaikutusviiveen kanssa, ja se on enimmäkseen diagnosoitavissa.
Mitä INP mittaa ja mitä se hiljaa jättää huomiotta
Vuorovaikutus seuraavaan Paintiin raportoi yhden vuorovaikutusviiveen sivukäyntiä kohden 75. prosenttipiste alkuperäsi halki. Hyvä on 200 ms tai vähemmän, parannusta tarvitaan yli 200 ms ja enintään 500 ms välillä, huono yli 500 ms välillä (web.dev). Kolme asiaa tuossa määritelmässä muuttaa sen virheenkorjausta:
- Vain klikkaukset, napautukset ja näppäinpainallukset lasketaan. Hiiren osoittaminen, zoomaus ja vieritystä ei mitata, joten kömpelö vieritys voi saada sivun tuntumaan rikkinäiseltä, kun taas INP pysyy vihreänä.
- Sivuilla, joilla on paljon vuorovaikutuksia, INP jättää huomiotta yhden suurimman vuorovaikutuksen jokaista 50:tä kohden, joten harvinainen katastrofaalinen vuorovaikutus voi piiloutua korkean sitoutumisen sivulla ja tulla esiin matalan sitoutumisen sivulla.
- Jokainen vuorovaikutus jakautuu osiin syöttöviive (ennen kuin käsittelijäsi suorittavat) käsittelyn kesto (käsittelijäsi käynnissä) ja esityksen viive (käsittelijöidesi jälkeen, ennen kehyksen maalaamista). Näillä kolmella ei ole juuri mitään yhteistä teknisinä ongelmina (web.dev).
Tuo viimeinen kohta on koko metodi. Et debugaa "INP":tä. Debugaat yhtä kolmesta vaiheesta, ja jokaisella on eri korjaus.
Haara 0: varmista, että numero on oikea, ennen kuin kosketat koodia
Avaa PageSpeed Insights ja lue kenttäosio, älä laboratoriotuloksia. Laboratoriotyökalut eivät voi mitata INP:tä, koska INP tarvitsee oikean käyttäjän painavan jotakin. Jos alkuperässä ei ole kenttädataa, sinulla on liikenneongelma, ei suorituskykyongelma, eikä mikään alla olevista vielä päde. Erota sitten mobiili- ja pöytätietokoneversiot erikseen – maailmanlaajuisesti ne erosivat 20 prosenttiyksikköä vuonna 2025. Jos mobiili on punainen ja pöytätietokone vihreä, lopeta testaus kannettavalla tietokoneellasi.
Haara 1: tapahtuuko hidas vuorovaikutus latauksen aikana vai sen jälkeen?
Instrumentoi kenttä web-vitals attribuutiorakenne. Neljä riviä antaa sinulle tiedot:
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
Lue attribution.loadState ensin. Jos useimmilla huonoilla vuorovaikutuksilla on kuormitustila lastaus or dom-interactive, käyttäjät napauttavat, kun skriptisi ovat vielä arvioimassa: toimitusongelma, joka on korjattu paketissa ja tagien hallinnassa, ei käsittelijässä. Jos virheellisiä vuorovaikutuksia esiintyy täysin ladatuilla sivuilla, siirry haaraan 2.
Haara 2: mikä osa omistaa ajan?
Kirjaudu inputDelay, processingDuration ja presentationDelay jokaiselle otokselle. Toimintasääntömme: aliosa omistaa vuorovaikutuksen, kun se ottaa huomioon yli 50 % INP:n kokonaismäärästäJos mikään niistä ei tyhjennä 50 %:a, käsittele sitä ensin syötteen viivetapauksena – pääsäikeen hajanainen ruuhkautuminen on yleensä se, mikä pahentaa kahta muuta.
| Hallitseva alaosa | Tutki ensin | Tyypillinen syy | Ensimmäinen korjaus |
|---|---|---|---|
| Tuloviive > 50 % | longAnimationFrameEntries kutsujan tyyppi | Skriptin arviointi latauksen aikana; ajastimet; edellinen vuorovaikutus on edelleen käynnissä | Lykkää tai poista kolmannen osapuolen skriptejä; jaa paketit; siirrä säännöllisiä töitä säikeen ulkopuolelle |
| Käsittelyn kesto > 50 % | longestScript ja totalScriptDuration | Yksi kallis tapahtumankäsittelijä; tilapäivitys, joka laukaisee täyden uudelleenrenderöinnin | Anna periksi käsittelijän sisällä; siirrä ei-visuaalista työtä seuraavan maalauksen jälkeen |
| Esitysviive > 50 % | totalStyleAndLayoutDuration | Suuri DOM; asettelun murskaaminen; raskas requestAnimationFrame työ | Pienennä DOM-kokoa; käytä content-visibility; erätyylinen luku ja kirjoitus |
| Ei alaosia > 50 % | Kaikki edellä mainitut | Yleinen pääsäikeen ruuhkautuminen | Käsittele tuloviiveenä, mittaa uudelleen ja haaroita sitten uudelleen |
Haara 3: nimeä skripti
Attribuutiokoonnuksessa on pitkiä animaatioruutuja (Long Animation Frame) jokaisen INP-näytteen rinnalla. attribution.longestScript antaa sinulle vuorovaikutuksen huonoimman skriptin kutsujan, funktion ja lähdetiedoston; totalScriptDuration kokoaa kaiken, mikä kestää yli 5 ms. Tässä kohtaa epämääräinen "React on hidas" muuttuu tiedostopoluksi. Tarkista kutsujan tyyppi: classic-script or module-script pistettä latausajan arvioinnissa, kun taas user-callback or event-listener osoittaa johonkin latauksen jälkeen käynnissä olevaan — tarkkailijaan, ajastimeen, analytiikkakuuntelijaan (web.dev).
Haara 4: onko se sinun vai kolmannen osapuolen?
Lajittele skriptisi attribuutio alkuperän mukaan. Tagien hallintaohjelmat, suostumusalustat, istuntojen tallennustyökalut ja chat-widgetit asentavat globaaleja kuuntelijoita, jotka suoritetaan ennen sinun kuuntelijaasi jokaisella klikkauksella. Jos kolmannen osapuolen alkuperä esiintyy yli neljänneksessä huonoimmista esimerkeistäsi, korjaus on kaupallinen ennen kuin se on tekninen: pienennä tagin laajuutta, lataa se vuorovaikutuksen yhteydessä tai siirrä se palvelinpuolelle. Älä kuitenkaan refaktoroi käsittelijääsi ostaaksesi takaisin 40 ms, jonka chat-widget käyttää.
Haara 5: toista se laboratoriossa ja korjaa sitten kehys
Ota valitsin kohdasta attribution.interactionTarget, avaa Chrome DevTools ja määritä suorittimen rajoitus kenttälaitevalikoimaasi vastaavaksi ja tallenna vuorovaikutus. Etsi tehtävää, joka on ohi. 50 ms, pitkän tehtävän kynnysarvo (web.dev) ja jaa se antamalla myöten.
Lähettää scheduler.yield() varavaihtoehdolla. Chrome ja Edge tukevat sitä versiosta 129 alkaen ja Firefox versiosta 142 alkaen, mutta Safari ei tue sitä tietokoneella tai iOS:llä, ja MDN merkitsee sen saatavuuden rajoitetuksi eikä lähtötilanteeksi (DND, Voinko käyttää). Turkin tai Persianlahden alueen yleisölle, jolla on suuri iOS-osuus, a setTimeout varajärjestelmä ei ole valinnainen.
Haara 6: mittaa markkinat, joille tosiasiallisesti myyt
Globaalit CrUX-keskiarvot piilottavat markkinat, jotka maksavat sinulle. CrUX BigQuery -datajoukko julkaisee maakohtaiset taulukot — chrome-ux-report.country_tr.YYYYMM Turkin tapauksessa sama kaava mille tahansa kaksikirjaimiselle maakoodille – päivitetään kuukausittain, laitteen kokoluokka ja tehokas yhteystyyppi mitoina (Chrome kehittäjille). Julkinen CrUX-rajapinta ei paljasta maata, joten tämä osio on tarkoitettu vain BigQuerylle.
Vertaile alkuperämaata maataulukkoa vasten jokaisella markkina-alueella, jolle myyt. Turkkia, Saksaa ja Persianlahden aluetta palveleva jälleenmyyjä löytää rutiininomaisesti kolme erilaista INP-jakaumaa yhdestä koodikannasta, koska laitevalikoima ja verkko-olosuhteet vaihtelevat. Määritä markkina-alue tulojen perusteella, äläkä sen mukaan, jolla toimistosi on.
Haara 7: todista, että se siirsi jotakin
Käsittele korjausta kokeiluna, älä käyttöönottona. Trendyol, turkkilainen markkinapaikka, jäljitti 963 ms:n mobiili-INP:n yhteen 700–900 ms:n pituiseen tehtävään, jonka aiheutti IntersectionObserver-takaisinkutsu React-komponentin sisällä, ja lykkäsi tilapäivitystä scheduler.yield()ja leikkasi 75. persentiilin INP:tä noin 1 400 millisekunnista noin 650 millisekuntiin kuuden kuukauden aikana. Sen A/B-testi osoitti a 1 %:n nousu klikkauksissa listauksista tuotetietoihin istuntoa kohden (web.dev). Redbus laiska lataus -vuorovaikutusten kesto nousi 870–900 millisekunnista 350–370 millisekuntiin, tekstinsyöttövuorovaikutus parani 72 % ja raportoi 7 %:n kasvu kokonaismyynnissä (web.dev).
Huomaa rehellinen asteikko: 1 %, ei 40 %. Tämä tuo meidät lukuun, joka kannattaa korjata.
Luku 8.4% ansaitsee varauksen.
Tällä alalla useimmin siteerattu luku on, että 0.1 sekunnin parannus mobiilinopeudessa nostaa vähittäiskaupan konversioita 8.4 % ja matkailua 10.1 %. Se on peräisin todellisesta tutkimuksesta – 55 ja Deloitte, Googlen tilaama, 37 brändiä, yli 30 miljoonaa istuntoa (web.dev). Mutta se mittasi kuormitusmittareita, kuten sivun latausaikaa ja palvelimen viivettä, ei INP; tiedot kattavat 30 päivää vuoden 2019 lopussa; eikä kontrolliryhmää ollut, joten kyseessä on havaittu korrelaatio, ei kausaalinen vaikutus. Käytä sitä budjettikeskustelun aloittamiseen, äläkä vuorovaikutuslatenssikorjauksen tuoton ennustamiseen.
[TARVITAAN SISÄISTÄ TIETOA: Swita-arvot ennen/jälkeen p75 INP ja konversiodelta asiakaskokemuksesta, jotta julkiset tapaustutkimukset voidaan korvata ensimmäisen osapuolen näytöllä.]
Missä tämä päätöksentekopuu jakautuu
- Vähäliikenteiset lähtöpaikat. Ohuen kentän datan kanssa 75. persentiili on kohinaa. Alle noin 1 000 vuorovaikutusta viikossa mallipohjaa kohden, profiloi laboratoriossa ja hyväksy, ettet voi varmistaa voittoa CrUX:ssa.
- Safarin ja Firefoxin käyttäjät ovat näkymättömiä. CrUX on tarkoitettu vain Chromelle. Jos merkittävä osa tuloistasi tulee iOS Safariin, INP-datasi kuvaavat populaatiota, jota et mittaa täysin.
- Scroll jank on poissa käytöstä. INP jättää vierityksen huomiotta, joten tämä puu ei koskaan löydä ongelmaa äärettömän vierityksen listauksesta, joka tuntuu kamalalta, mutta testataan vihreäksi.
- Se löytää latenssia, ei suunnitteluvelkaa. 180 ms:n vuorovaikutus hämmentävässä suodatinpaneelissa on käyttökokemusongelma, jota tämä puu ei näe.
FAQ
Onko INP sama asia kuin ensimmäisen syötteen viive?
Ei. FID mittasi vain viiveen ennen ensimmäisen interaktion käsittelijöiden suorittamista. INP kattaa edustavan interaktion koko latenssin koko vierailun ajan, mukaan lukien käsittelijän suorituksen ja sitä seuraavan piirron.
Miksi Lighthouse-pistemääräni näyttää hyvältä, vaikka INP on punainen?
Lighthouse on laboratoriotyökalu, eikä se voi mitata INP:tä: mikään oikea käyttäjä ei paina mitään. Välityspalvelimet, kuten Kokonaisestoaika (Total Blocking Time), korreloivat löyhästi. Lue sen sijaan PageSpeed Insightsin kenttäosio.
Kuinka kauan kestää, ennen kuin korjaus näkyy CrUX:ssa?
CrUX raportoi 28 päivän liukuvalla ikkunalla, ja BigQuery-taulukot julkaistaan kuukausittain. Osittaista signaalia on odotettavissa noin neljän viikon kuluttua ja puhdasta lukemaa kahden kuukausittaisen julkaisun jälkeen.
Voinko korjata INP:n koskematta runkoon?
Usein kyllä. Trendyolin korjaus oli tuotto yhden callbackin sisällä React 16.9:ssä ilman päivitystä. Kolmannen osapuolen tagien lykkääminen on myös frameworkista riippumatonta.
Vaikuttaako suostumusbanneri INP:hen?
Se voi tapahtua kahdella tavalla: bannerin oma skripti kilpailee pääketjusta latauksen aikana, ja suostumuspäätös usein laukaisee tagien latausryöpyn heti sen jälkeen. Mittaa ensimmäistä vuorovaikutusta suostumuksen jälkeen erikseen.
Tarvitsenko RUM-toimittajan, vai riittääkö web-vitals-kirjasto?
Attribuutiokoonnos ja beacon-päätepiste riittävät tämän puun pyörittämiseen. Toimittaja ostaa asiakaspysyvyyttä, segmentointia ja koontinäyttöjä, ei parempaa attribuutiodataa.
Pitäisikö minun optimoida INP hakukoneoptimointia vai konversiota varten?
Päätä konversion puolesta. Ydinverkkojen vitals-mittarit ovat sijoitussignaali, mutta dokumentoidut liiketoimintatapaukset – 1 % Trendyolilla, 7 % redBusilla – ovat vuorovaikutuksen laatua parantavia vaikutuksia, jotka oikeuttavat työn itsessään.
Suorita tämä omalla listaussivullasi
Ota eniten liikennettä saanut mallipohjasi, käytä siihen attribuutiomallia ja käy läpi haarat 0–7 järjestyksessä. Jos haluat mieluummin ajaa puun omaa kenttädataa vasten, maakohtaiset tiedot ja kokeiluasetelmat mukaan lukien, meidän verkkosuorituskykytiimi tekee juuri tätä sitoumusta.
Lähteet
- Vuorovaikutus seuraavaan maaliin (INP) — web.dev
- Optimoi vuorovaikutus seuraavaa maalia varten — web.dev
- Löydä hitaita vuorovaikutuksia kentällä — web.dev
- Optimoi pitkiä tehtäviä — web.dev
- Suorituskyky — Verkkoalmanakka 2025, HTTP-arkisto
- Miten Trendyol alensi INP:tä 50 % — web.dev
- Kuinka redBus paransi INP:tä ja kasvatti myyntiä 7 % — web.dev
- Millisekunneilla voi tehdä miljoonia — web.dev / 55 / Deloitte
- CrUX BigQueryssa — Chrome kehittäjille
- Ajoitusohjelma: yield() — MDN
- Scheduler API: tuotto — caniuse
- web-vitals JavaScript-kirjasto — GoogleChrome/web-vitals
