Tracciare un INP fallimentare fino alla riga di codice in sette rami

Tracciare un INP fallimentare fino alla riga di codice in sette rami

Un punteggio INP rosso non rappresenta un problema di prestazioni finché non si individua quale delle tre fasi sta rallentando il processo. La maggior parte dei team salta questo passaggio, acquista un plugin di caching o rimanda l'esecuzione di uno script, e si ritrova con il 75° percentile bloccato. Questa guida è l'albero decisionale che utilizziamo: sette rami che conducono da un valore di errore nel Chrome UX Report al gestore, allo script o al tag di terze parti specifico responsabile, con una soglia predefinita a ogni biforcazione. È pensata per i responsabili front-end e i team di crescita che gestiscono sia il tasso di conversione che il punteggio Lighthouse.

Il divario è reale. Nell'Almanacco Web 2025, Il 77% delle origini mobili aveva un buon INP contro il 97% su desktop e solo Il 48% delle origini da dispositivi mobili ha superato tutti e tre i Core Web Vitals (Archivio HTTPCiò che ancora non funziona sui dispositivi mobili è principalmente la latenza di interazione, ed è per lo più diagnosticabile.

Cosa misura l'INP e cosa ignora silenziosamente

L'interazione con Next Paint segnala una latenza di interazione per visita di pagina, al 75o percentile attraverso la tua origine. Il bene è 200 ms o meno, necessita di miglioramenti se è superiore a 200 ms e fino a 500 ms, scarso se è superiore a 500 ms (web.devTre elementi di questa definizione cambiano il modo in cui esegui il debug:

  • Contano solo i clic, i tocchi e la pressione dei tasti. Passare il mouse sopra, zoomare e lo scorrimento non è misurato, quindi uno scorrimento irregolare può far sembrare una pagina incompleta mentre INP rimane verde.
  • Nelle pagine con molte interazioni, INP ignora l'interazione più alta ogni 50Pertanto, una rara interazione catastrofica può nascondersi su una pagina ad alto coinvolgimento e riemergere su una a basso coinvolgimento.
  • Ogni interazione si divide in ritardo di ingresso (prima che i tuoi gestori vengano eseguiti), durata dell'elaborazione (i tuoi gestori in esecuzione) e ritardo della presentazione (dopo i tuoi gestori, prima che il telaio venga verniciato). Questi tre non hanno quasi nulla in comune come problemi di ingegneria (web.dev).

Quest'ultimo punto rappresenta l'intero metodo. Non stai eseguendo il debug di "INP", bensì di una delle tre fasi, e ognuna richiede una soluzione diversa.

Filiale 0: verifica che il numero sia reale prima di toccare il codice

Apri PageSpeed ​​Insights e leggi la sezione relativa ai campi, non il punteggio di laboratorio. Gli strumenti di laboratorio non possono misurare l'INP, perché l'INP richiede che un utente reale prema qualcosa. Se l'origine non ha dati sui campi, hai un problema di traffico, non di prestazioni, e nessuna delle seguenti considerazioni è ancora applicabile. Quindi, analizza separatamente i dati per dispositivi mobili e desktop: a livello globale, nel 2025 la differenza tra i due era di 20 punti percentuali. Se i dati per dispositivi mobili sono rossi e quelli per desktop verdi, interrompi i test sul tuo laptop.

Ramo 1: l'interazione lenta si verifica durante il caricamento o dopo?

Strumentare il campo con il web-vitals Creazione dell'attribuzione. Quattro righe ti forniscono i dati:

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

Leggi attribution.loadState Innanzitutto, se la maggior parte delle interazioni negative comporta uno stato di carico di Caricamento in corso or dom-interattivoGli utenti toccano lo schermo mentre gli script sono ancora in fase di valutazione: si tratta di un problema di consegna, da risolvere a livello del bundle e del tag manager, non nell'handler. Se le interazioni errate si estendono a pagine completamente caricate, passare al ramo 2.

Ramo 2: quale sottosezione gestisce il tempo?

Log inputDelay, processingDuration and presentationDelay per ogni campione. La nostra regola di lavoro: una sottoparte possiede l'interazione quando tiene conto di oltre il 50% del totale INPSe nessuno dei due supera il 50%, trattatelo prima come un caso di ritardo di input: la congestione diffusa del thread principale è solitamente ciò che peggiora gli altri due.

