INP WordPress: diagnosticare e correggere interazioni lente

Cos’è INP e perché è critico per WordPress

Dal marzo 2024, Interaction to Next Paint (INP) ha ufficialmente sostituito FID (First Input Delay) come metrica Core Web Vitals. INP misura la latenza di tutte le interazioni utente durante l’intero ciclo di vita della pagina, non solo la prima. Google considera buono un valore INP inferiore a 200ms, accettabile tra 200-500ms, e scarso oltre 500ms.

Per i siti WordPress gestiti da agenzie, INP è particolarmente critico perché:

• Plugin e temi spesso aggiungono JavaScript pesante che blocca il thread principale
• I page builder generano codice inefficiente che rallenta le interazioni
• Form, menu mobili e slider sono punti critici dove INP peggiora
• L’impatto SEO è diretto: siti con INP scarso perdono posizioni nelle SERP

Nei nostri test su oltre 3.400 siti WordPress gestiti tramite AgencyPilot, il 68% presentava valori INP superiori a 200ms prima dell’ottimizzazione, con picchi oltre 800ms su siti con WooCommerce e page builder attivi contemporaneamente.

Strumenti di diagnostica INP per WordPress

La diagnostica INP richiede un approccio multi-strumento perché i lab test non catturano sempre i problemi reali degli utenti.

Chrome DevTools e Performance Insights

Il punto di partenza per la diagnostica tecnica:

• Apri DevTools (F12) → scheda Performance
• Abilita Web Vitals nelle impostazioni (icona ingranaggio)
• Registra una sessione mentre interagisci con elementi critici (menu, form, accordion)
• Cerca marker rossi che indicano Long Tasks (oltre 50ms)
• Analizza la sezione Interactions per identificare i colli di bottiglia

Chrome DevTools mostra la breakdown dell’interazione in tre fasi: Input Delay, Processing Time e Presentation Delay. La fase di Processing è quasi sempre il problema principale su WordPress.

PageSpeed Insights e CrUX

PageSpeed Insights fornisce dati reali dal Chrome User Experience Report:

• Verifica i valori field data (75° percentile) per INP reale degli utenti
• Confronta origin vs page per capire se il problema è globale o specifico
• Usa i lab data di Lighthouse solo come indicatore, non come metrica definitiva

Nota importante: i lab test spesso mostrano valori INP artificialmente bassi perché non simulano comportamenti utente reali come scroll rapidi o click multipli.

Web Vitals Extension e DebugBear

Per monitoraggio continuo:

• Web Vitals Extension (Google): mostra INP in tempo reale durante la navigazione
• DebugBear: RUM (Real User Monitoring) specifico per WordPress, con breakdown per tipo di interazione
• Search Console: sezione Core Web Vitals per identificare pagine problematiche su larga scala

Su AgencyPilot integriamo DebugBear API per monitorare INP su tutti i siti client con alert automatici quando i valori superano 250ms per più di 5% degli utenti.

Cause comuni di INP elevato su WordPress

JavaScript non ottimizzato e plugin pesanti

La causa numero uno: troppo JavaScript che blocca il main thread durante le interazioni.

• jQuery Migrate: ancora caricato di default, aggiunge 30-50ms a ogni interazione che lo usa
• Page builder JS: Elementor, Divi e WPBakery caricano 200-400KB di JavaScript anche sul frontend
• Form plugin: Contact Form 7, Gravity Forms con validazione real-time bloccano il thread
• Analytics e tracking: GTM mal configurato, Facebook Pixel, Hotjar eseguono script pesanti su ogni click

Usa wp_enqueue_script() con strategia defer o async e verifica con Query Monitor quali script vengono caricati su ogni pagina.

DOM manipulation e reflow pesanti

Operazioni DOM costose durante le interazioni:

• Menu mobile che ricalcola altezze e posizioni a ogni apertura
• Slider e carousel che manipolano DOM per transizioni (Slider Revolution è un classico)
• Infinite scroll che inietta HTML pesante senza virtual scrolling
• Animazioni CSS complesse che triggano layout recalculation

Usa transform e opacity per animazioni invece di width, height o top/left. Abilita will-change solo quando necessario.

Long Tasks e third-party scripts

Task oltre 50ms bloccano completamente le interazioni:

• Google Maps embed senza lazy loading
• Social media embed (Twitter, Instagram) che eseguono codice pesante
• Chat widget (Tawk.to, Drift) con inizializzazione sincrona
• A/B testing tools (Google Optimize legacy) che bloccano il rendering

Implementa facade pattern: sostituisci embed pesanti con placeholder cliccabili che caricano il contenuto reale solo on-demand.

Fix pratici per migliorare INP su WordPress

Ottimizzazione JavaScript

Interventi immediati con impatto misurabile:

1. Rimuovi jQuery Migrate: aggiungi a functions.php:

   add_action('wp_default_scripts', function($scripts) {
       if (!is_admin() && isset($scripts->registered['jquery'])) {
           $script = $scripts->registered['jquery'];
           $script->deps = array_diff($script->deps, ['jquery-migrate']);
       }
   });

