Total Blocking Time (TBT) e SEO

TL;DR — Il Total Blocking Time (TBT) misura per quanto tempo la tua pagina è congelata — incapace di rispondere a un clic o a un tocco — mentre si carica. Uno strumento di laboratorio come Lighthouse somma tutto il tempo in cui il thread principale è bloccato tra la prima pittura e quando la pagina diventa interattiva. Sotto 200 ms è buono. È un numero solo da laboratorio, non è una Core Web Vital e non apparirà in Search Console.

Cos’è il TBT

Quando una pagina si carica, il browser ha un thread principale che fa il lavoro pesante — esegue JavaScript, costruisce la pagina, reagisce ai tuoi clic. Può fare solo una cosa alla volta. Se un blocco di JavaScript monopolizza quel thread per troppo tempo, la pagina diventa momentaneamente non reattiva: tocchi un pulsante e non succede nulla finché lo script non finisce.

Total Blocking Time è una misurazione esattamente di quel tempo congelato durante il caricamento. Uno strumento di test come Lighthouse carica la tua pagina in un ambiente controllato, osserva il thread principale e somma tutto il tempo in cui è stato bloccato dal rispondere all’input.

La regola dei 50 ms

Non ogni piccolo lavoro conta. Il browser può gestire attività brevi senza che tu te ne accorga. La linea è 50 millisecondi: qualsiasi attività che dura più di quello è una “long task”, e solo la parte sopra i 50 ms conta come tempo di blocco.

Quindi un’attività che dura 70 ms aggiunge 20 ms al tuo TBT. Un’attività che dura 40 ms non aggiunge nulla. Il TBT è la somma di tutti quei frammenti “sopra i 50 ms” mentre la pagina si carica.

Qual è un buon punteggio?

In Lighthouse, su mobile:

• Buono: 200 ms o meno
• Da migliorare: fino a 600 ms
• Scarso: oltre 600 ms

La cosa che la maggior parte delle persone sbaglia

Il TBT non è una Core Web Vital. Le tre Core Web Vitals sono LCP, INP e CLS. Il TBT è uno strumento di laboratorio che aiuta a prevedere il tuo Interaction to Next Paint (INP) — la metrica basata su utenti reali che Google usa effettivamente. Non troverai il TBT in Google Search Console o nei dati sul campo, perché viene misurato simulando un caricamento di pagina, non osservando visitatori reali.

Vuoi la meccanica completa — l’esempio pratico, perché il TBT ha il peso maggiore in Lighthouse, la differenza tra TBT e INP, e come risolverlo davvero? Passa alla scheda Avanzate.

TL;DR — Il TBT è la quantità totale di tempo, tra First Contentful Paint e Time to Interactive, in cui il thread principale è stato bloccato abbastanza a lungo da impedire la reattività all’input. Somma la parte di blocco (durata − 50 ms) di ogni long task (qualsiasi attività del thread principale oltre 50 ms). È una metrica di laboratorio — il peso singolo più grande (30%) nel punteggio Lighthouse 10 e il proxy di laboratorio per INP — ma non è una Core Web Vital e non appare mai in CrUX o Search Console. Soglie mobile: buono ≤200 ms, scarso >600 ms. Risolvilo come risolveresti l’INP: spezza le attività JS lunghe, fai code-splitting, rimanda/rimuovi JS inutilizzato, doma gli script di terze parti. La mia opinione onesta: risolvilo per gli utenti, non per un aumento di ranking.

Cosa misura realmente il TBT

La definizione di Google è il punto di partenza. Il TBT è “la quantità totale di tempo dopo First Contentful Paint (FCP) in cui il thread principale è stato bloccato abbastanza a lungo da impedire la reattività all’input.” Il thread principale del browser elabora un’attività alla volta; mentre è occupato con un lungo blocco di lavoro, non può reagire a un clic, a un tocco, o a una pressione di un tasto. Il TBT quantifica quanto della finestra di caricamento della tua pagina viene speso in quello stato bloccato.

Due definizioni fanno tutto il lavoro qui:

• Una long task è “un’attività che gira sul thread principale per più di 50 millisecondi.”
• La parte di blocco di un’attività è la sua durata meno 50 ms. Le attività a o sotto i 50 ms contribuiscono esattamente 0 ms.

Il TBT è la somma di quelle porzioni di blocco tra FCP e Time to Interactive (TTI). Quindi First Contentful Paint è la linea di partenza: nulla prima della prima pittura conta, perché non c’è ancora nulla sullo schermo con cui interagire.

L’esempio pratico

La tabella di Google è l’illustrazione più chiara. Immagina cinque attività eseguite sul thread principale tra FCP e TTI:

Le attività tre e quattro sono sotto la soglia dei 50 ms, quindi non contribuiscono nulla. L’attività uno blocca per 250 − 50 = 200 ms, l’attività cinque per 155 − 50 = 105 ms. Somma le porzioni di blocco — 200 + 40 + 0 + 0 + 105 — e ottieni 345 ms di TBT. Questo è un punteggio “da migliorare”, guidato quasi interamente da due attività pesanti.

