INP: la metrica Google che penalizza i siti WordPress interattivi (e come risolverla)

L'Interaction to Next Paint (INP) è la metrica di Core Web Vitals che più penalizza i siti WordPress con interazioni complesse: form multi-passo, filtri AJAX, carrelli WooCommerce, menu mega. Misura il tempo che intercorre tra il clic dell'utente e il rendering visibile della risposta della pagina. Un INP alto significa un sito che non risponde: l'utente clicca e non succede nulla per mezzo secondo o più.

A differenza del LCP — che misura un singolo evento di caricamento — l'INP si calcola su tutte le interazioni della sessione di navigazione e prende come valore il percentile peggiore (P98). Un solo clic lento su una pagina visitata migliaia di volte al giorno può far fallire l'intera metrica.

Perché WordPress ha spesso INP alto

WordPress carica per default jQuery e una catena di script di plugin che eseguono codice al caricamento di ogni pagina. Ogni listener su 'DOMContentLoaded', ogni observer, ogni inizializzazione di widget aggiunge latenza al thread principale. Quando l'utente clicca, il browser deve prima completare queste code JavaScript prima di poter dipingere il frame successivo.

La diagnosi parte da Chrome DevTools: apri Performance, registra una sessione, interagisci con la pagina, poi analizza i Long Tasks nel timeline. I task superiori a 50ms bloccano il thread e degradano l'INP.

Misurare l'INP con il Web API PerformanceObserver

Puoi raccogliere i dati INP reali degli utenti direttamente da WordPress, registrando ogni interazione lenta:

// Registrare INP nel browser (snippet da inserire in <head>)
new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  const inp = Math.max(...entries.map(e => e.duration));
  const interactionType = entries[0]?.name ?? 'unknown';

  // Invia al server o a analytics solo se lento (> 200ms)
  if (inp > 200) {
    navigator.sendBeacon('/wp-json/v1/inp-report', JSON.stringify({
      inp: Math.round(inp),
      url: location.pathname,
      type: interactionType,
      ts: Date.now()
    }));
  }
}).observe({ type: 'interaction', buffered: true });

Le tre cause più frequenti di INP alto in WordPress

La prima causa è il JavaScript di blocco: plugin che caricano script grandi su ogni pagina, anche dove non servono. La seconda è la manipolazione DOM sincrona: funzioni jQuery che ricalcolano layout interi al clic invece di usare CSS. La terza sono i listener globali: eventi su 'document' o 'window' che intercettano ogni interazione e aggiungono overhead.

Per il primo problema, rinviare il caricamento degli script non critici è la soluzione più efficace:

// Rinvia il caricamento degli script non critici nel functions.php
add_filter( 'script_loader_tag', function( $tag, $handle ) {
    // Lista di script non critici da rinviare
    $defer = [ 'jquery-core', 'jquery-migrate', 'comment-reply' ];
    if ( in_array( $handle, $defer ) ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    return $tag;
}, 10, 2 );

Ridurre il lavoro del thread principale

Il secondo intervento consiste nel spostare il lavoro fuori dal thread principale usando Web Workers per le elaborazioni pesanti, o nel frammentare le operazioni lunghe con requestIdleCallback o scheduler.yield(). Per interazioni rapide come filtri o ordinamenti, usa CSS per la parte visiva invece di JavaScript quando possibile.

// Frammentare un'operazione pesante per non bloccare l'interazione
async function processHeavyData(items) {
  const results = [];
  for (const item of items) {
    results.push(transform(item));
    // Cede il controllo al browser ogni iterazione
    if (results.length % 10 === 0) {
      await scheduler.yield(); // API moderna, fallback: await new Promise(r => setTimeout(r));
    }
  }
  return results;
}

Il Lighthouse lab non è l'INP reale

Come sempre con i Core Web Vitals, il punteggio di laboratorio di Lighthouse non coincide con l'INP misurato sugli utenti reali. Lighthouse simula un singolo caricamento; l'INP reale si accumula su tutta la sessione. Per sapere dove sei davvero, usa i dati del CrUX report di Google Search Console, che mostra il 75° percentile reale per ogni pagina.

Un INP sotto 200ms è l'obiettivo. Sotto 100ms è eccellente. Sopra 500ms è considerato scarso e penalizza l'indicizzazione mobile. Un audit Core Web Vitals dedicato misura l'INP reale su ogni interazione critica del tuo sito e identifica esattamente quale script degrada la metrica.