Ridurre il Total Blocking Time (TBT) con il caricamento JavaScript differito (Defer/Async) sul tuo sito

Il caricamento differito di JavaScript è una tecnica che permette di diminuire il Total Blocking Time (TBT) ottimizzando l’ordine di esecuzione degli script che bloccano il rendering della pagina. In pratica, aggiungendo defer o async ai file JavaScript non essenziali, si evita che il thread principale del browser rimanga bloccato inutilmente: così l’utente visualizza la pagina più rapidamente, può interagire prima, e i valori Core Web Vitals migliorano. Per implementare il caricamento differito JavaScript sul tuo sito, occorre prima identificare quali file sono critici, scegliere defer per script con dipendenze e async per script indipendenti di terze parti, quindi misurare il valore TBT dopo le modifiche con PageSpeed Insights, Lighthouse e Chrome DevTools.

Nei siti web moderni, i problemi di performance sono causati più spesso dall’uso eccessivo e poco controllato di JavaScript che dalle immagini. Un sito e-commerce che carica filtri prodotto, live chat, pixel pubblicitari, codici di analytics, plugin commenti, strumenti di A/B testing e script del tema contemporaneamente può saturare il thread principale del browser per diversi secondi. Questo è particolarmente evidente su dispositivi mobili: anche se l’utente vede il titolo della pagina, quando prova a toccare il menu non riceve risposta, e il report Lighthouse mostra un TBT molto elevato.

In questa guida analizzeremo cosa fanno gli attributi defer e async, quando usarli, come implementarli su WordPress e progetti custom, cosa considerare durante le misurazioni, e quali miglioramenti reali si possono ottenere sul TBT. Le raccomandazioni per i siti ospitati su Hostragons seguono gli standard web generali; vedremo anche come hosting, CDN, SSL e caching possano sostenere l’ottimizzazione JavaScript. Pacchetti web hosting Hostragons

Cos’è il TBT e perché è così legato a JavaScript?

TBT sta per Total Blocking Time e misura il tempo in cui il thread principale del browser è bloccato e quindi la pagina non è pronta per interazioni utente. Nei test Lighthouse, il TBT aumenta quando tra il First Contentful Paint e il Time to Interactive ci sono tanti task JavaScript che durano più di 50 millisecondi. Ad esempio, se uno script richiede 180 ms, i 130 ms dopo i primi 50 contribuiscono direttamente al TBT.

Questo parametro è fondamentale per l’esperienza utente. Quando un visitatore apre la pagina e prova a interagire con il menu, aggiungere un prodotto al carrello o cercare, se il browser sta ancora eseguendo JavaScript, il feedback sarà lento. L’utente percepisce la pagina come “bloccata”, “non responsiva” o “difettosa”. Nel 2026, anche se Google non ridurrà la valutazione della pagina ad un singolo punteggio, offrire una interazione rapida e stabile è essenziale per la soddisfazione degli utenti e le conversioni.

Segnali tipici di un TBT elevato

• Nel report PageSpeed Insights mobile, il TBT supera i 300 ms.
• Avvisi Lighthouse come "Reduce JavaScript execution time" o "Minimize main-thread work".
• Menu, slider, filtri o campi modulo rispondono lentamente anche se la pagina appare.
• Script di terze parti come pubblicità, chat o analytics risultano costosi nei report.
• Su smartphone Android entry-level si percepiscono ritardi nel tapping e scrolling.

La soglia consigliata è mantenere il TBT sotto i 200 ms nei siti content-driven. In siti complessi (e-commerce, SaaS) potrebbero servire anche code splitting, rimozione di bundle inutili, caching, ottimizzazione del server e CSS critico. Tuttavia, il caricamento differito JavaScript resta uno dei primi e più efficaci interventi da applicare.

Cosa sono Defer e Async?

Quando si inserisce uno script JavaScript in HTML senza attributi, il browser interrompe il parsing dell’HTML, scarica e esegue lo script, poi continua la costruzione della pagina. Questo comportamento è necessario solo per script essenziali; applicato a tutti i file genera attese inutili. Gli attributi defer e async modificano questa logica, regolando come e quando lo script viene scaricato ed eseguito.

Come funziona defer?

Uno script con defer viene scaricato in background mentre l’HTML viene analizzato; ma la sua esecuzione avviene solo dopo che il documento è stato completamente analizzato. Se ci sono più script defer, vengono eseguiti nell’ordine in cui compaiono nell’HTML. È ideale per script che dipendono l’uno dall’altro. Ad esempio, prima una libreria, poi uno script tema che la utilizza.

Esempio: <script defer src="/js/app.js"></script>. Questo file viene scaricato senza bloccare il rendering iniziale della pagina e viene eseguito solo quando il DOM è pronto. Defer è ben supportato dai browser moderni ed è una soluzione affidabile per script classici.