Questa è la parte controintuitiva che vale la pena interiorizzare: “Un piccolo numero di attività sul thread principale non significa necessariamente un basso tempo di blocco. Al contrario, un grande numero di attività non porta necessariamente a un sacco di tempo di blocco.” (Quella formulazione è di NitroPack, riportata qui — riverificata sulla fonte live il 2026-07-18.) Ciò che conta è se le attività individuali superano i 50 ms, non quante attività ci sono.

La finestra di misurazione: da FCP a TTI

La finestra termina al Time to Interactive — “il tempo dall’inizio del caricamento della pagina a quando le sue principali sotto-risorse sono state caricate ed è in grado di rispondere in modo affidabile all’input dell’utente rapidamente.” In Lighthouse, il TTI si trova cercando in avanti una “finestra di quiete” di cinque secondi senza attività lunghe e con non più di due richieste di rete in volo.

Vale la pena notare: il TTI stesso è stato rimosso da Lighthouse 10 perché si è rivelato eccessivamente sensibile a richieste di rete anomale e attività lunghe, producendo un’alta variabilità. Il TBT è sopravvissuto ed è diventato la metrica di interattività primaria. Come ha detto Philip Walton, “Nuove metriche alternative come Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Interaction to Next Paint (INP) sono solitamente metriche migliori da usare al posto del TTI.” Il TBT non ha sostituito il TTI come endpoint della finestra — è un numero singolo migliore per lo stesso problema di fondo. E la scomparsa del TTI dall’interfaccia del report di Lighthouse non è la stessa affermazione del TTI che non delimita più la finestra di navigazione predefinita di Lighthouse — la finestra stessa è ancora misurata in quel modo sotto il cofano.

Un’altra nota di delimitazione: “FCP to TTI” descrive specificamente l’audit di navigazione predefinito di Lighthouse. Altri strumenti, o Lighthouse stesso che esegue una traccia di intervallo di tempo invece di una navigazione completa di caricamento pagina, possono totalizzare una finestra misurata diversa — la matematica delle attività lunghe di 50 ms non cambia, ma i punti di inizio e fine di ciò che viene sommato sono specifici dello strumento e della modalità di traccia, non una legge universale della metrica.

Il TBT è un Core Web Vital? No.

È l’equivoco più comune: le tre Core Web Vitals sono LCP, INP e CLS; TBT non è tra queste. Google scrive: “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (traduzione) «Total Blocking Time è una metrica di laboratorio utile per individuare e diagnosticare potenziali problemi di interattività che possono influire su INP; non fa però parte delle Core Web Vitals perché non è misurata sul campo né riflette un risultato incentrato sull’utente». La grammatica della frase originale è di Google.

Quindi dove appare il TBT e dove non appare?

• Dove lo vedi: Lighthouse, PageSpeed Insights’ lab tab, e Chrome DevTools — tutti ambienti simulati/lab.
• Dove non lo vedi: il report Core Web Vitals di Google Search Console, CrUX, o qualsiasi dato di campo. Quelli includono solo LCP, INP e CLS.

Se qualcuno ti dice che sta “guardando TBT in Search Console”, si sbaglia — GSC riporta dati di campo, e TBT non è una metrica di campo.

Una correzione su cui vale la pena essere precisi: TBT raccomandato in lab non è la stessa cosa di TBT impossibile in campo. Puoi tecnicamente calcolare un totale in stile TBT in campo con la Long Tasks API — Google lo dice direttamente: “It is possible to measure TBT in the field, but we don’t recommend this as user interaction can affect your page’s TBT in ways that lead to lots of variance in your reports.” (traduzione) «È possibile misurare TBT in campo, ma non lo consigliamo perché l’interazione dell’utente può influenzare il TBT della tua pagina in modi che portano a molta varianza nei tuoi report.» Questa è una raccomandazione contro, non un muro tecnico. Ciò che è realmente vero senza eccezioni è più ristretto: CrUX e il report Core Web Vitals di Search Console non includono mai TBT, punto e basta — quelle pipeline raccolgono solo LCP, INP e CLS.

TBT è il proxy di laboratorio per INP

Ecco perché TBT esiste. Gli strumenti di laboratorio caricano una pagina in un ambiente simulato senza utente reale, quindi non possono misurare Interaction to Next Paint — INP richiede clic e tocchi reali. TBT colma questa lacuna: “the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” (traduzione) «La metrica Total Blocking Time (TBT) è misurabile in laboratorio ed è un proxy per INP.»

I due sono meccanicamente correlati: “Although INP and TBT are calculated differently, they are both reflections of a blocked main thread during the bootstrap process. When the main thread is blocked, the browser is delayed in responding to user interactions.” (traduzione) «Sebbene INP e TBT siano calcolati in modo diverso, sono entrambi riflessi di un thread principale bloccato durante il processo di bootstrap. Quando il thread principale è bloccato, il browser ritarda la risposta alle interazioni dell’utente.» E empiricamente, “A low TBT often correlates with a low Interaction to Next Paint (INP).” (traduzione) «Un TBT basso spesso è correlato a un basso Interaction to Next Paint (INP).»

