Tempo Total de Bloqueio (TBT)

TL;DR — O Tempo de Bloqueio Total (TBT) mede por quanto tempo sua página fica congelada — incapaz de responder a um clique ou toque — enquanto carrega. Uma ferramenta de laboratório como o Lighthouse soma todo o tempo em que a thread principal fica bloqueada entre a primeira pintura e o momento em que a página se torna interativa. Abaixo de 200 ms é bom. É um número apenas de laboratório, não é um Core Web Vital e não aparecerá no Search Console.

O que é TBT

Quando uma página carrega, o navegador tem uma thread principal fazendo o trabalho pesado — executando JavaScript, construindo a página, reagindo aos seus cliques. Ela só pode fazer uma coisa por vez. Se um pedaço de JavaScript monopoliza essa thread por muito tempo, a página fica momentaneamente sem resposta: você toca em um botão e nada acontece até o script terminar.

O Tempo de Bloqueio Total é uma medição exatamente desse tempo congelado durante o carregamento. Uma ferramenta de teste como o Lighthouse carrega sua página em um ambiente controlado, observa a thread principal e soma todo o tempo em que ela ficou bloqueada para responder à entrada do usuário.

A regra dos 50 ms

Nem todo trabalho conta. O navegador pode lidar com tarefas curtas sem que você perceba. O limite é 50 milissegundos: qualquer tarefa que execute por mais tempo que isso é uma “tarefa longa”, e apenas a parte acima de 50 ms conta como tempo de bloqueio.

Então, uma tarefa que executa por 70 ms adiciona 20 ms ao seu TBT. Uma tarefa que executa por 40 ms não adiciona nada. O TBT é a soma de todos esses fragmentos “acima de 50 ms” enquanto a página está carregando.

Qual é uma boa pontuação?

No Lighthouse, no celular:

• Bom: 200 ms ou menos
• Precisa de melhorias: até 600 ms
• Ruim: acima de 600 ms

O que a maioria das pessoas erra

TBT não é um Core Web Vital. Os três Core Web Vitals são LCP, INP e CLS. O TBT é uma ferramenta de laboratório que ajuda a prever seu Interaction to Next Paint (INP) — a métrica de usuário real que o Google realmente usa. Você não encontrará o TBT no Google Search Console nem nos dados de campo, porque ele é medido simulando um carregamento de página, não observando visitantes reais.

Quer a mecânica completa — o exemplo prático, por que o TBT tem o maior peso no Lighthouse, a diferença entre TBT e INP e como corrigi-lo de verdade? Mude para a aba Avançado.

TL;DR — TBT é a quantidade total de tempo, entre a Primeira Pintura com Conteúdo e o Tempo para Interatividade, em que a thread principal ficou bloqueada por tempo suficiente para impedir a responsividade à entrada. Ele soma a porção de bloqueio (duração − 50 ms) de cada tarefa longa (qualquer tarefa da thread principal acima de 50 ms). É uma métrica de laboratório — o maior peso individual (30%) na pontuação do Lighthouse 10 e o proxy de laboratório para INP — mas não é um Core Web Vital e nunca aparece no CrUX ou no Search Console. Limites para celular: bom ≤200 ms, ruim >600 ms. Corrija como você corrigiria o INP: divida tarefas JS longas, faça code-splitting, adie/remova JS não utilizado, domine scripts de terceiros. Minha opinião honesta: corrija para os usuários, não para um aumento de ranqueamento.

O que o TBT realmente mede

A definição do Google é o lugar para começar. TBT é “a quantidade total de tempo após a Primeira Pintura com Conteúdo (FCP) em que a thread principal ficou bloqueada por tempo suficiente para impedir a responsividade à entrada.” A thread principal do navegador processa uma tarefa por vez; enquanto está ocupada com um longo bloco de trabalho, ela não consegue reagir a um clique, um toque ou um pressionamento de tecla. O TBT quantifica quanto da sua janela de carregamento de página é gasta nesse estado bloqueado.

Duas definições fazem todo o trabalho aqui:

• Uma tarefa longa é “uma tarefa que executa na thread principal por mais de 50 milissegundos.”
• A porção de bloqueio de uma tarefa é sua duração menos 50 ms. Tarefas com 50 ms ou menos contribuem exatamente 0 ms.

O TBT é a soma dessas porções de bloqueio entre o FCP e o Time to Interactive (TTI). Então, o First Contentful Paint é a linha de partida: nada antes da primeira pintura conta, porque ainda não há nada na tela com o qual interagir.

O exemplo prático

A própria tabela do Google é a ilustração mais clara. Imagine cinco tarefas executadas na thread principal entre o FCP e o TTI:

As tarefas três e quatro estão abaixo da linha de 50 ms, então não contribuem em nada. A tarefa um bloqueia por 250 − 50 = 200 ms, a tarefa cinco por 155 − 50 = 105 ms. Some as porções de bloqueio — 200 + 40 + 0 + 0 + 105 — e você obtém 345 ms de TBT. Isso é uma pontuação de “precisa de melhorias”, impulsionada quase inteiramente por duas tarefas pesadas.

Esta é a parte contraintuitiva que vale a pena internalizar: “Um pequeno número de tarefas na thread principal não significa necessariamente baixo tempo de bloqueio. Por outro lado, um grande número de tarefas não leva necessariamente a muito tempo de bloqueio.” (Essa formulação é da NitroPack, reproduzida aqui — reverificada contra a fonte ao vivo em 2026-07-18.) O que importa é se tarefas individuais cruzam os 50 ms, não quantas tarefas existem.

A janela de medição: FCP a TTI

A janela termina no Time to Interactive — “o tempo desde quando a página começa a carregar até quando seus principais sub-recursos foram carregados e ela é capaz de responder de forma confiável e rápida à entrada do usuário.” No Lighthouse, o TTI é encontrado procurando adiante por uma “janela silenciosa” de cinco segundos sem tarefas longas e com no máximo duas requisições de rede em andamento.

Vale notar: o próprio TTI foi removido do Lighthouse 10 porque se mostrou excessivamente sensível a requisições de rede atípicas e tarefas longas, produzindo alta variabilidade. O TBT sobreviveu e se tornou a métrica principal de interatividade. Como Philip Walton disse, “Métricas novas e alternativas, como Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Interaction to Next Paint (INP), geralmente são métricas melhores para usar no lugar do TTI.” O TBT não substituiu o TTI como ponto final da janela — é um número único melhor para o mesmo problema subjacente. E o desaparecimento do TTI da interface do relatório do Lighthouse não é a mesma afirmação de que o TTI não delimita mais a janela de navegação padrão do Lighthouse — a janela em si ainda é medida dessa forma nos bastidores.

Mais uma nota de escopo: “FCP a TTI” descreve especificamente a auditoria de navegação padrão do Lighthouse. Outras ferramentas, ou o próprio Lighthouse executando um trace de período em vez de uma navegação completa de carregamento de página, podem totalizar uma janela de medição diferente — a matemática de tarefa longa de 50 ms não muda, mas os pontos de início e fim do que é somado são específicos da ferramenta e do modo de trace, não uma lei universal da métrica.

O TBT é um Core Web Vital? Não.

Este é o equívoco mais comum, então vamos ser diretos. Os três Core Web Vitals são LCP, INP e CLS. O TBT não é um deles. As próprias palavras do Google: “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.” (tradução) «O Total Blocking Time (TBT) é uma métrica de laboratório vital para capturar e diagnosticar possíveis problemas de interatividade que podem impactar o INP. No entanto, ele não faz parte do conjunto de Core Web Vitals porque não são mensuráveis em campo, nem refletem um resultado centrado no usuário.» (A gramática nessa frase é deles, não minha.)

Então, onde o TBT aparece e onde não aparece?

• Onde você vê: Lighthouse, PageSpeed Insights na aba de laboratório e no Chrome DevTools — todos ambientes simulados/de laboratório.
• Onde você não vê: no relatório Core Web Vitals do Google Search Console, no CrUX ou em qualquer dado de campo. Esses só trazem LCP, INP e CLS.

Se alguém disser que está “observando o TBT no Search Console”, está enganado — o GSC relata dados de campo, e o TBT não é uma métrica de campo.

Uma correção que vale a pena ser precisa: o TBT ser recomendado para laboratório não é o mesmo que o TBT ser impossível no campo. Você pode tecnicamente calcular um total no estilo TBT no campo com a Long Tasks API — o Google diz isso diretamente: “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.” (tradução) «É possível medir o TBT no campo, mas não recomendamos isso, pois a interação do usuário pode afetar o TBT da sua página de maneiras que geram muita variação nos seus relatórios.» Isso é uma recomendação contra, não uma barreira técnica. O que é verdade sem exceção é mais restrito: o CrUX e o relatório Core Web Vitals do Search Console nunca trazem TBT, ponto final — esses pipelines só coletam LCP, INP e CLS.

TBT é o proxy de laboratório para INP

Veja por que o TBT existe. As ferramentas de laboratório carregam uma página em um ambiente simulado, sem usuário real, então elas não podem medir o Interaction to Next Paint — o INP precisa de cliques e toques reais. O TBT preenche essa lacuna: “the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” (tradução) «A métrica Total Blocking Time (TBT) é mensurável em laboratório e é um proxy para o INP.»

