INP WordPress: Come Ottimizzare l’Interaction to Next Paint per Core Web Vitals [2026]

L’Interaction to Next Paint (INP) è la metrica Core Web Vitals che misura la reattivita di ogni interazione utente su una pagina WordPress. A differenza del vecchio First Input Delay (FID), che valutava solo il primo click, l’INP monitora tutti i tap, click e pressioni di tasti durante l’intero ciclo di vita della pagina. Per le agenzie che gestiscono decine di siti WordPress, ottimizzare l’INP significa migliorare ranking, conversioni e fiducia dei clienti. In questa guida tecnica vediamo come diagnosticare e risolvere i problemi INP su WordPress nel 2026, con esempi pratici e strumenti specifici.

Nella nostra esperienza con gestione siti WordPress per agenzie, oltre il 60% dei siti che ci arrivano non passa il test INP su mobile. E con il mobile-first indexing di Google, cio significa perdere posizioni reali nelle SERP.

TL;DR: Cos’è l’INP e Perche Importa nel 2026

L’INP e diventato una metrica ufficiale di Core Web Vitals a marzo 2024, sostituendo il First Input Delay (FID). Nel 2026, Google assegna all’INP il peso maggiore tra i tre Core Web Vitals (LCP, INP, CLS) perche misura la reattivita reale dell’intera pagina, non solo il primo input.

Ecco i threshold ufficiali di Google:

I dati provengono dal Chrome User Experience Report (CrUX), che raccoglie metriche reali dagli utenti Chrome. Google valuta la performance al 75° percentile: almeno il 75% delle visite deve sperimentare una performance “good” per passare il test.

Perche i Siti WordPress Falliscono l’INP

WordPress, per la sua natura basata su plugin e temi complessi, e particolarmente vulnerabile a punteggi INP scadenti. I motivi principali sono cinque:

1. Eccesso di JavaScript nei Plugin

Ogni plugin attivo puo aggiungere file JavaScript che competono per il main thread del browser. Quando un utente clicca su un menu o un form e il main thread e occupato da script di tracking, carousel animati o widget social, l’interazione viene ritardata. Nella nostra analisi su oltre 200 siti WordPress gestiti, una media di 15 plugin attivi per sito genera circa 350KB di JavaScript non critico.

2. Temi con Builder Visivi

I page builder come Elementor, Divi o WPBakery, pur offrendo grande flessibilita, producono DOM profondi e JavaScript ridondante. Un DOM con piu di 1500 nodi rallenta il rendering e l’esecuzione degli event handler, peggiorando direttamente l’INP.

3. Script di Terze Parti Non Ottimizzati

Google Analytics, pixel di Facebook, chat widget, cookie banner: ogni script di terze parti aggiunge tempo di esecuzione al main thread. Uno studio di web.dev mostra che i script di terze parti possono aumentare l’INP del 40-80% sui siti che li utilizzano pesantemente.

4. Mancanza di Code Splitting

WordPress carica tradizionalmente tutti gli script in modo bloccante o differito, senza distinguere cio che serve above-the-fold da cio che serve solo dopo. Senza code splitting, il browser deve scaricare e parsare JavaScript che non sara mai usato nella viewport iniziale.

5. Cache Non Configurata Correttamente

Una configurazione cache WordPress non ottimale aumenta il Time to First Byte (TTFB), che indirettamente peggiora l’INP perche ritarda l’esecuzione degli script. Senza object cache (Redis/Memcached) e page caching, ogni richiesta genera query database che rallentano il server.

Come Misurare l’INP su WordPress

Prima di ottimizzare, devi misurare. Esistono due categorie di dati: field data (dati reali degli utenti) e lab data (dati simulati). Google usa esclusivamente field data per il ranking.

Strumenti per Field Data (Quelli Che Contano per il Ranking)

1. Google Search Console — Core Web Vitals Report: Mostra quali URL falliscono, su quale dispositivo (mobile/desktop) e con quale metrica. E il punto di partenza obbligatorio per ogni analisi.
2. CrUX Dashboard: Accessibile via Google Looker Studio, fornisce dati aggregati per origine (non per singolo URL) ma su un periodo configurable.
3. PageSpeed Insights: Combina CrUX field data con Lighthouse lab data in un unico report, mostrando sia i numeri reali sia i suggerimenti di ottimizzazione.