Ma “proxy” non è “sostituto”. Google è esplicito: “Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (traduzione) «Total Blocking Time (TBT) può essere una metrica proxy ragionevole per INP, ma non è un sostituto di INP di per sé.» Divergano in modi reali:

• TBT alto, INP buono. TBT misura il blocco durante il caricamento. Se i tuoi utenti non provano effettivamente a interagire durante quella finestra bloccata — aspettano che la pagina sembri finita prima — il loro INP può essere buono anche con un TBT brutto.
• TBT buono, INP scarso. INP copre anche gestori di eventi lenti e lavoro di rendering che scattano dopo il caricamento, più cose come il ritardo di 300 ms del tocco del browser su pagine non ottimizzate per mobile — nessuna delle quali TBT vede.

Quando lab e campo non concordano, fidati del campo. INP (il numero dell’utente reale) ha priorità su TBT (la stima di laboratorio).

Una nota storica che confonde le persone: TBT era il proxy di laboratorio per First Input Delay (FID). INP ha sostituito FID come Core Web Vital il 12 marzo 2024, quindi TBT ora è il proxy di INP. Il meccanismo sottostante non è mai cambiato — è sempre stato un thread principale bloccato durante il caricamento — ma qualsiasi articolo più vecchio che chiama TBT “proxy di FID” precede quella transizione.

Perché TBT domina il punteggio Lighthouse

TBT ha il peso singolo più grande nel punteggio Performance di Lighthouse — 30%, un peso introdotto in Lighthouse 10 e, verificato dal vivo contro i documenti di punteggio di Chrome il 18 luglio 2026, ancora invariato fino all’attuale Lighthouse 13:

Tratta quella tabella come limitata a versione e data, non come una costante permanente — Lighthouse ha cambiato i suoi pesi prima e può farlo di nuovo. Riverifica contro Lighthouse performance scoring prima di citarla in un deck di audit.

Questa è la ragione pratica per cui il TBT è importante negli audit SEO anche se non è un segnale di ranking: un TBT scarso ha un effetto sproporzionato su quel grande punteggio Lighthouse che tutti catturano con uno screenshot. L’esempio pratico di Addy Osmani lo rende concreto: la rimozione di un polyfill Intersection Observer ha ridotto il TBT da 400 ms a 300 ms e ha portato il punteggio Lighthouse Performance da 63 a 70. Una correzione, sette punti, grazie al peso del 30%.

Un’altra sfumatura: la soglia di categoria “Buono ≤200 ms” e il punteggio Lighthouse sono scale diverse. Per ottenere 90+ nel sottopunteggio TBT servono circa ≤300 ms su mobile, e per raggiungere 100 servono ≤100 ms. (Quelle cifre del sottopunteggio sono la documentazione di DebugBear sulla curva di punteggio, riverificata sulla fonte live il 2026-07-18.) “Buono” e “100” non sono la stessa soglia.

Il TBT influisce sul ranking SEO?

Non direttamente — e sarò più diretto di quanto facciano molti.

Il TBT non è un segnale di ranking. L’input di ranking per l’interattività di Google è INP, una metrica di campo. Il TBT è un diagnostico che ti aiuta a trovare e correggere i task lunghi che danneggiano l’INP. Migliorare il TBT può migliorare l’INP, che potrebbe aiutare marginalmente l’aspetto Page Experience del ranking — ma sono due anelli di “può” lontani dalle tue posizioni.

E questa è la mia posizione reale sull’intera questione dei Core Web Vitals, che ho già scritto nella mia guida alla velocità delle pagine: non credo che i Core Web Vitals abbiano molto impatto sulla SEO e, a meno che tu non sia estremamente lento, generalmente non li darei priorità. Falli per gli utenti e le conversioni, non per un aumento del ranking. Questo vale doppiamente per il TBT, che è un proxy di laboratorio per una metrica di campo per un piccolo input di ranking. Correggilo perché una pagina bloccata ti fa perdere clienti — non perché stai inseguendo una posizione.

Cosa causa un TBT alto

È quasi sempre JavaScript:

• Caricamento, parsing o esecuzione di JavaScript non necessario — le parole stesse dell’audit Lighthouse. Inviare un bundle grande che la pagina non serve al caricamento è la causa classica.
• Istruzioni JavaScript inefficienti — lavoro sincrono pesante che monopolizza il thread principale.
• Script di terze parti — tag manager, widget di chat, analytics, script pubblicitari. Spesso il contributore singolo più grande, e quello su cui hai meno controllo.
• Bootstrap di framework pesante — l’idratazione di React e simili può eseguire task lunghi durante l’avvio.
• Ricalcolo di stile/layout e garbage collection — layout sincrono forzato, grandi ricalcoli di stile e pause del GC appaiono anche come task del thread principale; non dare per scontato che ogni task lungo nella traccia sia esecuzione di JavaScript.