Os dois estão mecanicamente relacionados: “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.” (tradução) «Embora o INP e o TBT sejam calculados de forma diferente, ambos são reflexos de uma thread principal bloqueada durante o processo de inicialização. Quando a thread principal está bloqueada, o navegador atrasa a resposta às interações do usuário.» E, empiricamente, “A low TBT often correlates with a low Interaction to Next Paint (INP).” (tradução) «Um TBT baixo frequentemente se correlaciona com um Interaction to Next Paint (INP) baixo.»

Mas “proxy” não é “substituto”. O Google é explícito: “Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (tradução) «O Total Blocking Time (TBT) pode ser uma métrica proxy razoável para o INP, mas não é um substituto para o INP por si só.» Eles divergem de maneiras reais:

• TBT alto, INP bom. O TBT mede o bloqueio durante o carregamento. Se seus usuários não tentam interagir de fato durante essa janela bloqueada — eles esperam a página parecer pronta primeiro — o INP deles pode ser bom mesmo com um TBT feio.
• TBT bom, INP ruim. O INP também cobre handlers de eventos lentos e trabalho de renderização que disparam após o carregamento, além de coisas como o atraso de toque de 300 ms do navegador em páginas não otimizadas para mobile — nada disso o TBT vê.

Quando o laboratório e o campo discordam, confie no campo. O INP (o número do usuário real) tem prioridade sobre o TBT (a estimativa de laboratório).

Uma nota histórica que confunde as pessoas: o TBT costumava ser o proxy de laboratório para o First Input Delay (FID). O INP substituiu o FID como Core Web Vital em 12 de março de 2024, então o TBT agora é o proxy do INP. O mecanismo subjacente nunca mudou — sempre foi sobre uma thread principal bloqueada durante o carregamento — mas qualquer artigo mais antigo que chame o TBT de “proxy do FID” é anterior a essa mudança.

Por que o TBT domina a pontuação do Lighthouse

O TBT carrega o maior peso individual na pontuação de Performance do Lighthouse — 30%, um peso introduzido no Lighthouse 10 e, verificado ao vivo contra os docs de pontuação do Chrome em 18/07/2026, ainda inalterado até o atual Lighthouse 13:

Trate essa tabela como específica de versão e data, não como uma constante permanente — o Lighthouse já mudou seus pesos antes e pode mudar de novo. Verifique novamente contra a pontuação de performance do Lighthouse antes de citá-la em um deck de auditoria.

Esta é a razão prática pela qual o TBT importa para auditorias de SEO, mesmo não sendo um sinal de ranqueamento: um TBT ruim tem um efeito desproporcional naquele grande número do Lighthouse que todo mundo captura de tela. O exemplo prático de Addy Osmani torna isso concreto — remover um polyfill de Intersection Observer reduziu o TBT de 400 ms para 300 ms e elevou a pontuação de Performance do Lighthouse de 63 para 70. Uma correção, sete pontos, por causa do peso de 30%.

Mais uma nuance: o limite de categoria “Bom ≤200 ms” e a pontuação do Lighthouse são escalas diferentes. Para pontuar 90+ no subscore de TBT, você precisa de aproximadamente ≤300 ms em mobile, e para atingir 100, precisa de ≤100 ms. (Esses valores de subscore são a documentação da curva de pontuação do DebugBear, reverificada na fonte ao vivo em 2026-07-18.) “Bom” e “100” não são a mesma métrica.

O TBT afeta o ranqueamento no SEO?

Não diretamente — e serei mais direto sobre isso do que a maioria.

O TBT não é um sinal de ranqueamento. O input de ranqueamento de interatividade do Google é o INP, uma métrica de campo. O TBT é um diagnóstico que ajuda você a encontrar e corrigir as tarefas longas que prejudicam o INP. Melhorar o TBT pode melhorar o INP, o que talvez ajude marginalmente o lado de Page Experience no ranqueamento — mas isso está a dois elos de “pode” de distância das suas posições.

E aqui está minha posição real sobre toda a questão dos Core Web Vitals, que já escrevi antes no meu guia de velocidade de página: não acho que os Core Web Vitals tenham muito impacto no SEO e, a menos que você seja extremamente lento, geralmente não os priorizo. Faça isso pelos usuários e pelas conversões, não por um aumento no ranqueamento. Isso se aplica em dobro ao TBT, que é um proxy de laboratório para uma métrica de campo para um pequeno input de ranqueamento. Corrija porque uma página congelada faz você perder clientes — não porque está perseguindo uma posição.

O que causa TBT alto

Quase sempre é JavaScript:

• Carregamento, análise ou execução de JavaScript desnecessários — nas próprias palavras da auditoria do Lighthouse. Enviar um bundle grande que a página não precisa no carregamento é a causa clássica.
• Declarações de JavaScript ineficientes — trabalho síncrono pesado que monopoliza a thread principal.
• Scripts de terceiros — gerenciadores de tags, widgets de chat, analytics, scripts de anúncios. Frequentemente o maior contribuinte individual, e o que você menos controla.
• Bootstrap pesado de framework — a hidratação do React e similares podem executar tarefas longas durante a inicialização.
• Recálculo de estilo/layout e coleta de lixo — layout síncrono forçado, recálculos grandes de estilo e pausas de GC aparecem como tarefas da thread principal também; não presuma que toda tarefa longa no trace seja execução de JavaScript.