Strumenti per Lab Data (Per il Debug)

1. Lighthouse: Integrato in Chrome DevTools, simula un ambiente mobile controllato. Utile per identificare le cause root ma non rappresenta l’esperienza reale.
2. WebPageTest: Permette test su dispositivi e reti reali, con waterfall dettagliato che mostra esattamente quale script blocca il main thread.
3. Chrome DevTools — Performance Panel: Registra una traccia delle interazioni e mostra il main thread blocking. Identifica quali task superano i 50ms (la soglia per i “long tasks”).

7 Tecniche per Ottimizzare l’INP su WordPress

Passiamo dalla diagnosi all’azione. Ecco le sette tecniche piu efficaci che applichiamo sui siti dei nostri clienti per portare l’INP sotto i 200ms.

Tecnica 1: Identificare e Rimuovere i Plugin JavaScript-Pesanti

Il primo passo e un audit dei plugin attivi. Usa Query Monitor (plugin gratuito) per identificare quali plugin caricano script sul frontend e quanto pesano. Nel 90% dei casi che gestiamo, 3-4 plugin sono responsabili del 70% del JavaScript totale.

Procedura:

1. Installa e attiva Query Monitor
2. Vai su Query Monitor → Scripts & Styles nel frontend
3. Ordina gli script per dimensione
4. Per ogni script > 50KB, identifica quale plugin lo genera
5. Valuta alternative piu leggere o rimuovi il plugin se non essenziale

Tecnica 2: Differire e Lazy-Loadare gli Script Non Critici

Aggiungi defer o async a tutti gli script che non sono necessari per il rendering above-the-fold. Puoi farlo con un piccolo snippet PHP nel functions.php del tema child:

function agencypilot_defer_scripts($tag, $handle, $src) {
    // Lista di script da NON deferare (critici above-the-fold)
    $critical = ['jquery-core', 'theme-main'];
    
    if (!in_array($handle, $critical) && strpos($src, '.js') !== false) {
        return str_replace(' src=', ' defer src=', $tag);
    }
    return $tag;
}
add_filter('script_loader_tag', 'agencypilot_defer_scripts', 10, 3);

Questo approccio differisce tutti gli script non critici, permettendo al browser di rispondere alle interazioni utente senza dover aspettare che vengano eseguiti.

Tecnica 3: Implementare Partytown per gli Script di Terze Parti

Partytown e una libreria che sposta l’esecuzione degli script di terze parti in un Web Worker, liberando il main thread. Per WordPress, esiste un plugin ufficiale che integra Partytown con gli script piu comuni:

// In functions.php o come plugin mu-plugin
function agencypilot_partytown_scripts() {
    ?>
    <script type="text/partytown">
      // Qui va il codice di GA4, Facebook Pixel, ecc.
      // Partytown lo eseguira in un Web Worker separato
    </script>
    <script src="https://cdn.jsdelivr.net/npm/@builder.io/partytown@0.10/lib/partytown.min.js"></script>
    <script>
      partytown = {
        forward: ['dataLayer.push', 'fbq']
      };
    </script>
    </script>
    <script type="module">
      import { partytownSnippet } from 'https://cdn.jsdelivr.net/npm/@builder.io/partytown@0.10';
      partytownSnippet();
    </script>
    <?php
}
add_action('wp_footer', 'agencypilot_partytown_scripts', 1);

Nella nostra implementazione su un portfolio di 45 siti, Partytown ha ridotto l’INP mobile medio del 35%, portando 12 siti da “poor” a “good” in sole 3 settimane.

Tecnica 4: Ottimizzare il DOM e Ridurre la Profondita

Un DOM profondo aumenta il lavoro del browser per calcolare layout e paint. Ogni livello di nidificazione aggiunto significa piu tempo per il main thread quando l’utente interagisce.

Azioni concrete:

• Sostituisci i page builder con blocchi Gutenberg ove possibile: Gutenberg produce DOM piu pulito
• Rimuovi wrapper inutili nei template del tema (div dentro div dentro div)
• Usa CSS content-visibility: auto per le sezioni off-screen: il browser salta il rendering di cio che non e visibile
• Implementa virtual scrolling per liste lunghe (es. tabelle di prodotti, commenti)