Come funziona async?

Uno script con async viene anch'esso scaricato durante il parsing HTML, ma viene eseguito immediatamente appena il download è terminato, anche se l’HTML non è ancora completamente analizzato. Non viene garantito l’ordine di esecuzione tra script async: il primo che arriva, viene eseguito. Per questo motivo, async è ideale per script indipendenti come analytics, pubblicità, pixel di tracking, widget esterni o social.

Esempio: <script async src="/js/analytics.js"></script>. Questo script non deve dipendere da altri script locali o librerie come jQuery, altrimenti può generare errori. Async è rapido, ma richiede attenzione nella classificazione dei file.

Tabella di confronto tra Defer e Async

Regola pratica: se il tuo file deve essere eseguito in ordine, usa defer. Se è totalmente indipendente, valuta async. In caso di dubbio, prova prima defer in staging, verifica errori in console e test di interazione critica. guida all'ambiente di staging e al backup

Piano operativo step-by-step per il caricamento differito JavaScript

Applicare defer o async a tutti gli script indiscriminatamente può sembrare una soluzione rapida, ma rischia di rompere funzioni essenziali come pagamenti, ricerca, menu, validazione form o carrello. La strategia migliore è seguire un ciclo di misurazione, classificazione, test incrementale e monitoraggio.

1. Misura la performance attuale

Prima di intervenire, definisci un benchmark. Registra i punteggi mobile e desktop con PageSpeed Insights. Annota TBT, First Contentful Paint, Largest Contentful Paint e Speed Index su Lighthouse. Su Chrome DevTools, nella scheda Performance, analizza le lunghe barre gialle: spesso rappresentano parsing, compilazione ed esecuzione JavaScript.

Puoi creare una tabella di partenza: TBT mobile 780 ms, JavaScript execution time 2,8 secondi, main-thread work 4,5 secondi. Se dopo l’ottimizzazione il TBT scende a 280 ms, hai migliorato del 64%. Questi dati aiutano a capire quali interventi funzionano.

2. Mappa gli script caricati

Analizza il codice sorgente o la scheda Network del browser e elenca tutti i file JavaScript. Per ciascuno, annota origine, dimensione, momento di utilizzo e dipendenze. Suddividili in:

• Script critici: necessari subito per la visualizzazione o navigazione.
• Script locali dipendenti: tema, slider, galleria, moduli app.
• Script terzi indipendenti: analytics, pubblicità, pixel, chat, social.
• Script inutili/obsoleti: residui di plugin non più usati.
• Script caricati condizionalmente: necessari solo su alcune pagine (es. validazione form su pagina contatti).

La migliore ottimizzazione spesso consiste nel rimuovere script inutili piuttosto che aggiungere defer. Un file compresso da 90 KB può causare un costo di parsing ed esecuzione di oltre 300 ms su mobile. Prima elimina i superflui, poi applica il caricamento differito agli altri.

3. Identifica i file da differire (defer)

Tipicamente, i candidati ideali sono script tema, logiche menu, slider, gallerie prodotto e bundle app. Attenzione: lo script non deve dipendere da metodi datati come document.write e deve poter lavorare dopo che il DOM è pronto.

Su WordPress, script come jquery-migrate, file principali del tema e script plugin possono avere dipendenze complesse. Rendere async il core jQuery è rischioso, poiché molti plugin attendono la sua esecuzione. Meglio applicare defer in modo controllato ai file dipendenti o usare opzioni di caricamento ottimizzate a livello di plugin. Guida all'ottimizzazione della velocità di WordPress

4. Scegli i file da rendere async

Sono candidati ideali Google Analytics, tag pubblicitari, Facebook Pixel, LinkedIn Insight Tag, alcune chat esterne e codici social. Non tutti i terzi sono uguali: alcune chat vogliono istanziare subito la sessione, certi sistemi pubblicitari richiedono un ordine specifico. Consulta la documentazione.

Rendere async un codice analytics generalmente non danneggia l’esperienza utente, ma verifica sempre il triggering nei report real-time. Se usi un Tag Manager, evita di raggruppare tutto in un unico container: imposta trigger condizionali. Ad esempio, il codice di monitoraggio dei commenti non va caricato sulle pagine senza form commenti.

5. Usa caricamento condizionale e su evento

Defer e async sono ottimi, ma il massimo impatto sul TBT si ottiene caricando script in base al comportamento utente. Ad esempio, la chat può essere caricata dopo 5 secondi di permanenza o solo al click sul bottone di aiuto. L’embed della mappa può essere scaricato solo quando l’utente scrolla sulla sezione contatti. Lo script del player video può essere caricato al click sul bottone play.