Também não presuma que o tamanho de transferência do bundle é a história completa. A atribuição de trace tem lacunas reais: frames de origem cruzada e threads de worker têm limites de privacidade e segurança sobre o que um observador de tarefas longas pode relatar sobre eles (veja Solução de problemas), então uma tarefa não atribuída no seu trace não é prova de que nenhum terceiro está envolvido — pode apenas significar que a API de atribuição não tem permissão para informar você.

Como corrigir TBT alto

As correções são da mesma família das correções de INP — ambas se resumem a uma thread principal bloqueada.

1. Encontre as tarefas longas. Abra o painel Performance do Chrome DevTools e procure por tarefas acima de 50 ms (elas são marcadas com cantos vermelhos), ou execute a auditoria “Avoid long main-thread tasks” do Lighthouse.
2. Audite scripts de terceiros primeiro. Eles geralmente são as vitórias mais fáceis. Use as abas Coverage e Network do DevTools para ver o custo de cada script e carregue com lazy-load embeds pesados (YouTube, mapas, chat) atrás de uma fachada.
3. Divida as tarefas longas. Ceda à thread principal para que o navegador possa lidar com entrada entre os blocos — “quando as tarefas são divididas, o navegador pode responder a trabalho de maior prioridade muito mais cedo—incluindo interações do usuário.” A API moderna é scheduler.yield(), com um fallback de setTimeout(resolve, 0) (veja a aba Cheat Sheets para o padrão). Observe que o Google não recomenda mais isInputPending() — ceda independentemente de haver entrada pendente.
4. Reduza o JavaScript. Faça code-split de bundles grandes para que menos seja analisado e avaliado no carregamento, remova JS não utilizado (a aba Coverage do DevTools mostra o que), e use defer em scripts não críticos.
5. Mova computação pesada para fora da thread principal. Web Workers executam trabalho intensivo de CPU em uma thread separada, deixando a thread principal livre para responder.

Um efeito colateral útil: tarefas longas que bloqueiam a thread principal também podem atrasar Largest Contentful Paint rendering, então corrigir o TBT às vezes também melhora o LCP — especialmente quando há JS que bloqueia a renderização envolvido.

Onde ir a seguir

O TBT vive na família Core Web Vitals junto com seu equivalente de campo Interaction to Next Paint, as métricas de carregamento Largest Contentful Paint e First Contentful Paint, e as ferramentas de laboratório Lighthouse, PageSpeed Insights e Speed Index que as reportam. Se você lembrar apenas de uma coisa: o TBT é a luz de aviso de laboratório para a responsividade de campo — persiga as tarefas longas, não o número.

Resumo de IA

Uma visão condensada da versão Avançada:

• TBT = tempo de bloqueio da thread principal durante o carregamento. É o tempo total, entre FCP e TTI, em que a thread principal ficou bloqueada por tempo suficiente para impedir a responsividade à entrada.
• A matemática: soma da porção de bloqueio (duration − 50 ms, ou duração menos 50 ms) de cada tarefa longa (qualquer tarefa da thread principal acima de 50 ms). Tarefas ≤50 ms adicionam 0 ms. O exemplo do Google: tarefas de 250/90/35/30/155 ms → 345 ms de TBT.
• É uma métrica de laboratório. Você a vê no Lighthouse, na aba de laboratório do PageSpeed Insights e no DevTools — nunca no CrUX ou no Search Console.
• Não é um Core Web Vital. Os três CWV são LCP, INP e CLS. O TBT é o proxy de laboratório para o INP (historicamente, proxy do FID; o INP substituiu o FID em 12 de março de 2024).
• Maior peso no Lighthouse: 30% — o maior de todos, então um TBT ruim derruba a pontuação geral. Limites para mobile: bom ≤200 ms, precisa de melhorias ≤600 ms, ruim

  600 ms.