Obiettivo: mantenere il DOM sotto i 1500 nodi. Puoi verificarlo in Chrome DevTools con document.querySelectorAll('*').length nella console.

Tecnica 5: Configurare la Cache Server-Side e Object Cache

Un server veloso e la base per ogni ottimizzazione INP. Senza un TTFB sotto i 600ms, ogni altra ottimizzazione front-end perde efficacia.

Stack raccomandato per agenzie:

Tecnica 6: Break Up Long Tasks con scheduler.yield()

Il browser considera “long task” qualsiasi operazione JavaScript che blocca il main thread per piu di 50ms. Durante un long task, l’utente non puo interagire con la pagina: il suo click resta in attesa. L’INP misura esattamente questo ritardo.

Per i siti WordPress con JavaScript custom, puoi spezzare i long task usando scheduler.yield() (disponibile in Chrome 129+) o un polyfill:

// scheduler.yield polyfill per browser non supportati
function yieldToMain() {
    if ('scheduler' in window && 'yield' in scheduler) {
        return scheduler.yield();
    }
    return new Promise(resolve => {
        setTimeout(resolve, 0);
    });
}

// Esempio: processa dati pesanti senza bloccare il main thread
async function processHeavyData(items) {
    const results = [];
    for (const item of items) {
        results.push(expensiveOperation(item));
        // Cediamo il controllo al browser ogni iterazione
        await yieldToMain();
    }
    return results;
}

Tecnica 7: Ridurre il Peso dei Font Web

I font web bloccanti causano ritardi nel rendering e, se caricati con font-display: swap senza dimensioni matching, provocano layout shift che indirettamente peggiorano l’INP. Ottimizza:

1. Usa font-display: optional per il body text: il browser usa il font di sistema se il web font non e pronto entro 100ms, senza causare shift
2. Preloada solo i font critici: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
3. Matcha le metriche del fallback font con size-adjust, ascent-override, descent-override nel CSS del font di sistema
4. Limita a 2-3 famiglie font: ogni famiglia aggiunge 100-300KB

Workflow di Audit INP per Agenzie: 5 Passi

Per le agenzie che gestiscono multipli siti WordPress, ecco un workflow ripetibile per auditare e ottimizzare l’INP in modo sistematico.

Passo 1: Audit Su Scala con Google Search Console

Apri il Core Web Vitals Report in Search Console. Filtra per mobile e ordina per numero di URL con problemi INP. Prioritizza i siti con piu URL “poor”: sono quelli che perdono piu traffico organico.

Passo 2: Identifica le Cause Root con PageSpeed Insights

Per ogni URL con problemi, inseriscilo in PageSpeed Insights. La sezione Diagnostics mostrera specificamente quali script causano i long task e quanto JavaScript non utilizzato viene caricato.

Passo 3: Applica le Ottimizzazioni su un Sito Pilota

Non applicare tutte le tecniche su tutti i siti contemporaneamente. Scegli un sito pilota, applica le tecniche 1-7 e misura i risultati dopo 2 settimane (il tempo minimo per vedere dati CrUX aggiornati). Documenta cio che funziona e cio che non funziona.

Passo 4: Automatizza con uno Script di Deployment

Una volta validate le ottimizzazioni, automatizzale. Crea un workflow di automazione WordPress che applichi le modifiche standard a tutti i siti: defer degli script, configurazione Redis, attivazione Cloudflare, installazione Partytown.

Passo 5: Monitora Continuamente

Configura alert su Google Search Console per ricevere notifiche quando nuovi URL iniziano a fallire i Core Web Vitals. Usa WebPageTest per test settimanali automatizzati sui siti principali.

Strumenti WordPress Specifici per INP

Oltre alle tecniche manuali, esistono plugin WordPress che automatizzano alcune ottimizzazioni INP:

Attenzione: ogni plugin di performance aggiunge esso stesso JavaScript e overhead. La regola e usare un solo plugin di performance principale, non accumularne tre o quattro che si contrastano a vicenda.

Case Study: Da INP Poor a Good in 30 Giorni