Non dare per scontato nemmeno che la dimensione di trasferimento del bundle sia tutta la storia. L’attribuzione della traccia ha lacune reali: i frame cross-origin e i thread worker hanno limiti di privacy e sicurezza su ciò che un osservatore di task lunghi può riportare su di loro (vedi Risoluzione dei problemi), quindi un task non attribuito nella tua traccia non è la prova che nessuna terza parte sia coinvolta — potrebbe semplicemente significare che l’API di attribuzione non è autorizzata a dirtelo.

Come correggere un TBT alto

Le correzioni sono della stessa famiglia delle correzioni INP — entrambe si riducono a un thread principale bloccato.

1. Trova le attività lunghe. Apri il pannello Performance di Chrome DevTools e cerca attività oltre 50 ms (sono contrassegnate con angoli rossi), oppure esegui l’audit Lighthouse “Evita attività lunghe sul thread principale”.
2. Controlla prima gli script di terze parti. Di solito sono le vittorie più facili. Usa le schede Coverage e Network di DevTools per vedere quanto costa ogni script e carica in modo lazy gli embed pesanti (YouTube, mappe, chat) dietro una facciata.
3. Spezza le attività lunghe. Cedi il controllo al thread principale così il browser può gestire l’input tra i blocchi — “quando le attività vengono spezzate, il browser può rispondere al lavoro a priorità più alta molto prima, incluse le interazioni dell’utente.” L’API moderna è scheduler.yield(), con un fallback setTimeout(resolve, 0) (vedi la scheda Cheat Sheets per il pattern). Nota che Google non raccomanda più isInputPending() — cedi il controllo indipendentemente dal fatto che l’input sia in sospeso.
4. Riduci il JavaScript. Dividi i bundle grandi in codice separato così meno codice viene analizzato ed eseguito al caricamento, rimuovi JS non utilizzato (la scheda Coverage di DevTools ti mostra cosa) e usa defer per gli script non critici.
5. Sposta i calcoli pesanti fuori dal thread principale. I Web Worker eseguono il lavoro ad alta intensità di CPU su un thread separato, lasciando il thread principale libero di rispondere.

Un utile effetto collaterale: le attività lunghe che bloccano il thread principale possono anche ritardare il rendering di Largest Contentful Paint, quindi correggere il TBT a volte migliora anche l’LCP — specialmente quando è coinvolto JS che blocca il rendering.

Dove andare dopo

Il TBT fa parte della famiglia Core Web Vitals insieme al suo equivalente sul campo Interaction to Next Paint, le metriche di caricamento Largest Contentful Paint e First Contentful Paint, e gli strumenti di laboratorio Lighthouse, PageSpeed Insights e Speed Index che le riportano. Se ricordi solo una cosa: il TBT è la spia di laboratorio per la reattività sul campo — caccia le attività lunghe, non il numero.

Riepilogo AI

Una sintesi della versione Advanced:

• TBT = tempo di blocco del thread principale durante il caricamento. È il tempo totale, tra FCP e TTI, in cui il thread principale è stato bloccato abbastanza a lungo da impedire la reattività all’input.
• La matematica: somma della parte bloccante (duration − 50 ms) di ogni attività lunga (qualsiasi attività del thread principale oltre 50 ms). Le attività ≤50 ms aggiungono 0 ms. L’esempio di Google: attività di 250/90/35/30/155 ms → 345 ms di TBT.
• È una metrica di laboratorio. La vedi in Lighthouse, nella scheda laboratorio di PageSpeed Insights e in DevTools — mai in CrUX o Search Console.
• Non è una Core Web Vital. Le tre CWV sono LCP, INP, CLS. Il TBT è il proxy di laboratorio per INP (storicamente il proxy di FID; INP ha sostituito FID il 12 marzo 2024).
• Peso maggiore in Lighthouse: 30% — il singolo più grande, quindi un TBT scarso affonda il punteggio complessivo. Soglie mobile: buono ≤200 ms, da migliorare ≤600 ms, scarso

  600 ms.

• Ranking: non è un fattore di ranking diretto. INP è il segnale sul campo; TBT aiuta solo a diagnosticarlo. L’opinione di Patrick: correggilo per gli utenti e le conversioni, non per un aumento del ranking.
• Correzioni (stessa famiglia di INP): trova le attività lunghe in DevTools, controlla prima gli script di terze parti, spezza le attività con scheduler.yield(), dividi il codice e rimuovi JS non utilizzato, scarica il lavoro pesante sui Web Worker.
• Avvertenza: TBT e INP possono divergere — TBT alto con INP buono (gli utenti non interagiscono durante il caricamento) o TBT buono con INP scarso (gestori di eventi lenti dopo il caricamento). I dati sul campo vincono.
• «Solo laboratorio» significa raccomandato in laboratorio, non impossibile sul campo. Puoi tecnicamente calcolare un totale in stile TBT dai dati sul campo con l’API Long Tasks, ma Google lo sconsiglia (troppa varianza tra le esecuzioni) — CrUX e Search Console semplicemente non lo riportano mai in ogni caso.
• L’attribuzione delle tracce ha reali lacune. I frame cross-origin e i thread worker hanno limiti di privacy/sicurezza su ciò che un osservatore di attività lunghe può riportare, quindi un’attività non attribuita significa «causa sconosciuta», non «nessuna terza parte coinvolta».