• Ranqueamento: não é um fator de ranqueamento direto. O INP é o sinal de campo; o TBT apenas ajuda a diagnosticá-lo. A opinião do Patrick: corrija-o para os usuários e conversões, não para um aumento de ranqueamento.
• Correções (mesma família do INP): encontre tarefas longas no DevTools, audite scripts de terceiros primeiro, divida tarefas com scheduler.yield(), faça code-split e remova JS não utilizado, transfira trabalhos pesados para Web Workers.
• Ressalva: TBT e INP podem divergir — TBT alto com INP bom (usuários não interagem durante o carregamento) ou TBT bom com INP ruim (handlers de eventos lentos após o carregamento). Dados de campo vencem.
• “Somente laboratório” significa recomendado para laboratório, não impossível no laboratório. Você pode tecnicamente calcular um total estilo TBT a partir de dados de campo com a Long Tasks API, mas o Google desaconselha (variação excessiva de execução para execução) — CrUX e Search Console simplesmente nunca o carregam de qualquer forma.
• A atribuição de rastreamento tem lacunas reais. Frames de origem cruzada e threads de worker têm limites de privacidade/segurança sobre o que um observador de tarefas longas pode relatar, então uma tarefa não atribuída significa “causa desconhecida”, não “nenhum terceiro envolvido”.

Documentação oficial

Documentação de fonte primária sobre TBT do Google e da equipe do Chrome.

web.dev / Chrome

• Total Blocking Time (TBT) — Philip Walton & Barry Pollard: a definição canônica, a regra de tarefa longa de 50 ms e o exemplo prático.
• Auditoria de TBT no Lighthouse — a página da auditoria, com os limites de pontuação para mobile/desktop e causas citadas.
• Pontuação de desempenho do Lighthouse — os pesos das métricas, de onde vêm os 30% do TBT.
• Web Vitals — por que o TBT não é um Core Web Vital e como ele se relaciona com o conjunto.
• Interaction to Next Paint (INP) — a métrica de campo que o TBT representa, e a ressalva de “proxy, não substituto”.
• Otimizar tarefas longas — Jeremy Wagner & Brendan Kenny sobre dividir tarefas, scheduler.yield() e por que isInputPending() não é mais recomendado.
• Time to Interactive (TTI) — a métrica que define o fim da janela de TBT e por que foi removida do Lighthouse 10.
• Diferenças entre dados de laboratório e de campo — os limites do TBT como substituto do INP.

Citações da fonte

Declarações registradas da documentação do Google. Cada link é um link profundo que salta para a passagem citada.

Definição e mecânica

• “the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness.” (tradução) «a quantidade total de tempo após a Primeira Pintura com Conteúdo (FCP) em que o thread principal ficou bloqueado por tempo suficiente para impedir a responsividade à entrada.» — web.dev, Total Blocking Time. Ir para a citação
• “a task that runs on the main thread for more than 50 milliseconds” (tradução) «uma tarefa que é executada no thread principal por mais de 50 milissegundos» — a definição de uma tarefa longa. Ir para a citação
• “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.” (tradução) «Para proporcionar uma boa experiência ao usuário, os sites devem se esforçar para ter um Tempo Total de Bloqueio inferior a 200 milissegundos quando testados em hardware móvel médio.» Ir para a citação
• “A low TBT often correlates with a low Interaction to Next Paint (INP).” (tradução) «Um TBT baixo frequentemente se correlaciona com uma Interação com a Próxima Pintura (INP) baixa.» Ir para a citação

Status: não é um 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.” (tradução) «O Tempo Total de Bloqueio (TBT) é uma métrica de laboratório que é vital para detectar e diagnosticar possíveis problemas de interatividade que podem impactar o INP. No entanto, ele não faz parte do conjunto de Core Web Vitals porque não são mensuráveis em campo, nem refletem um resultado centrado no usuário.» — web.dev, Web Vitals (Philip Walton). (A gramática é verbatim da fonte.) Ir para a citação

TBT como proxy do 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.” (tradução) «Nesses casos, o Tempo Total de Bloqueio (TBT) pode ser uma métrica proxy razoável para o INP, mas não é um substituto para o INP em si.» — web.dev, Interaction to Next Paint. Ir para a citação

Tarefas longas e como corrigi-las

• “The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.” (tradução) «O thread principal só pode processar uma tarefa por vez. Qualquer tarefa que demore mais de 50 milissegundos é uma tarefa longa.» — web.dev, Optimize long tasks. Ir para a citação
• “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” (tradução) «Quando as tarefas são divididas, o navegador pode responder a trabalhos de prioridade mais alta muito mais cedo—incluindo interações do usuário.» Ir para a citação
• On isInputPending(): “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” (tradução) «Não recomendamos mais o uso desta API e, em vez disso, recomendamos ceder independentemente de haver entrada pendente ou não.» Ir para a citação

TTI e por que o TBT o substituiu como o principal número de interatividade

• “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.” (tradução) «Métricas mais novas e alternativas, como a Maior Pintura com Conteúdo (LCP), o Tempo Total de Bloqueio (TBT) e a Interação com a Próxima Pintura (INP), geralmente são métricas melhores para usar no lugar do TTI.» — web.dev, Time to Interactive (Philip Walton). Ir para a citação

Lista de verificação de triagem do TBT

Uma passagem rápida quando o Lighthouse lhe entrega um Tempo Total de Bloqueio vermelho (ou laranja):