Sottoparte dominanteIndagare primaCausa tipicaPrima correzione
Ritardo di input > 50%longAnimationFrameEntries tipo di invocatoreValutazione dello script durante il caricamento; timer; un'interazione precedente ancora in corsoRimandare o rimuovere gli script di terze parti; suddividere i pacchetti; spostare il lavoro periodico fuori dal thread
Tempo di elaborazione > 50%longestScript and totalScriptDurationUn gestore di eventi costoso; un aggiornamento di stato che innesca un rendering completoDare la precedenza all'interno del dispositivo di movimentazione; spostare le operazioni non visive dopo la verniciatura successiva
Ritardo della presentazione > 50%totalStyleAndLayoutDurationDOM di grandi dimensioni; layout instabile; pesante requestAnimationFrame lavoroRiduci le dimensioni del DOM; applica content-visibility; lettura e scrittura in stile batch
Nessuna sottosezione > 50%Tutte le risposte in alto sono corretteCongestione generale del thread principaleTrattare come un ritardo di ingresso, rimisurare, quindi ri-diramare.

Ramo 3: assegnare un nome allo script

La build di attribuzione include le voci Long Animation Frame accanto a ciascun campione INP. attribution.longestScript ti fornisce l'invocatore, la funzione e il file sorgente dello script peggiore nell'interazione; totalScriptDuration aggrega tutto ciò che supera i 5 ms. È qui che un vago "React è lento" diventa un percorso di file. Controlla il tipo di invoker: classic-script or module-script punti alla valutazione del tempo di caricamento, mentre user-callback or event-listener punta a qualcosa in esecuzione dopo il caricamento: un osservatore, un timer, un listener di analisi (web.dev).

Punto 4: è tuo o di terzi?

Ordina l'attribuzione degli script in base all'origine. I gestori di tag, le piattaforme di consenso, gli strumenti di registrazione delle sessioni e i widget di chat installano listener globali che vengono eseguiti prima del tuo a ogni clic. Se un'origine di terze parti compare in più di un quarto dei tuoi campioni peggiori, la soluzione è più commerciale che tecnica: riduci l'ambito del tag, caricalo all'interazione o spostalo lato server. Non rifattorizzare il tuo gestore per recuperare i 40 ms che un widget di chat impiega comunque.

Ramo 5: riprodurlo in laboratorio, quindi correggere il frame

Prendi il selettore da attribution.interactionTarget, apri Chrome DevTools con la limitazione della CPU adatta al mix di dispositivi sul campo e registra l'interazione. Cerca un'attività su ms 50, la soglia del compito lungo (web.dev), e dividerlo mediante cessione.

Nave scheduler.yield() con un fallback. Chrome ed Edge lo supportano dalla versione 129 e Firefox dalla 142, ma Safari non lo fa, né su desktop né su iOS.e MDN lo contrassegna come disponibilità limitata piuttosto che Baseline (ND, posso usare). Per un pubblico turco o del Golfo con un'ampia quota iOS, un setTimeout Il piano di riserva non è facoltativo.

Ramo 6: misurare il mercato a cui effettivamente si vende