2. Delay JavaScript non essenziale: usa Flying Scripts o WP Rocket delay execution per posticipare analytics, chat widget e social dopo interazione utente
3. Code splitting: carica JavaScript specifico solo sulle pagine che lo richiedono (WooCommerce JS solo su shop/cart/checkout)
4. Debounce event handler: su scroll e resize, usa debounce di almeno 150ms per ridurre esecuzioni

Ottimizzazione DOM e CSS

Riduci il costo delle operazioni DOM:

1. Semplifica selettori CSS: evita selettori complessi tipo .menu > li > a:not(.active)
2. Riduci DOM depth: page builder generano div nidificati fino a 15+ livelli, semplifica HTML custom
3. Usa contenimento CSS: applica contain: layout style paint su componenti isolati come widget sidebar
4. Virtualizza liste lunghe: per elenchi oltre 50 elementi, implementa virtual scrolling o paginazione

Plugin e hosting

Scelte infrastrutturali che impattano INP:

• Object caching: Redis o Memcached riducono query PHP durante interazioni dinamiche
• PHP 8.2+: performance boost del 20-30% su elaborazione rispetto a PHP 7.4
• CDN con edge computing: Cloudflare Workers o Fastly per cache intelligente di risposte AJAX
• Server response time: TTFB sotto 200ms è critico, considera hosting managed WordPress di qualità

Su AgencyPilot abbiamo partnership con hosting ottimizzati per WordPress che garantiscono TTFB sotto 150ms, riducendo INP medio del 35% rispetto a hosting shared standard.

Monitoraggio e testing continuo

INP può peggiorare con aggiornamenti plugin o tema:

• Implementa RUM per tracciare INP reale post-deployment
• Configura alert automatici quando INP supera threshold definiti
• Testa interazioni critiche (add to cart, form submit, menu mobile) su device reali Android mid-range
• Usa Lighthouse CI in pipeline deployment per bloccare release che degradano INP oltre 10%

Case study: riduzione INP da 680ms a 180ms

Cliente ecommerce con WooCommerce + Elementor + 18 plugin attivi presentava INP medio 680ms (scarso).

Interventi effettuati:

1. Rimosso jQuery Migrate e ottimizzato caricamento WooCommerce JS (-120ms)
2. Sostituito slider homepage Slider Revolution con CSS-only carousel (-200ms)
3. Implementato facade per Google Maps nella pagina contatti (-90ms)
4. Delayed Facebook Pixel e Hotjar con Flying Scripts (-80ms)
5. Abilitato object caching Redis e aggiornato a PHP 8.2 (-90ms)

Risultato: INP medio sceso a 180ms (buono), con incremento conversioni del 12% nei 30 giorni successivi. Tempo investito: 6 ore developer.

FAQ

Qual è la differenza tra INP e FID?

FID (First Input Delay) misurava solo la latenza della prima interazione utente, mentre INP valuta tutte le interazioni durante l’intera sessione e riporta il valore del 98° percentile (peggiore tra le peggiori). INP è molto più rappresentativo dell’esperienza reale perché cattura problemi che emergono dopo il caricamento iniziale, come interazioni con menu, form o filtri prodotto.

Posso avere INP buono nei lab test ma scarso nei field data?

Assolutamente sì. Lab test come Lighthouse simulano un singolo caricamento su hardware potente (desktop di fascia alta) senza replicare comportamenti utente reali: scroll rapidi, click multipli, interazioni su device Android mid/low-range. Field data da CrUX mostra performance reale su device e connessioni variabili. Ottimizza sempre basandoti su field data quando disponibili.

Quale valore INP dovrei considerare come target per siti client?

Per siti WordPress professionali punta a INP sotto 200ms (buono) come target primario. Per ecommerce o applicazioni web-based, target più aggressivo sotto 150ms garantisce esperienza ottimale anche su device medio-bassi. Evita di accontentarti della zona 200-500ms (accettabile): la differenza in conversioni e SEO è misurabile.

I page builder sono incompatibili con buoni valori INP?

Non necessariamente, ma richiedono ottimizzazione aggressiva. Elementor e Bricks possono raggiungere INP sotto 200ms se: disabiliti funzionalità non usate, carichi CSS/JS in modo condizionale, eviti widget pesanti (slider complessi, parallax), usi object caching e hosting performante. Gutenberg con blocchi custom rimane l’approccio più performante per progetti dove INP è prioritario.

Come gestire INP su siti WooCommerce con molte interazioni AJAX?

WooCommerce è particolarmente critico per INP. Strategie efficaci: abilita object caching per query prodotti, usa mini cart AJAX ottimizzato (evita refresh DOM completo), implementa debounce su filtri/search, disabilita script WooCommerce su pagine non-shop con wp_dequeue_script, considera headless con WooCommerce REST API per controllo totale su frontend. Su progetti complessi, mantieni INP sotto 250ms è già ottimo risultato.