Documentazione ufficiale

Documentazione di fonte primaria su TBT da Google e dal team di Chrome.

web.dev／Chrome

• Total Blocking Time (TBT) — Philip Walton e Barry Pollard: definizione canonica, regola dei 50 ms ed esempio svolto.
• Audit Lighthouse del TBT — soglie mobile／desktop e cause indicate.
• Calcolo del punteggio Performance di Lighthouse — pesi delle metriche e origine del 30% di TBT.
• Web Vitals — perché TBT non è una Core Web Vital e come si rapporta all’insieme.
• Interaction to Next Paint (INP) — metrica sul campo di cui TBT è proxy, non sostituto.
• Ottimizzare i long task — Jeremy Wagner e Brendan Kenny su suddivisione dei task, scheduler.yield() e abbandono di isInputPending().
• Time to Interactive (TTI) — fine della finestra TBT e rimozione da Lighthouse 10.
• Differenze tra dati di laboratorio e sul campo — limiti di TBT come sostituto di INP.

Citazioni dalla fonte

Dichiarazioni ufficiali dalla documentazione di Google. Ogni link è un deep link che salta al passaggio citato.

Definizione e meccanica

• “the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness.” (traduzione) «il tempo totale dopo First Contentful Paint in cui il main thread è rimasto bloccato abbastanza da impedire la risposta agli input» — web.dev, Total Blocking Time. Vai alla citazione
• “a task that runs on the main thread for more than 50 milliseconds” (traduzione) «un task eseguito sul main thread per più di 50 millisecondi»: la definizione di long task. Vai alla citazione
• “To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.” (traduzione) «Per offrire una buona esperienza, i siti dovrebbero puntare a un TBT inferiore a 200 millisecondi su hardware mobile medio». Vai alla citazione
• “A low TBT often correlates with a low Interaction to Next Paint (INP).” (traduzione) «Un TBT basso spesso è correlato a un INP basso». Vai alla citazione

Stato: non è una Core Web Vital

• “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (traduzione) «Il Total Blocking Time (TBT) è una metrica di laboratorio ed è fondamentale per individuare e diagnosticare potenziali problemi di interattività che possono influire sull’INP. Tuttavia, non fa parte dell’insieme delle Core Web Vitals perché non sono misurabili sul campo, né riflettono un risultato incentrato sull’utente.» — web.dev, Web Vitals (Philip Walton). (La grammatica è fedele alla fonte.) Vai alla citazione

TBT come proxy di INP

• “In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (traduzione) «In tali casi, il Total Blocking Time (TBT) può essere una metrica proxy ragionevole per l’INP, ma non è un sostituto dell’INP di per sé.» — web.dev, Interaction to Next Paint. Vai alla citazione

Attività lunghe e come risolverle

• “The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.” (traduzione) «Il thread principale può elaborare un solo compito alla volta. Qualsiasi compito che richieda più di 50 millisecondi è un compito lungo.» — web.dev, Optimize long tasks. Vai alla citazione
• “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” (traduzione) «Quando i compiti vengono suddivisi, il browser può rispondere molto prima al lavoro a priorità più alta, incluse le interazioni dell’utente.» Vai alla citazione
• Su isInputPending(): “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” (traduzione) «Non raccomandiamo più l’uso di questa API e raccomandiamo invece di cedere il controllo indipendentemente dal fatto che ci sia input in attesa o meno.» Vai alla citazione

TTI e perché TBT l’ha sostituito come numero chiave dell’interattività

• “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (traduzione) «Metriche più recenti e alternative come Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Interaction to Next Paint (INP) sono di solito metriche migliori da usare al posto di TTI.» — web.dev, Time to Interactive (Philip Walton). Vai alla citazione

Checklist di triage TBT

Un passaggio rapido quando Lighthouse ti dà un Total Blocking Time rosso (o arancione):

• Conferma che stai leggendo dati di laboratorio — TBT è in Lighthouse / PageSpeed Insights’ scheda di laboratorio / DevTools, non nel campo o in Search Console.
• Apri il pannello Performance di DevTools e trova i compiti lunghi (oltre 50 ms, con angolo rosso) tra la prima pittura e l’interattività.
• Elenca i tuoi script di terze parti e quanto costa ciascuno (schede Coverage + Network) — inizia da qui; di solito è la vittoria più grande e facile.
• Carica in modo pigro gli embed pesanti (YouTube, mappe, chat) dietro una facciata.
• Esegui gli audit Lighthouse “Evita compiti lunghi sul thread principale” e “Riduci JavaScript inutilizzato” e lavora sull’elenco.
• Dividi il codice dei bundle grandi così meno JS viene analizzato/valutato al caricamento.
• Rimanda gli script non critici; usa import() dinamico per ciò che non serve immediatamente.
• Suddividi i compiti lunghi rimanenti con scheduler.yield() (fallback setTimeout). Non ricorrere a isInputPending().
• Sposta il calcolo pesante per la CPU a un Web Worker.
• Controlla incrociato il campo: estrai INP da CrUX / monitoraggio utenti reali. Se INP è a posto, non investire troppo nell’inseguire il numero di laboratorio.

