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

Interaction to Next Paint (INP) è un Core Web Vital che misura la velocità con cui una pagina web risponde alle interazioni degli utenti come clic, tocchi e pressioni dei tasti. L'INP cattura la latenza completa 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 Vital che misura la reattività di una pagina web durante l'intera visita dell'utente. A differenza del suo predecessore First Input Delay (FID), che misurava solo il ritardo prima dell'inizio dell'event handler della prima interazione, l'INP valuta ogni interazione che un utente effettua con la pagina e riporta un singolo valore che rappresenta la reattività complessiva della pagina.

Ogni volta che un utente clicca 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 frame successivo viene dipinto 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 filtrare i 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 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é aveva due limitazioni fondamentali che lo rendevano una misura incompleta della reattività della pagina.

Primo, 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 avrebbe riportato 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.

Secondo, il FID misurava solo la fase di input delay, ovvero catturava il tempo che il browser impiegava in attesa prima di iniziare a elaborare l'evento. Ignorava completamente il tempo speso per eseguire il codice dell'event handler (tempo di elaborazione) e il tempo necessario per dipingere il risultato visivo sullo schermo (presentation delay). L'INP cattura tutte e tre le fasi, offrendo agli sviluppatori una visione completa della latenza dell'interazione.

La transizione da FID a INP ha causato un calo di circa 5 punti percentuali nei tassi di superamento dei Core Web Vitals su mobile, secondo l'HTTP Archive 2025 Web Almanac. Questo è successo perché molti siti che apparivano reattivi sotto 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 discreti dell'utente che il browser può osservare attraverso gli event handler. Capire 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, checkbox e controlli personalizzati)
• Tocchi su touchscreen (equivalenti ai clic su dispositivi mobili)
• Pressioni dei tasti su una tastiera fisica o su schermo (inclusa la digitazione nei campi dei form, la pressione di Invio, l'uso di scorciatoie da tastiera)

Interazioni che NON contano per l'INP

• Lo scrolling non conta perché viene gestito dal compositor thread del browser e tipicamente non blocca il main thread
• L'hover (mouseover) non conta perché l'hover è uno stato continuo del puntatore, non un'interazione discreta dell'utente
• I gesti di trascinamento non contano, anche se il pointerdown iniziale che avvia un trascinamento può generare una voce INP
• Le transizioni e animazioni CSS che avvengono senza input dell'utente non sono interazioni

Un'idea sbagliata comune è che lo scrolling influenzi l'INP. Non è così. Tuttavia, se la tua pagina utilizza scrolling basato su JavaScript invece dello scrolling nativo del browser, quegli handler di scroll JavaScript possono attivare callback di eventi che il browser misura come interazioni. Questo è uno dei motivi per cui lo scrolling CSS nativo supera costantemente lo scrolling 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 è diversa per ciascuna.

1. Input Delay

L'input delay è il tempo tra il momento in cui l'utente interagisce con la pagina e il momento in cui il browser inizia a eseguire gli event handler associati. Questo ritardo si verifica perché il main thread del browser potrebbe essere occupato con altro lavoro, come il parsing di JavaScript, l'esecuzione di task precedentemente programmati o l'elaborazione di altri callback di eventi.

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

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

2. Tempo di elaborazione

Il tempo di elaborazione è il tempo totale che il browser impiega per eseguire tutti i callback degli event handler associati all'interazione. Questo include qualsiasi JavaScript che viene eseguito in risposta all'evento, dalla validazione dei form agli aggiornamenti di stato fino alle chiamate di tracciamento analitico.

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

3. Presentation Delay

Il presentation delay è il tempo tra il momento in cui tutti gli event handler hanno terminato l'esecuzione e il momento in cui il browser presenta il frame successivo contenente l'aggiornamento visivo. Questa fase include il ricalcolo degli stili, il calcolo del layout, il painting e il compositing.

Alla mediana, il presentation delay è la sotto-parte 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 ed eseguire il layout. Le Single Page Application che ri-renderizzano grandi alberi di componenti dopo i cambiamenti di stato sono particolarmente suscettibili a un presentation delay elevato.

Quali sono punteggi INP buoni e cattivi?

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

• Un INP inferiore o uguale a 200 millisecondi significa che la tua pagina ha una buona reattività.
• Un INP tra 200 e 500 millisecondi significa che la reattività della tua pagina necessita di miglioramento.
• Un INP superiore a 500 millisecondi significa che la tua pagina ha una reattività scarsa.

È importante capire che l'INP utilizza il 75° percentile, non la media. Questo significa che il 75% dei tuoi utenti reali deve sperimentare interazioni più veloci di 200ms. La metodologia del 75° percentile assicura che la metrica rifletta l'esperienza degli utenti su dispositivi più lenti e connessioni più lente, 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 cliccano, toccano e digitano sulle tue pagine. Non c'è modo di ottenere un punteggio INP significativo da un test sintetico perché l'INP dipende dal comportamento umano reale.

Ottenere 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 del 75° percentile basato sugli ultimi 28 giorni di dati degli utenti Chrome. Google BigQuery fornisce più contesto storico e permette query personalizzate sull'intero dataset CrUX.

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

Tracciare l'INP con il Real User Monitoring

Mentre il dataset CrUX ufficiale è la fonte definitiva per i punteggi dei Core Web Vitals, è altamente anonimizzato e non supporta il monitoraggio in tempo reale o il filtraggio dettagliato. Ecco perché i professionisti delle prestazioni web si affidano a strumenti di Real User Monitoring (RUM) come CoreDash per ottenere dati INP pratici e 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.

Misurare l'INP per la sessione corrente

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

Per il debug pratico, usa 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, tempo di elaborazione e presentation delay. La tua pagina potrebbe rispondere istantaneamente alla maggior parte delle interazioni, ma se anche una sola interazione è lenta, può definire l'intero punteggio INP. Ecco perché è necessario un approccio sistematico.

PageSpeed TIP: 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é, quando si fa debug dell'INP, ha senso registrare tutte le interazioni così come lo stato di caricamento della pagina!

1. Minimizzare l'Input Delay: prevenire i task lunghi sul Main Thread

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

• Rimuovi il codice inutilizzato. Usa il tree shaking per eliminare il codice morto e il code splitting per suddividere il tuo bundle in chunk più piccoli che si caricano su richiesta. Verifica la copertura del 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à del browser. Hai davvero bisogno di un widget di chat durante i primi 500ms del caricamento della pagina? Programma gli script non critici con requestIdleCallback() per eseguirli solo quando il browser è inattivo.
• Identifica e riscrivi gli script lenti che consumano risorse CPU eccessive. Usa il pannello Performance di Chrome per trovare gli script con tempi di esecuzione lunghi e puntali per l'ottimizzazione.
• Mantieni la tua pagina facile da renderizzare. Evita DOM di grandi dimensioni, immagini eccessive, troppi video e animazioni CSS intensive per la CPU.
• Usa async e defer sui tag script per impedire a JavaScript di bloccare il parser HTML. Valuta di differire il JavaScript non critico completamente fino a dopo che la pagina è diventata interattiva.

Spezzare i task lunghi con scheduler.yield()

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

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

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Differire il lavoro non critico con requestIdleCallback

Usa requestIdleCallback() per programmare task non essenziali (analytics, telemetria, prefetching) per quando il browser è inattivo. Questo mantiene il main thread libero per le interazioni dell'utente e riduce direttamente l'input delay.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Usare event listener passivi

Per gli eventi che non necessitano di chiamare preventDefault(), contrassegna i tuoi event listener come passivi. Questo dice al browser che non deve aspettare che il tuo handler decida se annullare il comportamento predefinito, consentendo uno scrolling più fluido e una risposta al tocco più rapida.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimizzare il tempo di elaborazione: fornire feedback immediato

Quando un visitatore esegue un'azione come l'invio di un form o l'aggiunta di un articolo al carrello, non aspettare la conferma dal server prima di aggiornare l'interfaccia. Fornisci un feedback visivo immediato ("Invio del form in corso...", "Aggiunta dell'articolo 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 fino a quando tutto il codice nel callback è stato eseguito. Puoi creare manualmente un punto di yield dove il browser può aggiornare il layout e poi continuare a eseguire il codice non critico rimanente.

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

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  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. Minimizzare il Presentation Delay: mantenere 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 la dimensione del tuo DOM determinano direttamente quanto tempo richiede questo lavoro di rendering.

Alcuni ambienti SPA poco ottimizzati ri-renderizzano troppo contenuto 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ù facile per un browser renderizzare una pagina con meno elementi DOM (nodi HTML) rispetto a una pagina con strutture DOM profondamente annidate e complicate. Punta a meno di 1.400 elementi DOM totali ed evita annidamenti superiori a 32 livelli.
2. Usa content-visibility per il lazy-render del contenuto fuori schermo. La proprietà CSS content-visibility: auto velocizza il rendering iniziale differendo il rendering del contenuto fuori schermo fino a quando l'utente non scorre nelle sue vicinanze.

/* Apply content-visibility to off-screen sections */
.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 frame che richiedono più di 50ms per il rendering, inclusi dati di attribuzione degli script che ti dicono esattamente quali script stanno contribuendo alle interazioni lente.

A differenza della più vecchia Long Tasks API, LoAF cattura il tempo di rendering così come il tempo di esecuzione degli script, rendendola particolarmente utile per diagnosticare problemi di presentation delay. Le voci LoAF includono la durata del frame, la durata di blocco e un array di voci script che mostrano l'URL sorgente, il nome della funzione e il tempo di esecuzione di ogni script eseguito durante il frame.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

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

Gli strumenti RUM come CoreDash integrano automaticamente i dati LoAF, correlando i frame di animazione lunghi con specifiche interazioni dell'utente così puoi identificare esattamente quale script, su quale pagina, per quale tipo di interazione, sta causando i tuoi peggiori punteggi INP.

INP e LCP: la connessione dei task lunghi

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

Case study: miglioramenti INP in produzione

redBus: miglioramento della conversione mobile dell'80-100%

redBus, una delle più grandi piattaforme mondiali di prenotazione autobus online, ha investito nell'ottimizzazione dei Core Web Vitals nei loro mercati globali. Il loro focus sulla riduzione del tempo di esecuzione JavaScript e l'ottimizzazione degli event handler ha contribuito a un miglioramento dell'80-100% nei tassi di conversione mobile nei loro mercati globali. I miglioramenti sono stati guidati da una combinazione di riduzione del tempo di blocco del main thread, ottimizzazione del caricamento degli script di terze parti e implementazione del code splitting per ridurre la quantità di JavaScript analizzato durante l'avvio della pagina.

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

Preply, una piattaforma di tutoraggio linguistico online, ha migliorato l'INP della Home page da circa 250ms a 185ms e l'INP della pagina di ricerca da circa 250ms a 175ms. Il team ha ottenuto questi risultati profilando la loro applicazione React, identificando ed eliminando i re-render non necessari e differendo i callback di eventi non critici. I punteggi Core Web Vitals migliorati hanno mostrato una correlazione con ranking di ricerca più elevati, traducendosi in un valore stimato di $200.000 all'anno in ricerca organica.

Cosa mostrano i dati reali sull'INP

Il divario INP mobile-desktop

I dati di CoreDash rivelano che l'INP mobile (131ms al p75) è 2,8 volte peggiore dell'INP desktop (48ms al p75). Questo è il divario dispositivo più grande di qualsiasi metrica Core Web Vital. I dispositivi mobili hanno processori più lenti, meno memoria e latenza di rete più elevata, tutti 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 raggiunge un punteggio INP "buono", mentre su mobile questa cifra scende all'88,0%. Gli utenti mobili sperimentano anche 5 volte più eventi INP "scarsi" (9,6% vs 1,9%).

Interazioni tastiera vs puntatore

I dati di CoreDash mostrano che le interazioni da tastiera (75ms p75) sono il 56% più lente delle interazioni da puntatore (49ms p75). Gli eventi da tastiera hanno anche significativamente più esperienze scarse: il 7,4% delle interazioni da tastiera risulta in un INP scarso, rispetto a solo l'1,4% per le interazioni da puntatore. Questo divario è probabilmente dovuto al fatto che gli eventi da tastiera, specialmente nei campi dei form, attivano elaborazioni più complesse come la validazione dell'input, i suggerimenti di autocompletamento e gli aggiornamenti di stato.

Interazioni durante il caricamento vs dopo il caricamento

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

Tassi globali di superamento INP

Secondo l'HTTP Archive 2025 Web Almanac, il 77% di tutte le pagine mobili raggiunge un punteggio INP "buono" (in aumento dal 55% nel 2022). Tuttavia, solo il 53% dei primi 1.000 siti web più visitati supera l'INP. I siti web ad alto traffico tendono ad avere JavaScript più complesso, più script di terze parti e strutture DOM più intricate, tutti fattori che contribuiscono a una reattività peggiore. Su desktop, il 97% delle pagine raggiunge buoni punteggi INP, evidenziando l'enorme divario di prestazioni mobile-desktop. Il Total Blocking Time mediano nei test di laboratorio è di 67ms su desktop ma di 1.209ms su mobile.

Domande frequenti

Guide correlate

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

• <strong>Trovare e risolvere i problemi INP</strong>: una metodologia diagnostica passo-passo che utilizza Search Console, dati RUM e Chrome DevTools per identificare esattamente quali interazioni stanno causando i tuoi peggiori punteggi INP.
• <strong>INP Input Delay</strong>: copre la prima fase dell'INP. Scopri come i task lunghi sul main thread bloccano l'elaborazione degli eventi e come minimizzare l'input delay con la pianificazione dei task, il code splitting e i web worker.
• <strong>INP Processing Time</strong>: copre la seconda fase dell'INP. Scopri come ottimizzare i callback degli event handler, dare priorità al codice critico, differire il lavoro non essenziale e usare le funzionalità di concorrenza di React per ridurre il tempo di elaborazione.
• <strong>INP Presentation Delay</strong>: copre la terza fase dell'INP. Scopri come la dimensione del DOM, il layout thrashing e il rendering lato client contribuiscono ad aggiornamenti visivi lenti e come ridurre il presentation delay.

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

• Migliorare l'INP: abbandona lo scrolling JavaScript
• Async vs Defer: strategie di caricamento JavaScript
• 14 metodi per differire JavaScript
• Widget di chat con Core Web Vitals perfetti
• Fix: evitare dimensioni DOM eccessive