• Confirme que você está lendo dados de lab — TBT está no Lighthouse / PageSpeed Insights na aba lab / DevTools, não no campo ou no Search Console.
• Abra o painel Performance do DevTools e encontre as tarefas longas (acima de 50 ms, com canto vermelho) entre a primeira pintura e o interativo.
• Liste seus scripts de terceiros e o custo de cada um (abas Coverage + Network) — comece por aqui; geralmente é a maior e mais fácil vitória.
• Carregue embeds pesados (YouTube, mapas, chat) de forma preguiçosa atrás de uma fachada.
• Execute as auditorias do Lighthouse “Evite tarefas longas na thread principal” e “Reduza JavaScript não utilizado” e trabalhe a lista.
• Divida o código de bundles grandes para que menos JS seja analisado/executado no carregamento.
• Adie scripts não críticos; use import() dinâmico para o que não é necessário imediatamente.
• Divida as tarefas longas restantes com scheduler.yield() (fallback para setTimeout). Não use isInputPending().
• Mova cálculos pesados de CPU para um Web Worker.
• Verifique o campo: extraia INP do CrUX / monitoramento de usuário real. Se o INP estiver ok, não invista demais em perseguir o número de lab.

Folha de dicas do TBT

A matemática, em uma linha

TBT = Σ (taskDuration − 50 ms) para cada tarefa > 50 ms entre FCP e TTI. Tarefas ≤ 50 ms contribuem com 0 ms.

Exemplo prático (do Google)

Limites do Lighthouse

(Os limites diferem da curva de subscore do Lighthouse: 90+ ≈ ≤300 ms no mobile, 100 ≈ ≤100 ms no mobile — números documentados do DebugBear, reverificados ao vivo em 2026-07-18.)

TBT vs. INP — a folha de dicas

Padrão yield-to-main (a correção)

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

Use scheduler.yield() onde disponível, com fallback para setTimeout. Não use isInputPending() — o Google agora recomenda ceder independentemente de haver entrada pendente.

Ferramentas para medir e corrigir o TBT

• PageSpeed Insights — leia o TBT na seção lab data (não está na seção de field data, porque o TBT não é uma métrica de campo).
• Lighthouse (Chrome DevTools → painel Lighthouse, ou a CLI) — a fonte do número de TBT e das auditorias “Avoid long main-thread tasks” / “Reduce unused JavaScript”.
• Chrome DevTools — painel Performance — grave um carregamento e encontre as long tasks (acima de 50 ms, sinalizadas com cantos vermelhos) que compõem o seu TBT.
• Chrome DevTools — aba Coverage — veja quanto de cada script é realmente usado, para mirar JavaScript não utilizado e terceiros pesados.
• WebPageTest — testes de laboratório com detalhamentos de main-thread e CPU.
• Long Animation Frames (LoAF) API — um complemento moderno, do lado de campo, para o TBT, não um substituto para o cálculo da janela de carregamento em laboratório: ele atribui long animation frames ao longo de uma visita inteira, o que é mais próximo de como os problemas de INP realmente aparecem, em vez da janela única de carregamento de FCP a TTI do TBT.
• TBT do lado de campo via Long Tasks API — tecnicamente possível (some duration − 50 ms, ou duração menos 50 ms, para long tasks observadas em produção, igual ao snippet da aba Scripts), mas o Google recomenda contra isso para RUM: o tempo real de interação do usuário torna o número variável demais para comparar execução após execução. Prefira INP ou LoAF para responsividade de campo.
• Onde você não vai encontrar: o relatório Core Web Vitals do Google Search Console e o CrUX trazem apenas LCP, INP e CLS — nunca TBT, independentemente do que seja tecnicamente possível calcular por conta própria.

Erros de TBT que produzem a correção errada

• Chamar o TBT de Core Web Vital. O TBT é um diagnóstico de laboratório e um proxy útil para contenção da main-thread; o INP é o Core Web Vital de usuários reais. Relate-os separadamente.
• Contar a long task inteira como tempo de bloqueio. Apenas a parte além de 50 milissegundos conta. Uma tarefa de 70 milissegundos contribui com 20 milissegundos, não 70.
• Otimizar fora da janela de medição. O TBT do Lighthouse soma o bloqueio entre FCP e TTI. Trabalho antes ou depois dessa janela pode importar para os usuários, mas não faz parte desse valor de TBT.
• Remover código de primeira parte enquanto ignora o maior terceiro. Use o trace e os iniciadores de requisição para atribuir long tasks antes de escolher um responsável ou correção.
• Dividir código sem reduzir trabalho. Muitas tarefas menores podem melhorar a responsividade, mas enviar o mesmo JavaScript desnecessário ainda custa parsing, compilação e execução. Remova trabalho não utilizado além de ceder a execução.
• Presumir que um bom TBT de laboratório prova um bom INP de campo. Usuários reais interagem após o carregamento em dispositivos variados. Confirme o resultado com dados de responsividade de campo.