Cheat sheet TBT

La matematica, in una riga

TBT = Σ (taskDuration − 50 ms) per ogni compito > 50 ms tra FCP e TTI. I compiti ≤ 50 ms contribuiscono 0 ms.

Esempio pratico (di Google)

Soglie Lighthouse

(Le soglie differiscono dalla curva del sottopunteggio Lighthouse: 90+ ≈ ≤300 ms mobile, 100 ≈ ≤100 ms mobile — cifre documentate da DebugBear, riverificate live il 18-07-2026.)

TBT vs. INP — il cheat sheet

Pattern yield-to-main (la soluzione)

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Usa scheduler.yield() dove disponibile, altrimenti ripiega su setTimeout. Non usare isInputPending() — Google ora consiglia di cedere indipendentemente dal fatto che ci sia input in attesa.

Strumenti per misurare e correggere il TBT

• PageSpeed Insights — mostra il TBT nei dati di laboratorio, non nella sezione sul campo.
• Lighthouse (pannello Lighthouse di Chrome DevTools o CLI) — produce il valore TBT e gli audit «Evita attività lunghe sul main thread» e «Riduci JavaScript inutilizzato».
• Chrome DevTools, pannello Performance — registra un caricamento e individua i long task oltre 50 ms, segnalati con angoli rossi, che compongono il TBT.
• Chrome DevTools, scheda Coverage — mostra la quota usata di ogni script per individuare JavaScript inutilizzato e terze parti pesanti.
• WebPageTest — test di laboratorio con dettaglio di main thread e CPU.
• Long Animation Frames (LoAF) API — complemento moderno sul campo, non sostituto del calcolo TBT nella finestra di caricamento. Attribuisce frame lunghi durante l’intera visita, più vicino ai problemi INP rispetto alla sola finestra FCP→TTI.
• TBT sul campo tramite Long Tasks API — tecnicamente possibile sommando duration − 50 ms per i long task osservati in produzione, come nello snippet della scheda Scripts. Google lo sconsiglia per RUM perché l’interazione reale rende il valore troppo variabile tra esecuzioni. Per la reattività sul campo usa INP o LoAF.
• Dove non compare: il report Core Web Vitals di Google Search Console e CrUX includono soltanto LCP, INP e CLS, mai TBT.

Errori TBT che producono la correzione sbagliata

• Chiamare il TBT una Core Web Vital. Il TBT è un diagnostico di laboratorio e un utile proxy per la contesa del thread principale; l’INP è la Core Web Vital degli utenti reali. Riportali separatamente.
• Contare l’intera attività lunga come tempo di blocco. Solo la parte oltre 50 millisecondi conta. Un’attività di 70 millisecondi contribuisce con 20 millisecondi, non 70.
• Ottimizzare al di fuori della finestra di misurazione. Il TBT di Lighthouse somma il blocco tra FCP e TTI. Il lavoro prima o dopo quella finestra può contare per gli utenti, ma non fa parte di quel valore TBT.
• Rimuovere codice first-party ignorando la terza parte più grande. Usa la traccia e gli inizializzatori di richiesta per attribuire le attività lunghe prima di scegliere un proprietario o una correzione.
• Dividere il codice senza ridurre il lavoro. Molte attività più piccole possono migliorare la reattività, ma distribuire lo stesso JavaScript non necessario costa comunque parsing, compilazione ed esecuzione. Rimuovi il lavoro inutilizzato oltre a cederlo.
• Presumere che un buon TBT di laboratorio dimostri un buon INP sul campo. Gli utenti reali interagiscono dopo il caricamento su dispositivi vari. Conferma il risultato con i dati di reattività sul campo.

Il TBT è alto ma la rete sembra veloce

Sintomo: Le risorse si scaricano rapidamente, ma Lighthouse segnala un blocco pesante.

Causa probabile: Il parsing, la compilazione, l’esecuzione, l’idratazione di JavaScript o il lavoro di terze parti monopolizzano il thread principale dopo l’arrivo dei byte.

Correzione e conferma: Registra una traccia Performance, ordina le attività lunghe per durata e proprietario, poi rimuovi il codice inutilizzato, rimanda il lavoro non critico o dividi l’attività più grande. Conferma che la parte di blocco diminuisca in esecuzioni abbinate ripetute.

Un bundle grande è rimandato ma il TBT rimane alto

Sintomo: L’aggiunta di defer modifica l’ordine di download/esecuzione senza spostare materialmente il TBT.

Causa probabile: Lo stesso codice costoso viene ancora eseguito nella finestra da FCP a TTI.