Questo approccio è particolarmente efficace su siti istituzionali e content-driven, dove non tutti gli utenti hanno bisogno di tutti i widget. Eliminare 200 KB di JavaScript dal caricamento iniziale può ridurre il TBT di centinaia di millisecondi su dispositivi mobili lenti.

6. Testa e pubblica gradualmente

Non applicare le modifiche direttamente online: usa ambienti di staging. Testa homepage, categorie, pagine prodotto/servizio, contatti, login, checkout. Controlla gli errori in console: errori come “Cannot read property”, “is not defined” o “undefined function” indicano problemi di ordine o dipendenza.

Procedi a gruppi: prima ottimizza script terzi indipendenti, poi quelli del tema. Dopo ogni modifica, rilancia Lighthouse simulando la stessa rete e dispositivo. Non basarti su una sola misurazione: prendi la media di almeno tre test.

Note sull’implementazione di Defer e Async su WordPress

Su WordPress, gli script JavaScript vengono caricati tramite la funzione wp_enqueue_script da tema e plugin. Dal 2026, le versioni moderne permettono una gestione più granulare delle strategie di caricamento. Temi datati, page builder e plugin incompatibili possono causare conflitti.

Se usi un plugin di performance, evita di differire tutti gli script con un solo click: crea liste di esclusione. Pagina checkout, login, admin bar, validazione sicurezza e captcha sono sensibili. Su siti WooCommerce, testa particolarmente i frammenti carrello, script gateway di pagamento e selettori di variazione. Soluzioni di hosting WooCommerce

Sequenza consigliata per WordPress: elimina plugin inutili, rendi condizionali i file plugin caricati solo su alcune pagine, applica defer su script tema e plugin, e infine usa async o caricamento differito per script terzi indipendenti. Così riduci il rischio di rotture improvvise.

Considerazioni su progetti custom e framework moderni

Su React, Vue, Angular, Next.js, Nuxt e simili, l’ottimizzazione JavaScript non si limita all’attributo defer. Dimensione dei bundle, code splitting, tree shaking, import dinamico e i costi di hydration pesano sul TBT. Un unico file bundle da 700 KB, anche differito, può bloccare a lungo il thread principale.

Usa code splitting basato sulle route: l’utente sulla homepage non deve scaricare codice dell’admin, editor grafico o librerie pesanti. Importa componenti pesanti solo quando servono. Individua dipendenze inutili con tool di analisi. Valuta alternative leggere a librerie per date, grafici o animazioni.

Anche con rendering server-side o statico bisogna fare attenzione: un HTML rapido può comunque causare un TBT elevato se la hydration attiva centinaia di componenti simultaneamente. Evita JavaScript client-side non necessario su contenuti statici, secondo le best practice 2026.

Hosting, tempi di risposta server e impatto sul JavaScript

Il TBT dipende direttamente dal tempo di esecuzione JavaScript nel browser, ma l’infrastruttura hosting ha effetti indiretti. Un TTFB lento, mancanza di compressione, assenza di HTTP/2 o HTTP/3, caching inefficace e latenza geografica possono ritardare la consegna degli script. Quando i file JavaScript arrivano tardi, il ciclo di caricamento si prolunga e l’esperienza utente peggiora.

Un hosting di qualità offre compressione Brotli/Gzip, caching browser efficiente, PHP aggiornato, dischi veloci e CDN integrato. Anche la corretta configurazione SSL è essenziale per sfruttare le tecnologie browser moderne, HTTP/2 e integrazioni sicure. Certificati SSL Hostragons Verifica dominio Hostragons

Un file JavaScript non compresso da 320 KB può scendere a 95 KB con Brotli. Questo non riduce direttamente il TBT, che misura il tempo di esecuzione, ma la velocità di download migliora, le risorse sono prioritarie, e l’esperienza globale è più fluida. Quindi, defer, async, caching e hosting vanno valutati insieme.

Checklist di misurazione e verifica

Valutare l’efficacia dell’ottimizzazione richiede più della semplice osservazione del punteggio PageSpeed. Ecco una checklist per una verifica approfondita:

• Hai confrontato il TBT mobile prima e dopo?
• Il report JavaScript execution time mostra una riduzione dei file più pesanti?
• Il numero di task lunghi nel Performance DevTools è diminuito?
• Ci sono errori JavaScript in console?
• Funzionano correttamente menu, ricerca, filtri, form, carrello e checkout?
• I tag analytics e pubblicità vengono triggerati correttamente?
• I dati utente reali mostrano miglioramenti in INP e tempi di interazione?
• Hai testato dopo aver pulito tutte le cache?