TBT alto, mas a rede parece rápida

Sintoma: Os recursos baixam rapidamente, mas o Lighthouse relata bloqueio pesado.

Causa provável: Parsing, compilação, execução, hidratação ou trabalho de terceiros de JavaScript monopoliza a main-thread depois que os bytes chegam.

Correção e confirmação: Grave um trace de Performance, ordene as long tasks por duração e proprietário, depois remova código não utilizado, adie trabalho não crítico ou divida a maior tarefa. Confirme que a parte de bloqueio cai em execuções correspondentes repetidas.

Um bundle grande é adiado, mas o TBT continua alto

Sintoma: Adicionar defer muda a ordem de download/execução sem mover materialmente o TBT.

Causa provável: O mesmo código caro ainda executa dentro da janela de FCP a TTI.

Correção e confirmação: Perfile funções dentro da long task. Faça code-split por rota ou interação, reduza a hidratação ou remova trabalho não utilizado/duplicado; depois verifique que o tempo de execução, não apenas o horário de início da requisição, diminui.

Lighthouse TBT bom enquanto o INP de campo é ruim

Sintoma: Testes de laboratório de navegação parecem responsivos, mas CrUX ou RUM relatam interações lentas.

Causa provável: A tarefa problemática ocorre após o carregamento inicial ou apenas após uma interação real que a navegação padrão do Lighthouse não exercita.

Correção e confirmação: Colete rastros de interação para as páginas com INP ruim e dispositivos, reproduza a ação localmente e otimize o tratamento de eventos e a próxima pintura.

Uma tarefa longa aparece sem dono claro

Sintoma: O DevTools ou um observador da Long Tasks API sinaliza uma tarefa bloqueante, mas a atribuição está em branco, genérica ou rotulada como “desconhecida” / “cross-origin”.

Causa provável: Esta é uma lacuna de cobertura conhecida, não um erro de medição. A própria especificação da Long Tasks API limita o que ela relata entre contextos de execução — tarefas de ancestrais cross-origin não são relatadas deliberadamente (“this is not reported because of security” (tradução) «isso não é informado por motivos de segurança»), e um iframe cross-origin profundamente incorporado “does not receive any information” (tradução) «não recebe nenhuma informação» sobre uma tarefa longa em um ancestral cross-origin. Trabalho em um Web Worker ou na thread do compositor do navegador também pode ficar fora do que as superfícies de atribuição mostram.

Correção e confirmação: Não conclua “nenhum terceiro está envolvido” apenas porque nada é nomeado. Verifique com a coluna de iniciador do painel Network, a aba Coverage e (onde você controla o script) instrumentação de primeira parte dentro de iframes que você possui. Trate uma tarefa não atribuída como “causa desconhecida”, não como “causa ausente”.

TBT varia muito entre execuções

Sintoma: Uma execução está verde e a próxima está ruim sem implantação.

Causa provável: Execução variável de terceiros, tempo de servidor que altera a janela de trabalho, estado de cache ou contenção da máquina de teste.

Correção e confirmação: Combine as configurações, execute vários testes a frio e compare os donos de tarefas longas e o resultado mediano em vez de selecionar uma pontuação.

Transforme um rastro em um plano de propriedade

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.

Compare dois rastros de desempenho

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.

Revise uma decisão de script de terceiros

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.

Observe tarefas longas durante uma reprodução

Execute isso no início do Console do DevTools, reproduza a carga ou interação e inspecione a parte bloqueante de cada tarefa:

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 });

Este é um total de depuração para o período que você observa, não o TBT oficial do Lighthouse, a menos que você reproduza deliberadamente a mesma janela de FCP a TTI e as mesmas condições de teste.

Sinalize scripts com o maior tempo de avaliação na thread principal

Após gravar um rastro de desempenho no DevTools, use a visão Bottom-up agrupada por URL. Para um inventário rápido de rede ao lado, este snippet de Console lista o JavaScript transferido do maior para o menor:

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);

O tamanho grande de transferência é apenas uma pista; o rastro de desempenho é o que atribui o tempo de análise e execução ao TBT.

Redução de tarefas longas

Teste a executar: Capture vários rastros de Lighthouse/desempenho correspondentes antes e depois da mudança de JavaScript e compare tarefas longas entre FCP e TTI.

Resultado esperado: A tarefa alvo desaparece, encurta ou se divide em tarefas menores, e o TBT mediano melhora sem atrasar o FCP ou quebrar a funcionalidade.

Interpretação de falha: O trabalho foi movido para outro bundle/tarefa, ainda executa na mesma janela, ou a variação normal da execução é maior que a mudança.