Correzione e conferma: Profila le funzioni all’interno del task lungo. Suddividi il codice per route o interazione, riduci l’idratazione o rimuovi lavoro inutilizzato/duplicato; poi verifica che il tempo di esecuzione, non solo l’ora di inizio della richiesta, diminuisca.

Il TBT di Lighthouse è buono mentre l’INP sul campo è scarso

Sintomo: I test di laboratorio di navigazione sembrano reattivi, ma CrUX o RUM riportano interazioni lente.

Causa probabile: Il task problematico si verifica dopo il caricamento iniziale o solo dopo un’interazione reale che la navigazione standard di Lighthouse non esercita.

Correzione e conferma: Raccogli tracce di interazione per le pagine con INP scarso e i dispositivi, riproduci l’azione localmente e ottimizza la gestione degli eventi e il paint successivo.

Un task lungo appare senza un proprietario chiaro

Sintomo: DevTools o un osservatore dell’API Long Tasks segnala un task bloccante, ma l’attribuzione è vuota, generica o etichettata come “unknown” / “cross-origin”.

Causa probabile: è una lacuna di copertura nota, non un errore di misura. La specifica Long Tasks API limita ciò che può riportare tra execution context: i task degli ancestor cross-origin non vengono riportati perché “this is not reported because of security” (traduzione) «non viene riportato per motivi di sicurezza»; inoltre un iframe cross-origin profondamente annidato “does not receive any information” (traduzione) «non riceve alcuna informazione» su un long task di un ancestor cross-origin. Anche il lavoro in Web Worker o nel compositor thread del browser può restare fuori dalle superfici di attribuzione.

Correzione e conferma: Non concludere “nessun terzo è coinvolto” solo perché nulla è nominato. Controlla incrociando con la colonna initiator del pannello Network, la scheda Coverage e (dove controlli lo script) l’instrumentazione first-party all’interno degli iframe che possiedi. Tratta un task non attribuito come “causa sconosciuta”, non “causa assente”.

Il TBT varia notevolmente tra le esecuzioni

Sintomo: Una esecuzione è verde e la successiva è scarsa senza alcun deployment.

Causa probabile: Esecuzione variabile di terze parti, tempi del server che cambiano la finestra di lavoro, stato della cache o contesa della macchina di test.

Correzione e conferma: Abbina le impostazioni, esegui diversi test a freddo e confronta i proprietari dei task lunghi e il risultato mediano piuttosto che selezionare un singolo punteggio.

Trasforma una traccia in un piano di proprietà

Review this Lighthouse/DevTools trace for Total Blocking Time. For every long task
between FCP and TTI, calculate only duration above 50 ms as blocking time, attribute
the task to first-party code, framework/hydration, or a named third party, and rank
owners by blocking contribution. Propose remove, reduce, defer, split, or yield actions
with a validation test for each. Do not treat TBT as field INP or a direct ranking
factor.

Confronta due tracce di performance

Compare these before/after traces under matched settings. Report FCP, TBT, the largest
long tasks, their initiators, and whether work moved outside the measurement window or
was actually removed. Flag regressions hidden by the aggregate score. Return a verdict,
confidence limits from the supplied runs, and the next smallest experiment. Do not
invent missing timings.

Rivedi una decisione su uno script di terze parti

Given this script's business purpose, loading pattern, request initiator, and main-
thread tasks, decide whether to keep, delay, conditionally load, replace, or remove it.
Separate network cost from execution/blocking cost. Include consent and functionality
constraints, owner, implementation step, TBT validation, field-INP follow-up, and
rollback trigger.

Osserva i task lunghi durante una riproduzione

Esegui questo all’inizio nella console di DevTools, riproduci il caricamento o l’interazione e ispeziona la parte bloccante di ogni task:

let observedBlocking = 0;
const observer = new PerformanceObserver(list => {
  for (const task of list.getEntries()) {
    const blocking = Math.max(0, task.duration - 50);
    observedBlocking += blocking;
    console.log({ start: task.startTime, duration: task.duration, blocking });
  }
  console.log('Observed blocking total:', observedBlocking);
});
observer.observe({ type: 'longtask', buffered: true });

Questo è un totale di debug per il periodo che osservi, non il TBT ufficiale di Lighthouse a meno che non riproduca deliberatamente la stessa finestra FCP-to-TTI e le stesse condizioni di test.

Segnala gli script con il maggior tempo di valutazione sul thread principale

Dopo aver registrato una traccia Performance di DevTools, usa la vista Bottom-up raggruppata per URL. Per un inventario di rete rapido accanto ad essa, questo snippet di console elenca il JavaScript trasferito dal più grande al più piccolo:

performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .map(r => ({ script: r.name, transferred: r.transferSize, duration: r.duration }))
  .sort((a, b) => b.transferred - a.transferred);

La dimensione di trasferimento grande è solo un indizio; la traccia Performance è ciò che attribuisce il tempo di parsing ed esecuzione al TBT.

Riduzione dei task lunghi

Test da eseguire: Cattura diverse tracce Lighthouse/Performance abbinate prima e dopo la modifica JavaScript e confronta i task lunghi tra FCP e TTI.