Distinguere tra dati di laboratorio e dati reali è cruciale. Il TBT è una metrica di laboratorio Lighthouse, mentre Interaction to Next Paint (INP) è sempre più rilevante per la UX reale. Una riduzione del TBT, comunque, spesso si traduce in un miglioramento dell’INP grazie a un thread principale meno bloccato.

Errori comuni e come evitarli

Applicare async a tutti gli script contemporaneamente

È uno degli errori più frequenti: async non garantisce l’ordine, quindi può causare errori random su script dipendenti. Una struttura apparentemente stabile può rompersi su connessioni lente o browser diversi. Su script con dipendenze, defer è più sicuro.

Differire erroneamente jQuery e plugin dipendenti

In WordPress, molti plugin dipendono dall’ordine di caricamento di jQuery. Rendere async jQuery core porta i plugin a tentare di eseguire codice prima che jQuery sia disponibile. La soluzione è mappare le dipendenze e escludere i file critici.

Dimenticare gli script di terze parti

Spesso il proprietario ottimizza i file tema ma ignora pubblicità, chat e analytics, che nei report Lighthouse sono tra i task più pesanti. Rimuovi tag inutili, imposta trigger condizionali e carica su interazione quando possibile.

Installare plugin senza misurazione preventiva

I plugin di performance sono utili, ma ogni plugin aggiunge nuovi file JS/CSS. Diagnostica il problema prima di scegliere lo strumento, e verifica che il plugin riduca davvero il TBT con report oggettivi.

Ignorare conflitti tra cache e minificazione

Minificazione, concatenazione, defer e async simultanei possono alterare l’ordine degli script, generando errori in produzione. Se usi CDN, cache server e cache applicativa, pulisci tutte le cache dopo ogni modifica.

Scenario di ottimizzazione reale

Immagina un sito corporate medio con 18 richieste JavaScript sulla homepage: 5 per tema/menu, 4 per slider/animazione, 3 per form/mappa, 6 per analytics/pixel/chat. Il TBT mobile iniziale misurato da Lighthouse è 920 ms.

Step 1: eliminazione di due plugin animazione inutili, meno 140 KB di JS, TBT scende a 760 ms. Step 2: defer su file tema/slider, test ordine, TBT a 480 ms. Step 3: script mappa caricato solo su sezione contatti, chat avviata dopo 7 secondi, analytics/pixel resi async. Il TBT finale è 210 ms.

Questo esempio mostra l’importanza di un approccio stratificato: defer e async sono potenti, ma il miglior risultato si ottiene anche rimuovendo codice superfluo, caricando condizionatamente, usando cache efficace e un’infrastruttura solida.

Conclusione: strategia JavaScript bilanciata e testata per un TBT più basso

Implementare il caricamento differito JavaScript è uno dei modi più pratici ed efficaci per ridurre il TBT. Defer offre una soluzione sicura per script ordinati e eseguiti dopo il DOM; async è ideale per script terzi indipendenti. Il successo passa da una misurazione accurata, classificazione degli script, eliminazione dei superflui, test incrementali e monitoraggio dell’esperienza reale.

Con Hostragons puoi contare su un’infrastruttura veloce, sicura e scalabile, che insieme a ottimizzazione JavaScript, caching e SSL ti aiuta a raggiungere una performance web stabile. Per migliorare il TBT, parti dal report attuale e prosegui con piccoli passi misurabili. Scopri le soluzioni Hostragons per hosting e performance. Pacchetti web hosting Hostragons

Domande Frequenti

Posso usare defer e async insieme sullo stesso script?

Se aggiungi entrambi su uno script, i browser moderni danno priorità ad async, eliminando la garanzia d’ordine. Quindi, non è consigliato usarli insieme sullo stesso file. Usa defer per script dipendenti, async per quelli indipendenti.

Il caricamento differito JavaScript migliora direttamente il posizionamento SEO?

Non garantisce un miglioramento diretto, ma ottimizza l’esperienza utente, la velocità di risposta e i Core Web Vitals, supportando il successo SEO. Pagine più reattive migliorano soddisfazione, conversione e la percezione di qualità agli occhi dei crawler.

È sicuro aggiungere defer a tutti i file JavaScript?

No. Alcuni script devono eseguire subito, altri dipendono da un ordine specifico. Prima di applicare defer, valuta scopo, dipendenze e timing di esecuzione; testa sempre in staging.

Basta defer e async per ridurre il TBT?

Su siti piccoli e medi spesso sì, ma su framework pesanti, siti con molti tag terzi o bundle grandi servono anche code splitting, rimozione JavaScript inutilizzato, caricamento condizionale, caching e hosting performante.

Quali script WordPress non dovrebbero essere async?

Plugin dipendenti da jQuery, script di checkout/carrello, validazione form e funzioni critiche tema non vanno resi async a caso: l’ordine è essenziale. Prova prima defer, crea liste di esclusione se necessario.