Janela de monitoramento: Teste imediatamente em perfis de laboratório móvel e desktop e observe o INP de campo durante a próxima janela de relatório.

Gatilho de reversão: Reverta se interações críticas quebrarem, erros aumentarem ou uma regressão repetível de FCP/LCP/INP superar a melhoria do TBT.

Adiamento de terceiros

Teste a executar: Compare um rastro a frio com o terceiro em sua posição atual e com ele atrasado até consentimento, tempo ocioso ou a interação relevante.

Resultado esperado: Suas tarefas longas saem da janela inicial de TBT enquanto o evento de negócio necessário ainda dispara no momento pretendido.

Interpretação de falha: Outro carregador o injeta cedo, código dependente bloqueia a página, ou o trabalho na thread principal do script não é o gargalo medido.

Janela de monitoramento: Valide em todos os modelos que carregam o script e monitore tanto o desempenho quanto o evento de negócio após o lançamento.

Gatilho de reversão: Restaure o caminho de carregamento anterior se consentimento, análise, checkout, anúncios ou outra função necessária perder eventos válidos.

Acompanhamento de responsividade de campo

Teste a executar: Segmentar o campo INP para modelos/dispositivos afetados após a mudança de TBT em laboratório, mantendo a data de implantação anotada.

Resultado esperado: A responsividade do campo permanece estável ou melhora; uma vitória apenas em laboratório não é relatada como resultado para o usuário até que evidências de campo a sustentem.

Interpretação de falha: O trabalho real de interação ocorre fora da carga inicial ou a coorte otimizada é pequena demais para mover o agregado.

Janela de monitoramento: Revise durante toda a janela de relatório de dados de campo e durante interações de alto valor.

Gatilho de reversão: Investigue ou reverta se o INP de campo ou o sucesso de interações críticas regredir consistentemente após o lançamento.

Teste-se: Tempo Total de Bloqueio

Cinco perguntas rápidas sobre matemática e diagnóstico de TBT. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Oficial

• Total Blocking Time (TBT) — a definição canônica e o exemplo prático.
• Otimize tarefas longas — o guia prático de correção (scheduler.yield(), agrupamento, por que não isInputPending()).
• Web Vitals — onde o TBT se posiciona em relação aos Core Web Vitals.
• Otimizando Web Vitals usando Lighthouse — Addy Osmani; inclui o exemplo prático de remoção de polyfill (TBT 400→300 ms, pontuação 63→70).

De outros (verifique antes de citar)

• DebugBear — Total Blocking Time — profundidade técnica forte sobre o mecanismo TBT↔INP e a curva de pontuação do Lighthouse.
• NitroPack — O que é Total Blocking Time? — a percepção de “contagem de tarefas ≠ tempo de bloqueio”.
• BrowserStack — Guia de TBT e Catchpoint — TBT — visões gerais orientadas a ferramentas/monitoramento.
• web.dev — Métricas de desempenho centradas no usuário — a estrutura de Philip Walton classificando o TBT como uma métrica de laboratório/responsividade de carga versus métricas de campo; enquadramento útil para explicar por que o TBT não aparece no CrUX.
• web.dev — Começando a medir Web Vitals — aborda como o TBT serve como proxy de laboratório para o INP quando a medição de usuários reais não é possível em ambientes simulados.
• WebPageTest — ferramenta gratuita de teste em laboratório que relata o TBT junto com análises detalhadas da thread principal e da CPU; útil para diagnosticar quais tarefas estão elevando uma pontuação alta.
• Search Engine Journal — Cobertura de Core Web Vitals — relatórios contínuos do setor sobre atualizações de CWV, o papel do TBT em auditorias e como os profissionais interpretam as lacunas entre laboratório e campo.

Estatísticas que valem citar

• O TBT é 30% da pontuação de desempenho do Lighthouse — o maior peso individual de qualquer métrica (LCP e CLS são 25% cada; FCP e Speed Index 10% cada). Introduzido no Lighthouse 10, verificado novamente ao vivo em 18/07/2026 como inalterado até o Lighthouse 13. Fonte
• A barra “bom” é ≤200 ms no celular (≤150 ms no desktop); “ruim” é >600 ms no celular (>350 ms no desktop) — documentos de auditoria do Lighthouse. Fonte
• Um polyfill = sete pontos. Remover um único polyfill de Intersection Observer reduziu o TBT de 400 ms para 300 ms e elevou a pontuação de desempenho do Lighthouse de 63 para 70 — uma ilustração clara do peso de 30%. Fonte
• Uma tarefa de 250 ms contribui com 200 ms de tempo de bloqueio — a parte de bloqueio é sempre duration − 50 ms (duração menos 50 ms). O exemplo prático do Google totaliza 345 ms em cinco tarefas. Fonte

Registro de alterações