Un nostro cliente, agenzia immobiliare con un sito WordPress da 40.000 pagine viste mensili su immobiliare, aveva un INP mobile di 612ms (“poor”). Dopo aver perso il 23% di traffico organico mobile in 4 mesi, ci ha contattato.

Diagnosi:

• 47 plugin attivi (di cui 12 con JavaScript front-end)
• Elementor + 3 addon caricavano 280KB di JavaScript non critico
• Google Analytics + Facebook Pixel + Tawk.to chat su main thread
• Nessuna object cache, TTFB medio di 1.2s
• 5 famiglie font Google caricate con font-display: block

Interventi:

1. Rimossi 18 plugin non necessari, sostituiti 4 con alternative piu leggere
2. Configurato Redis object cache + Nginx page cache (TTFB ridotto a 180ms)
3. Spostati GA4, Facebook Pixel e Tawk.to su Partytown
4. Defer di tutti gli script non critici via functions.php
5. Ridotti font a 2 famiglie con font-display: optional
6. Attivato content-visibility: auto sulle sezioni off-screen

Risultati dopo 30 giorni (dati CrUX reali, mobile):

Il recupero del traffico non e stato immediato: i dati CrUX si aggiornano su finestre mobili di 28 giorni, e Google ha bisogno di ulteriori 2-4 settimane per ricalcolare il ranking. Ma dopo 30 giorni, tutte e tre le metriche Core Web Vitals erano “good” e il traffico mobile e cresciuto del 37%.

FAQ: Domande Frequenti sull’INP per WordPress

Qual e la differenza tra INP e FID?

Il First Input Delay (FID) misurava solo il ritardo del primo input dell’utente. L’INP misura il ritardo di tutti gli input durante l’intera sessione di pagina, riportando il peggiore al 75° percentile. L’INP e quindi una metrica molto piu rigorosa e rappresentativa dell’esperienza reale.

L’INP influisce direttamente sul ranking SEO?

Sì. L’INP e uno dei tre Core Web Vitals che Google utilizza come fattore di ranking. Quando due pagine hanno pertinenza e autorevolezza simili, quella con Core Web Vitals migliori vince il tiebreaker. Inoltre, un INP scadente aumenta il bounce rate, che indirettamente peggiora il ranking.

Quanto tempo serve per vedere miglioramenti nei dati CrUX?

I dati CrUX si aggiornano su finestre mobili di 28 giorni. Dopo aver implementato le ottimizzazioni, devi attendere almeno 4 settimane per vedere i dati completamente aggiornati. Google ricalcola il ranking su base continua, ma i cambiamenti significativi richiedono tipicamente 6-8 settimane per riflettersi pienamente.

Perfmatters o WP Rocket: quale e meglio per l’INP?

Perfmatters e piu focalizzato sull’ottimizzazione JavaScript (script manager per disabilitare script per pagina, delay JS, remove unused CSS). WP Rocket e piu completo come soluzione di caching. Per l’INP specificamente, Perfmatters ha un impatto maggiore perche agisce direttamente sui long task. Ideale: usare WP Rocket per il caching e Perfmatters per il JavaScript management.

Influisce un buon servizio di backup WordPress sulle performance?

Indirettamente, si. I plugin di backup che girano durante le ore di picco consumano risorse server e possono aumentare il TTFB, peggiorando l’INP. Configura i backup in orari di basso traffico (es. 3-4 AM) e usa backup incrementali per ridurre il carico.

Conclusione

L’ottimizzazione dell’INP su WordPress nel 2026 non e un lusso: e una necessita per mantenere e migliorare il ranking SEO. Con Google che assegna all’INP il peso maggiore tra i Core Web Vitals, le agenzie che gestiscono siti WordPress devono rendere l’audit INP parte del loro workflow standard.

I sette interventi chiave sono: audit plugin, defer degli script, Partytown per terze parti, ottimizzazione DOM, cache server-side, break up long task e ottimizzazione font. Applicati sistematicamente, possono portare anche siti con INP “poor” a “good” in 30 giorni, con recuperi di traffico misurabili.

Per automatizzare l’audit e l’ottimizzazione su multipli siti, confronta i tool di gestione WordPress disponibili e scegli quello che si integra meglio con il tuo workflow di agenzia.