JavaScript di terze parti e INP: il nemico silenzioso delle interazioni WordPress

L'INP — Interaction to Next Paint — è la metrica che Google usa per misurare la responsività: quanto tempo passa tra il momento in cui l'utente clicca (o tocca o digita) e il momento in cui lo schermo mostra la risposta. A differenza del LCP, che riguarda il caricamento iniziale, l'INP riguarda ogni interazione durante tutta la visita. Un sito può caricarsi velocemente e avere un INP pessimo se, dopo il caricamento, le interazioni sono lente.

La causa più frequente di un INP alto non è il codice del tema o dei plugin WordPress: sono gli script di terze parti. Analytics, pixel di tracciamento, chat widget, banner cookie, widget social — ognuno carica JavaScript che gira sul thread principale del browser. Quando l'utente clicca, il browser deve finire di eseguire quegli script prima di poter disegnare la risposta. Più script, più attesa, peggiore INP.

Identificare gli script che bloccano le interazioni

Il primo passo è misurare. Chrome DevTools, nella scheda Performance, registra una traccia durante un'interazione e mostra esattamente quale script occupa il thread principale nel momento del click. La colonna 'Self Time' rivela i colpevoli: spesso uno script di analytics o un widget di chat da solo occupa centinaia di millisecondi, bloccando tutto il resto.

Un modo rapido per quantificare il peso delle terze parti è confrontare il tempo di esecuzione totale del JavaScript con e senza di esse. Puoi usare la funzione di blocco delle richieste di Chrome DevTools per disabilitare temporaneamente i domini di terze parti e rifare il test:

# Identificare i domini di terze parti che caricano script
# Estrai gli URL degli script dalla pagina con cURL + grep

curl -s https://www.tuosito.com/ \
  | grep -oE 'src="https?://[^"'\''"]+\.js[^"'\''"]*"' \
  | sort -u

# Domini comuni di terze parti da verificare:
#   googletagmanager.com  (GTM, gtag)
#   google-analytics.com  (Universal Analytics)
#   connect.facebook.net  (Pixel Meta)
#   analytics.tiktok.com  (Pixel TikTok)
#   bat.bing.com         (UET Bing)
#   js.hs-scripts.com     (chat widget)
#   cdn.cookieconsent.*  (banner cookie)

# In Chrome DevTools: Network tab → filtra per 'Third Party'
# per vedere il peso totale e il tempo di esecuzione di ciascuno.

Ridurre prima di differire: il principio fondamentale

La tentazione è differire tutti gli script con `defer` o `async` e considerare risolto il problema. Non lo è. `defer` sposta quando lo script si esegue (dopo il parsing HTML), ma non riduce quanto tempo occupa quando si esegue. Se uno script di analytics impiega 300ms di thread principale, li impiega comunque — solo più tardi. L'INP misura le interazioni durante tutta la visita, quindi uno script differito che gira al momento del click blocca comunque la risposta.

Il principio è: ridurre prima, differire dopo. Ridurre significa caricare meno script in assoluto. Hai davvero bisogno di tre pixel di tracciamento? Un banner cookie che pesa 80KB? Un chat widget che carica 200KB di JavaScript per mostrare una bolla? Ogni script di terze parti è una decisione di business che si paga in performance. La prima ottimizzazione è la più efficace: togliere ciò che non serve.

Differire e isolare gli script necessari

Per gli script che servono davvero, la strategia è differirli e, dove possibile, isolarli. Il `defer` caricato in modo classico va bene per gli script non essenziali. Per i widget interattivi (chat, form), la tecnica migliore è il caricamento ritardato sull'interazione: lo script non si carica finché l'utente non interagisce — scorre, clicca, muove il mouse — e a quel punto il costo di caricamento è già stato pagato dal gesto dell'utente.

// Caricamento ritardato di uno script di terze parti sull'interazione
// Lo script NON si carica al page load, ma solo quando l'utente
// interagisce (scroll, click, touch, mousemove).

(function () {
  var loaded = false;
  function loadThirdParty() {
    if (loaded) return;
    loaded = true;
    var s = document.createElement('script');
    s.src = 'https://connect.example.net/widget.js';
    s.async = true;
    document.body.appendChild(s);
    // Rimuovi i listener dopo il primo caricamento
    ['scroll','click','touchstart','mousemove'].forEach(function (ev) {
      window.removeEventListener(ev, loadThirdParty, { passive: true });
    });
  }
  ['scroll','click','touchstart','mousemove'].forEach(function (ev) {
    window.addEventListener(ev, loadThirdParty, { passive: true });
  });
  // Fallback: carica comunque dopo 5 secondi
  setTimeout(loadThirdParty, 5000);
})();

Il caso del banner cookie: pesante e inevitabile

Il banner cookie è un caso particolare: è obbligatorio (per conformità GDPR), ma è anche uno degli script più pesanti perché si carica in modo bloccante per poter mostrare il banner il prima possibile. La soluzione è un banner leggero, scritto in codice nativo senza dipendenze da librerie, che pesa pochi KB invece delle decine di KB dei banner commerciali. Un banner di 5KB nativo ha un impatto sull'INP infinitamente minore di un banner di 80KB che carica un framework.

Il server-side tagging è un'altra leva per gli script di analytics: invece di far eseguire il tag di tracciamento nel browser dell'utente (sul thread principale), lo si esegue sul server, tramite un container server-side (es. Cloudflare Workers, GTM Server-Side). Il browser non scarica né esegue lo script di terze parti; il server raccoglie l'evento e lo inoltra. L'INP migliora perché il thread principale del browser non è più occupato dal tracciamento. Non è sempre fattibile, ma per siti ad alto traffico con molti pixel è la soluzione più pulita.

Il JavaScript di terze parti è il problema più sottovalutato dell'ottimizzazione WordPress perché non è visibile nel codice del sito — arriva da fuori, via plugin o via snippet incollati nell'header. Un audit Core Web Vitals misura l'INP reale, identifica gli script che lo degradano e propone le riduzioni e i differimenti concreti. L'obiettivo non è eliminare tutte le terze parti — spesso servono al business — ma caricarle in modo che non blocchino le interazioni dell'utente.