Interaction to Next Paint (INP): Cos'è, come misurarlo e migliorarlo

Interaction to Next Paint (INP) è un Core Web Vital che misura quanto rapidamente una pagina web risponde alle interazioni dell'utente come clic, tocchi e pressioni di tasti. L'INP cattura l'intera latenza dall'input dell'utente attraverso l'elaborazione JavaScript fino all'aggiornamento visivo finale sullo schermo. Un buon punteggio INP è di 200 millisecondi o meno al 75° percentile. L'INP ha sostituito il First Input Delay (FID) come Core Web Vital a marzo 2024.

Cos'è Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) è una metrica Core Web Vitals che misura la reattività di una pagina web durante l'intera visita di un utente. A differenza del suo predecessore First Input Delay (FID), che misurava solo il ritardo prima che iniziasse il gestore di eventi della prima interazione, l'INP valuta ogni interazione che un utente compie con la pagina e riporta un singolo valore che rappresenta la reattività complessiva della pagina.

Ogni volta che un utente fa clic su un pulsante, tocca un link, preme un tasto sulla tastiera o interagisce con un controllo personalizzato, il browser misura il tempo totale dal momento dell'input a quando il fotogramma successivo viene renderizzato sullo schermo. L'INP seleziona una delle interazioni più lente come punteggio di reattività della pagina. Per le pagine con meno di 50 interazioni totali, l'INP riporta la singola interazione peggiore. Per le pagine con molte interazioni, l'INP utilizza tipicamente il 98° percentile per escludere eventuali valori anomali occasionali.

Un INP basso significa che la pagina risponde in modo affidabile all'input dell'utente in modo tempestivo. Un INP alto significa che la pagina risulta lenta, non reattiva o "scattosa" perché il browser non riesce a elaborare le interazioni e ad aggiornare lo schermo abbastanza velocemente.

INP vs FID: Cosa è cambiato e perché

L'INP ha ufficialmente sostituito il First Input Delay (FID) come Core Web Vital a marzo 2024. Google ha ritirato il FID perché presentava due limitazioni fondamentali che lo rendevano una misura incompleta della reattività della pagina.

In primo luogo, il FID misurava solo la prima interazione su una pagina. Se il primo clic di un utente era veloce ma le interazioni successive erano lente, il FID riportava un punteggio positivo nonostante l'esperienza scadente. L'INP misura tutte le interazioni durante l'intera sessione, fornendo un quadro molto più accurato della reattività reale.

In secondo luogo, il FID misurava solo la fase di input delay, il che significa che catturava il tempo che il browser trascorreva in attesa prima di iniziare a elaborare l'evento. Ignorava completamente il tempo trascorso per eseguire il codice del gestore di eventi (processing time) e il tempo necessario per renderizzare il risultato visivo sullo schermo (presentation delay). L'INP cattura tutte e tre le fasi, offrendo agli sviluppatori una visione completa della latenza di interazione.

Il passaggio dal FID all'INP ha causato un calo di circa 5 punti percentuali nei tassi di superamento dei Core Web Vitals su dispositivi mobili, secondo l'HTTP Archive Web Almanac 2024. Questo è successo perché molti siti che sembravano reattivi con il FID avevano interazioni successive lente che l'INP ora cattura.

Quali interazioni misura l'INP?

L'INP misura solo le interazioni che coinvolgono input utente discreti che il browser può osservare tramite i gestori di eventi. Comprendere quali interazioni contano è essenziale per un debug e un'ottimizzazione accurati.

Interazioni che contano per l'INP