Le medie globali di CrUX nascondono il mercato che ti paga. Il dataset CrUX di BigQuery pubblica tabelle per paese. chrome-ux-report.country_tr.YYYYMM per la Turchia, lo stesso schema per qualsiasi codice paese di due lettere, aggiornato mensilmente, con fattore di forma del dispositivo e tipo di connessione effettivo come dimensioni (Chrome per sviluppatoriL'API pubblica di CrUX non espone il paese, quindi questa porzione è disponibile solo per BigQuery.

Confronta la tua origine con la tabella dei paesi per ogni mercato in cui vendi. Un rivenditore che serve Turchia, Germania e Paesi del Golfo trova regolarmente tre diverse distribuzioni INP da un unico codice sorgente, perché la combinazione di dispositivi e le condizioni di rete sono diverse. Concentrati sul mercato che genera il fatturato, non su quello in cui si trova la tua sede.

Ramo 7: dimostra che ha spostato qualcosa

Considera la correzione come un esperimento, non come un'implementazione definitiva. Trendyol, un mercato turco, ha tracciato un INP mobile di 963 ms a un'attività lunga 700-900 ms causata da una callback di IntersectionObserver all'interno di un componente React, ha differito l'aggiornamento dello stato con scheduler.yield()e ha ridotto l'INP del 75° percentile da circa 1,400 ms a circa 650 ms in sei mesi. Il suo test A/B ha mostrato un Aumento dell'1% dei clic dai risultati di ricerca ai dettagli del prodotto per sessione. (web.dev). Redbus ha ridotto le interazioni di caricamento differito da 870–900 ms a 350–370 ms, ha migliorato un'interazione di input di testo del 72% e ha riportato un Aumento del 7% delle vendite complessive (web.dev).

Si noti la scala di valutazione corretta: 1%, non 40%. Il che ci porta a un dato che merita di essere corretto.

La cifra dell'8.4% merita una precisazione.

Il dato più citato in questo campo è che un miglioramento di 0.1 s nella velocità mobile aumenta la conversione al dettaglio dell'8.4% e i viaggi del 10.1%. Proviene da uno studio reale: 55 e Deloitte, commissionato da Google, 37 marchi, oltre 30 milioni di sessioni (web.dev). Ma ha misurato metriche di carico come il tempo di caricamento della pagina e la latenza del server, non INPI dati si riferiscono a 30 giorni alla fine del 2019 e non era presente un gruppo di controllo, quindi si tratta di una correlazione osservata, non di un effetto causale. Utilizzateli per avviare una discussione sul budget, non per prevedere il ritorno sull'investimento di una soluzione per la latenza di interazione.

[DATI INTERNI NECESSARI: Switas prima/dopo p75 INP e delta di conversione da un incarico presso un cliente, per sostituire i casi di studio pubblici con prove di prima parte.]

Dove questo albero decisionale si interrompe

  • Origini a basso traffico. Con dati di campo scarsi, il 75° percentile è rumore. Al di sotto di circa 1,000 interazioni per modello a settimana, profila in laboratorio e accetta che non puoi verificare la vittoria in CrUX.
  • Gli utenti di Safari e Firefox sono invisibili. CrUX è disponibile solo su Chrome. Se una quota significativa del tuo fatturato proviene da Safari su iOS, i tuoi dati INP descrivono una popolazione che non stai misurando completamente.
  • Il problema dello scorrimento a scatti non rientra nell'ambito di questa discussione. INP ignora lo scorrimento, quindi questo albero non troverà mai il problema in un elenco a scorrimento infinito che risulta scomodo da usare ma supera il test.
  • Individua la latenza, non i debiti di progettazione. Un'interazione di 180 ms su un pannello di filtri confusionario è un problema di esperienza utente che questo albero non può rilevare.

FAQ

INP è la stessa cosa di First Input Delay?
No. FID misurava solo il ritardo prima dell'esecuzione dei gestori della prima interazione. INP copre l'intera latenza di un'interazione rappresentativa durante la visita, inclusa l'esecuzione dei gestori e la successiva visualizzazione.

Perché il mio punteggio Lighthouse sembra a posto mentre INP è rosso?
Lighthouse è uno strumento di laboratorio e non può misurare l'INP: non c'è un utente reale che preme alcun pulsante. Indicatori come il tempo totale di blocco presentano una correlazione debole. Consulta invece la sezione relativa ai campi di PageSpeed ​​Insights.

Quanto tempo passerà prima che una correzione venga visualizzata in CrUX?
CrUX effettua i report con una finestra temporale mobile di 28 giorni, mentre le tabelle di BigQuery vengono pubblicate mensilmente. È prevedibile un segnale parziale dopo circa quattro settimane e una lettura completa dopo due rilasci mensili.

Posso correggere INP senza modificare il framework?
Spesso sì. La soluzione di Trendyol consisteva nell'inserire un `yield` all'interno di una callback su React 16.9, senza necessità di aggiornamento. Anche il differimento dei tag di terze parti è indipendente dal framework.

Il banner di consenso influisce sulla protezione dei dati personali?
Può accadere in due modi: lo script del banner stesso compete per il thread principale durante il caricamento e la decisione di consenso spesso innesca un'ondata di caricamento di tag subito dopo. Misura separatamente la prima interazione successiva al consenso.

Ho bisogno di un fornitore RUM, oppure la libreria Web Vitals è sufficiente?
La configurazione di attribuzione più un endpoint beacon sono sufficienti per eseguire questo albero. Un fornitore acquista fidelizzazione, segmentazione e dashboard, non dati di attribuzione migliori.

Devo ottimizzare la pagina web per la SEO o per le conversioni?
Decidete di puntare sulla conversione. I Core Web Vitals sono un segnale di ranking, ma i casi aziendali documentati — l'1% su Trendyol, il 7% su redBus — dimostrano effetti sulla qualità dell'interazione che giustificano di per sé il lavoro svolto.

Esegui questo comando sulla tua pagina di inserzione

Prendi il tuo modello con il maggior traffico, strumentalo con la build di attribuzione e percorri i rami da 0 a 7 in ordine. Se preferisci che l'albero venga eseguito sui tuoi dati di campo, con la sezione per paese e il design dell'esperimento inclusi, il nostro team di prestazioni web fa esattamente questo impegno.

fonti


Articoli Correlati

Switas come visto su

Magnify: scalare l'influencer marketing con Engin Yurtdakul

Scopri il nostro caso di studio su Microsoft Clarity

Abbiamo evidenziato Microsoft Clarity come un prodotto sviluppato pensando a casi d'uso pratici e reali, da persone che conoscono bene le sfide che aziende come Switas devono affrontare. Funzionalità come i clic collezionati e il monitoraggio degli errori JavaScript si sono rivelate preziose nell'identificare le frustrazioni degli utenti e i problemi tecnici, consentendo miglioramenti mirati che hanno avuto un impatto diretto sull'esperienza utente e sui tassi di conversione.