Risultato atteso: Il task mirato scompare, si accorcia o si suddivide in task più piccoli, e il TBT mediano migliora senza ritardare FCP o rompere la funzionalità.

Interpretazione del fallimento: Il lavoro si è spostato in un altro bundle/task, viene ancora eseguito nella stessa finestra, o la varianza normale delle esecuzioni è maggiore della modifica.

Finestra di monitoraggio: Testa immediatamente nei profili di laboratorio mobile e desktop e osserva l’INP sul campo durante la prossima finestra di reporting.

Trigger di rollback: Fai rollback se le interazioni critiche si rompono, gli errori aumentano o una regressione ripetibile di FCP/LCP/INP supera il miglioramento del TBT.

Rinvio di terze parti

Test da eseguire: Confronta una traccia a freddo con la terza parte nella sua posizione attuale e con essa ritardata fino al consenso, al tempo di inattività o all’interazione pertinente.

Risultato atteso: I suoi task lunghi lasciano la finestra TBT iniziale mentre l’evento aziendale richiesto viene ancora attivato al momento previsto.

Interpretazione del fallimento: Un altro loader la inietta in anticipo, il codice dipendente blocca la pagina o il lavoro del thread principale dello script non è il collo di bottiglia misurato.

Finestra di monitoraggio: Valida su ogni template che carica lo script e monitora sia le prestazioni che l’evento aziendale dopo il rilascio.

Trigger di rollback: Ripristina il percorso di caricamento precedente se consenso, analytics, checkout, annunci o un’altra funzione richiesta perde eventi validi.

Follow-up sulla reattività sul campo

Test da eseguire: Segmenta l’INP sul campo per template/dispositivi interessati dopo la modifica del TBT in laboratorio, mantenendo annotata la data di distribuzione.

Risultato atteso: La reattività sul campo rimane stabile o migliora; un miglioramento solo in laboratorio non viene riportato come risultato per l’utente finché le prove sul campo non lo supportano.

Interpretazione del fallimento: Il lavoro di interazione reale avviene al di fuori del caricamento iniziale o la coorte ottimizzata è troppo piccola per spostare l’aggregato.

Finestra di monitoraggio: Rivedi attraverso l’intera finestra di reporting dei dati sul campo e durante le interazioni ad alto valore.

Trigger di rollback: Indaga o esegui il rollback se l’INP sul campo o il successo delle interazioni critiche regrediscono costantemente dopo il rilascio.

Mettiti alla prova: Total Blocking Time

Cinque domande rapide su matematica e diagnosi del TBT. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

Ufficiale

• Total Blocking Time (TBT) — la definizione canonica e un esempio pratico.
• Optimize long tasks — la guida pratica alla risoluzione (scheduler.yield(), batching, perché non isInputPending()).
• Web Vitals — dove si colloca il TBT rispetto ai Core Web Vitals.
• Optimizing Web Vitals using Lighthouse — Addy Osmani; include l’esempio pratico di rimozione del polyfill (TBT 400→300 ms, punteggio 63→70).

Da altri, da verificare prima della citazione

• DebugBear — Total Blocking Time — approfondimento tecnico sul rapporto TBT↔INP e sulla curva di punteggio Lighthouse.
• NitroPack — Che cos’è Total Blocking Time? — perché il numero di task non equivale al blocking time.
• Guida TBT di BrowserStack e TBT secondo Catchpoint — panoramiche orientate a strumenti e monitoring.
• Metriche di performance incentrate sull’utente — classificazione di Philip Walton: TBT è una metrica lab di reattività al caricamento, distinta dalle metriche sul campo; spiega perché non compare in CrUX.
• Introduzione alla misurazione delle Web Vitals — TBT come proxy lab di INP quando la misurazione reale non è disponibile in ambienti simulati.
• WebPageTest — strumento lab gratuito che mostra TBT, main thread e CPU per trovare i task responsabili.
• Copertura Core Web Vitals di Search Engine Journal — aggiornamenti di settore sul ruolo di TBT negli audit e sui divari tra lab e campo.

Statistiche da citare

• TBT vale il 30% del punteggio Performance di Lighthouse, il peso singolo maggiore (LCP e CLS 25% ciascuno; FCP e Speed Index 10% ciascuno). Introdotto in Lighthouse 10, è stato riverificato il 18 luglio 2026 come invariato fino a Lighthouse 13. Fonte
• La soglia «buono» è ≤200 ms su mobile (≤150 ms desktop); «scarso» è >600 ms su mobile (>350 ms desktop). Fonte
• Un polyfill vale sette punti. Rimuovere un polyfill di Intersection Observer ha ridotto TBT da 400 ms a 300 ms e aumentato il punteggio Lighthouse da 63 a 70, mostrando l’effetto del peso del 30%. Fonte
• Un task da 250 ms contribuisce 200 ms di blocking time: la parte bloccante è sempre duration − 50 ms. L’esempio Google totalizza 345 ms su cinque task. Fonte

Cronologia modifiche