• Clic del mouse (inclusi clic su pulsanti, link, caselle di controllo e controlli personalizzati)
• Tocchi su schermi touch (equivalenti ai clic sui dispositivi mobili)
• Pressioni di tasti su una tastiera fisica o su schermo (inclusa la digitazione nei campi dei moduli, la pressione di Invio, l'uso di scorciatoie da tastiera)

Interazioni che NON contano per l'INP

• Lo scorrimento (scrolling) non conta perché viene gestito dal thread compositore del browser e in genere non blocca il main thread
• Il passaggio del mouse (hovering) non conta perché l'hovering è uno stato continuo del puntatore, non un'interazione utente discreta
• I gesti di trascinamento (drag) non contano, sebbene il pointerdown iniziale che dà inizio a un trascinamento possa innescare una misurazione INP
• Le transizioni e le animazioni CSS che si verificano senza l'input dell'utente non sono interazioni

Un malinteso comune è che lo scorrimento influisca sull'INP. Non è così. Tuttavia, se la tua pagina utilizza uno scorrimento basato su JavaScript anziché lo scorrimento nativo del browser, quei gestori di scorrimento JavaScript possono innescare callback di eventi che il browser misura come interazioni. Questo è uno dei motivi per cui lo scorrimento CSS nativo supera costantemente lo scorrimento JavaScript in termini di reattività.

Le tre fasi di un'interazione INP

Ogni interazione misurata dall'INP è composta da tre fasi sequenziali. Il valore INP totale è la somma di tutte e tre. Comprendere ogni fase è fondamentale perché la strategia di ottimizzazione differisce per ciascuna di esse.

1. Input Delay

L'input delay è il tempo tra quando l'utente interagisce con la pagina e quando il browser inizia a eseguire i gestori di eventi associati. Questo ritardo si verifica perché il main thread del browser potrebbe essere occupato con altro lavoro, come l'analisi di JavaScript, l'esecuzione di attività programmate in precedenza o l'elaborazione di altre callback di eventi.

L'input delay è particolarmente problematico durante la fase di caricamento della pagina, quando molti script vengono analizzati ed eseguiti contemporaneamente. I dati di CoreDash mostrano che le interazioni durante la fase di caricamento hanno un INP p75 di 132 ms, rispetto a soli 50 ms per le interazioni dopo il completamento del caricamento della pagina. È una differenza di 2,6 volte. Ridurre la contesa sul main thread durante l'avvio della pagina è uno dei modi più efficaci per migliorare l'INP.

Alla mediana, l'input delay è la componente più piccola dell'INP. Ma al 90° percentile, l'input delay diventa il contributore dominante perché i task lunghi sul main thread possono ritardare l'elaborazione degli eventi di centinaia di millisecondi. L'HTTP Archive Web Almanac 2024 ha rilevato che meno del 25% dei siti web mantiene la durata dei task al di sotto della soglia raccomandata di 50 ms.

2. Processing Time

Il processing time è il tempo totale che il browser trascorre eseguendo tutte le callback dei gestori di eventi associate all'interazione. Questo include qualsiasi JavaScript eseguito in risposta all'evento, dalla convalida del modulo agli aggiornamenti di stato fino alle chiamate di tracciamento analitico.

Il processing time rappresenta una parte significativa dell'INP totale. Se un gestore di eventi esegue operazioni DOM costose, effettua chiamate API sincrone o esegue cicli inefficienti, il processing time aumenterà vertiginosamente. Un pattern comune che gonfia il processing time è l'esecuzione di codice non essenziale (come eventi analitici o callback di tag di terze parti) all'interno dello stesso gestore di eventi dell'aggiornamento visivo critico.

3. Presentation Delay

Il presentation delay è il tempo tra quando tutti i gestori di eventi hanno terminato l'esecuzione e quando il browser presenta il fotogramma successivo contenente l'aggiornamento visivo. Questa fase include il ricalcolo degli stili, il calcolo del layout, la pittura e la composizione.

Alla mediana, il presentation delay è la componente più grande dell'INP perché ogni interazione richiede almeno un passaggio di rendering. Le pagine con un DOM grande o profondamente annidato impiegano più tempo per ricalcolare gli stili e calcolare il layout. Le Single Page Application che re-renderizzano grandi alberi di componenti dopo i cambiamenti di stato sono particolarmente suscettibili a un elevato presentation delay.

Quali sono i punteggi INP buoni e cattivi?

Per superare la valutazione Core Web Vitals per la metrica Interaction to Next Paint, il 75° percentile di tutte le interazioni registrate sul campo deve rimanere al di sotto di 200 millisecondi:

• Un INP inferiore o uguale a 200 millisecondi significa che la tua pagina ha una buona reattività.
• Un INP compreso tra 200 e 500 millisecondi significa che la reattività della tua pagina deve essere migliorata.
• Un INP superiore a 500 millisecondi significa che la tua pagina ha una scarsa reattività.

È importante capire che l'INP utilizza il 75° percentile, non la media. Ciò significa che il 75% dei tuoi utenti reali deve sperimentare interazioni più veloci di 200 ms. La metodologia del 75° percentile assicura che la metrica rifletta l'esperienza degli utenti su dispositivi e connessioni più lenti, non solo quelli con hardware di fascia alta.

Come misurare Interaction to Next Paint (INP)

L'Interaction to Next Paint può essere misurato solo con strumenti sul campo che catturano le interazioni reali degli utenti. A differenza delle metriche di laboratorio che simulano un singolo caricamento di pagina, l'INP richiede visitatori reali che fanno clic, toccano e digitano sulle tue pagine. Non c'è modo di ottenere un punteggio INP significativo da un test sintetico perché l'INP dipende dal reale comportamento umano.

Ottieni le metriche INP ufficiali

Puoi ottenere le metriche INP ufficiali da PageSpeed Insights o dalla dashboard CrUX e Google BigQuery. PageSpeed Insights riporta il punteggio al 75° percentile basato sugli ultimi 28 giorni di dati degli utenti di Chrome. Google BigQuery fornisce più contesto storico e consente query personalizzate sull'intero set di dati CrUX.

Anche Google Search Console riporta i problemi di INP nella sezione Core Web Vitals, raggruppando gli URL interessati e segnalando le pagine che necessitano di miglioramenti o che hanno una reattività scarsa.

Monitora l'INP con il Real User Monitoring

Sebbene il set di dati ufficiale CrUX sia la fonte definitiva per i punteggi Core Web Vitals, è altamente anonimizzato e non supporta il monitoraggio in tempo reale o filtri dettagliati. Ecco perché i professionisti delle prestazioni web si affidano agli strumenti di Real User Monitoring (RUM) come CoreDash per ottenere dati INP azionabili in tempo reale. Gli strumenti RUM raccolgono misurazioni INP da ogni caricamento di pagina, le attribuiscono a elementi specifici, stati di caricamento e tipi di dispositivo, e ti permettono di diagnosticare esattamente quali interazioni stanno causando problemi.

Misura l'INP per la sessione corrente

Il modo più semplice per eseguire il debug dell'INP durante lo sviluppo è tramite i Chrome DevTools. Apri il pannello Prestazioni (Performance) e utilizza la modalità "timespan" in Lighthouse per registrare le interazioni e visualizzare la loro latenza. Puoi anche usare l'estensione Core Web Vitals Visualizer, che sovrappone i punteggi INP sulla pagina mentre interagisci con essa.

Per un debug pratico, utilizza la libreria JavaScript Web Vitals di Google per registrare le singole interazioni nella console:

Registra l'INP nella console con la libreria JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Come migliorare Interaction to Next Paint

Migliorare l'Interaction to Next Paint richiede l'ottimizzazione di tutte e tre le fasi: input delay, processing time e presentation delay. La tua pagina potrebbe rispondere istantaneamente alla maggior parte delle interazioni, ma se anche solo una è lenta, può definire l'intero punteggio INP. Ecco perché è necessario un approccio sistematico.

SUGGERIMENTO PageSpeed: la maggior parte delle volte l'INP sarà molto peggiore quando un utente interagisce con la pagina durante la fase di avvio del caricamento della pagina. Ecco perché, durante il debug dell'INP, ha senso registrare tutte le interazioni oltre allo stato di caricamento della pagina!

1. Riduci al minimo l'input delay: Previeni i task lunghi sul main thread

Di solito qualsiasi pagina è meno reattiva durante la fase di avvio della pagina, quando avviene la maggior parte del lavoro sul main thread (analisi, decodifica, rendering e scripting). Per mantenere il main thread il più libero possibile:

• Rimuovi il codice non utilizzato. Usa il tree shaking per eliminare il codice morto e il code splitting per dividere il tuo bundle in pezzi più piccoli che si caricano su richiesta. Verifica la copertura del tuo codice usando Chrome DevTools per identificare gli script che si caricano ma non vengono mai eseguiti.
• Carica il codice non essenziale durante il tempo di inattività (idle time) del browser. Hai davvero bisogno di un widget di chat durante i primi 500 ms del caricamento della pagina? Pianifica gli script non critici con requestIdleCallback() affinché vengano eseguiti solo quando il browser è inattivo.
• Identifica e riscrivi gli script lenti che consumano eccessive risorse CPU. Usa il pannello Prestazioni di Chrome per trovare gli script con lunghi tempi di esecuzione e colpisci quest'ultimi per l'ottimizzazione.
• Mantieni la tua pagina facile da renderizzare. Evita dimensioni DOM eccessive, immagini in eccesso, troppi video e animazioni CSS ad uso intensivo della CPU.
• Usa async e defer sui tag script per impedire che JavaScript blocchi il parser HTML. Prendi in considerazione l'idea di differire i JavaScript non critici interamente fino a quando la pagina non è diventata interattiva.

Suddividi i task lunghi con scheduler.yield()

JavaScript viene eseguito sul main thread del browser utilizzando un modello "run to completion" (esecuzione fino al completamento): una volta iniziato, un task blocca il main thread fino al termine. I task lunghi (oltre i 50 ms) impediscono al browser di rispondere all'input dell'utente. L'API scheduler.yield() ti consente di creare esplicitamente punti di rilascio all'interno di codice in esecuzione prolungata, dando al browser l'opportunità di elaborare le interazioni dell'utente in sospeso prima di continuare.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback per browser senza scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Utilizzo: dividi un task lungo in frammenti più piccoli
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Cedi il controllo ogni 5 elementi per permettere al browser di gestire l'input utente
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Differisci il lavoro non critico con requestIdleCallback

Utilizza requestIdleCallback() per pianificare le attività non essenziali (analisi, telemetria, prefetching) quando il browser è inattivo. Questo mantiene il main thread libero per le interazioni dell'utente e riduce direttamente l'input delay.

// Invece di eseguire l'analisi in modo sincrono:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critico: aggiorna l'UI immediatamente
  showConfirmation();

  // Non critico: invia analisi durante il tempo di inattività
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Usa listener di eventi passivi

Per gli eventi che non hanno bisogno di richiamare preventDefault(), contrassegna i tuoi listener di eventi come passivi. Questo dice al browser che non deve aspettare che il tuo gestore decida se annullare il comportamento predefinito, consentendo uno scorrimento più fluido e una risposta al tocco più veloce.

// Listener passivo: il browser non aspetta preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Riduci al minimo il processing time: Fornisci feedback immediato

Quando un visitatore esegue un'azione come l'invio di un modulo o l'aggiunta di un elemento al carrello, non aspettare la conferma lato server prima di aggiornare l'UI. Fornisci un feedback visivo immediato ("Invio modulo in corso...", "Aggiunta elemento al carrello...") e poi completa l'operazione in background.

Inoltre, cedi il controllo al main thread il prima possibile dopo l'aggiornamento visivo critico. Poiché JavaScript segue un modello "run to completion", blocca il main thread finché tutto il codice nella callback non è stato eseguito. Puoi creare manualmente un punto di rilascio in cui il browser può aggiornare il layout per poi continuare a eseguire il restante codice non critico.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Invio modulo ... per favore attendi";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Riduci al minimo il presentation delay: Mantieni le cose semplici

Quando la pagina deve aggiornarsi dopo un'interazione, il browser deve ricalcolare gli stili, eseguire il layout, dipingere i pixel modificati e comporre il risultato. La complessità e le dimensioni del tuo DOM determinano direttamente quanto tempo richiede questo lavoro di rendering.

Alcuni ambienti SPA scarsamente ottimizzati re-renderizzano fin troppi contenuti dopo ogni interazione. Ad esempio, quando si aggiorna un contatore, assicurati di aggiornare solo l'elemento del contatore, non l'intero albero dei componenti.

Segui queste due regole d'oro per un rendering più veloce:

1. Mantieni il DOM piccolo e semplice. È molto più semplice per un browser renderizzare una pagina con meno elementi DOM (nodi HTML) rispetto a una pagina con strutture DOM complesse e profondamente annidate. Cerca di mantenere il numero totale di elementi DOM inferiore a 1.400 ed evita annidamenti più profondi di 32 livelli.
2. Utilizza content-visibility per il lazy-rendering dei contenuti fuori schermo. La proprietà CSS content-visibility: auto accelera il rendering iniziale differendo il rendering dei contenuti fuori dallo schermo fino a quando l'utente non vi scorre vicino.

/* Applica content-visibility alle sezioni fuori schermo */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Debug dell'INP con l'API Long Animation Frames (LoAF)

L'API Long Animation Frames (LoAF) è uno strumento potente per diagnosticare i problemi di INP. Fornisce informazioni dettagliate sui fotogrammi che impiegano più di 50 ms per il rendering, inclusi i dati di attribuzione degli script che ti dicono esattamente quali script stanno contribuendo alle interazioni lente.

A differenza della vecchia Long Tasks API, LoAF cattura il tempo di rendering oltre al tempo di esecuzione dello script, rendendolo particolarmente utile per diagnosticare i problemi di presentation delay. Le voci LoAF includono la durata del fotogramma, la durata del blocco e un array di voci di script che mostrano l'URL di origine, il nome della funzione e il tempo di esecuzione di ogni script eseguito durante il fotogramma.

// Osserva i Long Animation Frames per trovare i colli di bottiglia dell'INP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Analizza solo i fotogrammi più lunghi di 100 ms
    if (entry.duration > 100) {
      console.log('Fotogramma lungo:', entry.duration + 'ms');

      // Registra ogni script che ha contribuito
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Funzione:', script.sourceFunctionName,
          'Durata:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Strumenti RUM come CoreDash integrano automaticamente i dati LoAF, correlando i long animation frames a specifiche interazioni dell'utente, così puoi identificare esattamente quale script, su quale pagina, per quale tipo di interazione, sta causando i tuoi punteggi INP peggiori.

INP e LCP: Il collegamento con i Long Task

I task lunghi sul main thread influiscono sia sull'INP che sul Largest Contentful Paint (LCP). Un task JavaScript che blocca il main thread per 200 ms ritarda l'elaborazione degli eventi (peggiorando l'INP) e ritarda anche il rendering dell'elemento LCP da parte del browser (peggiorando l'LCP). Quando ottimizzi il tuo main thread frammentando i task lunghi, differendo i JavaScript non critici e riducendo il tempo di esecuzione degli script, migliori entrambe le metriche contemporaneamente.

Casi di studio: Miglioramenti dell'INP in produzione

redBus: Miglioramento della conversione su mobile dall'80 al 100%

redBus, una delle più grandi piattaforme di biglietteria per autobus online al mondo, ha investito nell'ottimizzazione dei Core Web Vitals nei suoi mercati globali. La loro attenzione nel ridurre il tempo di esecuzione di JavaScript e nell'ottimizzare i gestori di eventi ha contribuito a un miglioramento dall'80 al 100% dei tassi di conversione su dispositivi mobili nei loro mercati globali. I miglioramenti sono stati guidati da una combinazione di riduzione del tempo di blocco del main thread, ottimizzazione del caricamento di script di terze parti e implementazione del code splitting per ridurre la quantità di JavaScript analizzato durante l'avvio della pagina.

Preply: INP da 250 ms a 185 ms, $200.000 all'anno in risparmi SEO stimati

Preply, una piattaforma di tutoraggio linguistico online, ha migliorato l'INP della propria Home page da circa 250 ms a 185 ms e l'INP della pagina di ricerca da circa 250 ms a 175 ms. Il team ha ottenuto questi risultati profilando la propria applicazione React, identificando ed eliminando re-renderizzazioni non necessarie e differendo callback di eventi non critici. I punteggi migliorati dei Core Web Vitals sono stati correlati a posizionamenti di ricerca più elevati, traducendosi in un valore di ricerca organica stimato in $200.000 all'anno.

Cosa mostrano i dati del mondo reale sull'INP

Il divario INP tra dispositivi mobili e desktop

I dati di CoreDash rivelano che l'INP su dispositivi mobili (131 ms al p75) è 2,8 volte peggiore rispetto all'INP su desktop (48 ms al p75). Questo è il divario maggiore tra dispositivi per qualsiasi metrica Core Web Vital. I dispositivi mobili hanno processori più lenti, meno memoria e una latenza di rete maggiore, fattori che contribuiscono a tempi di blocco del main thread più lunghi e a un'elaborazione degli eventi più lenta. Su desktop, il 95,6% delle interazioni ottiene un punteggio INP "buono", mentre sui dispositivi mobili tale cifra scende all'88,0%. Gli utenti mobili sperimentano anche 5 volte più eventi INP "scadenti" (9,6% rispetto all'1,9%).

Interazioni con la tastiera vs puntatore

I dati di CoreDash mostrano che le interazioni tramite tastiera (75 ms p75) sono del 56% più lente rispetto alle interazioni tramite puntatore (49 ms p75). Anche gli eventi da tastiera presentano molte più esperienze scadenti: il 7,4% delle interazioni da tastiera si traduce in un INP scadente, rispetto a solo l'1,4% per le interazioni tramite puntatore. Questo divario è probabilmente dovuto al fatto che gli eventi della tastiera, specialmente nei campi dei moduli, attivano elaborazioni più complesse come la convalida dell'input, i suggerimenti di autocompletamento e gli aggiornamenti di stato.

Interazioni durante il caricamento vs dopo il caricamento

Le interazioni che si verificano durante il caricamento della pagina hanno un INP drasticamente più alto di quelle che avvengono dopo che la pagina si è caricata completamente. I dati di CoreDash mostrano che le interazioni durante la fase di "caricamento" (loading) hanno un INP p75 di 132 ms, rispetto a soli 50 ms per le interazioni post-caricamento. È una differenza di 2,6 volte. Persino le interazioni durante la fase "dom-content-loaded" (75 ms) mostrano un INP elevato perché gli script asincroni e le risorse secondarie sono ancora in fase di elaborazione. Questi dati supportano fortemente la raccomandazione di differire JavaScript non critico per ridurre la contesa del main thread durante la fase di avvio della pagina.

Tassi di superamento INP globali

Secondo l'HTTP Archive Web Almanac 2024, il 74% di tutte le pagine per dispositivi mobili ottiene un punteggio INP "buono" (rispetto al 55% nel 2022). Tuttavia, solo il 53% dei 1.000 siti web più visitati supera l'INP. I siti web ad alto traffico tendono ad avere JavaScript più complessi, più script di terze parti e strutture DOM più intricate, tutti elementi che contribuiscono a peggiorare la reattività. Sul desktop, il 97% delle pagine raggiunge buoni punteggi INP, evidenziando l'enorme divario di prestazioni tra dispositivi mobili e desktop. Il tempo di blocco totale mediano nei test di laboratorio è di 67 ms su desktop, ma di 1.209 ms su dispositivi mobili.

Domande frequenti

Approfondimenti correlati

Questa pagina hub copre i fondamenti dell'Interaction to Next Paint. Per indicazioni approfondite su aspetti specifici dell'ottimizzazione dell'INP, esplora questi articoli dedicati:

• Trova e risolvi i problemi INP: Una metodologia diagnostica passo-passo che utilizza Search Console, i dati RUM e i Chrome DevTools per identificare esattamente quali interazioni stanno causando i tuoi punteggi INP peggiori.
• INP Input Delay: Un approfondimento sulla prima fase dell'INP. Scopri come i task lunghi sul main thread bloccano l'elaborazione degli eventi e come ridurre al minimo l'input delay con la pianificazione dei task, il code splitting e i web worker.
• INP Processing Time: Un approfondimento sulla seconda fase dell'INP. Scopri come ottimizzare le callback dei gestori di eventi, assegnare la priorità al codice critico, differire il lavoro non essenziale e utilizzare le funzionalità di concorrenza di React per ridurre il processing time.
• INP Presentation Delay: Un approfondimento sulla terza fase dell'INP. Scopri come le dimensioni del DOM, il layout thrashing e il rendering lato client contribuiscono agli aggiornamenti visivi lenti e come ridurre il presentation delay.

Potresti trovare utili anche queste guide all'ottimizzazione PageSpeed per migliorare l'INP:

• Migliora l'INP: Abbandona lo scorrimento JavaScript
• Async vs Defer: Strategie di caricamento JavaScript
• 14 metodi per differire JavaScript
• Widget di chat con Core Web Vitals perfetti
• Risoluzione: Evita dimensioni DOM eccessive