# Como corrigir TBT alto e JavaScript bloqueante no WordPress

TBT alto no WordPress é quando o Total Blocking Time, a soma do tempo em que a thread principal fica bloqueada por JavaScript entre o primeiro render e a interatividade, passa de 200ms no laboratório. Costuma vir de scripts pesados, plugins que carregam JS no carregamento inicial e código de terceiros como rastreadores.

## O que é o TBT alto no WordPress?

O TBT alto no WordPress é uma métrica de laboratório do PageSpeed que mede quanto tempo a thread principal do navegador fica ocupada executando JavaScript e não consegue responder ao usuário. O Total Blocking Time soma os trechos acima de 50ms de cada tarefa longa entre o First Contentful Paint e o momento em que a página fica interativa. A meta no laboratório é abaixo de 200ms; entre 200ms e 600ms o status é "precisa melhorar" e acima de 600ms é considerado ruim. Um TBT alto é o principal proxy de laboratório para o INP de campo, e quase sempre aponta para JavaScript demais executando cedo.

## Como identificar

- "TBT acima de 200ms" no relatório de performance do PageSpeed Insights, em amarelo ou vermelho.
- O diagnóstico "Minimize main-thread work" aparece com vários segundos no PageSpeed Insights.
- O diagnóstico "Reduce JavaScript execution time" lista scripts custosos no Lighthouse.
- A página parece carregada, mas não responde a cliques ou rolagem por alguns instantes.

## Como prevenir

- Mantenha o adiamento do JavaScript ativo e limite scripts de terceiros ao mínimo necessário
- Carregue widgets pesados (chat, mapa, vídeo) sob demanda, na interação do usuário
- Audite o impacto de cada plugin no JavaScript antes de instalar e remova os que enfileiram scripts sem uso

Erros relacionados

- [Como corrigir Eliminate render-blocking resources](https://full.services/wp-fixer/corrigir-render-blocking-resources-wordpress/)
- [Como corrigir INP alto (Interaction to Next Paint) no WordPress](https://full.services/wp-fixer/corrigir-inp-alto-wordpress/)
- [Como corrigir LCP alto no WordPress (Core Web Vitals)](https://full.services/wp-fixer/corrigir-lcp-alto-wordpress/)

## Causa

- Plugins que enfileiram arquivos JavaScript grandes no carregamento inicial de todas as páginas, mesmo onde não são usados.
- Scripts de terceiros (Google Tag Manager, pixels de anúncios, chats e mapas) executando na thread principal antes da interatividade.
- Page builders e sliders que carregam bibliotecas JavaScript completas para renderizar componentes simples.
- Falta de adiamento (defer) e de carregamento sob demanda, fazendo todo o JavaScript bloquear a thread de uma vez.
- Tema que combina muitos scripts num único arquivo enorme, criando uma tarefa longa que segura a thread.

## Como resolver

1. Identifique os scripts mais custosos: rode o PageSpeed Insights e abra os diagnósticos "Reduzir o tempo de execução do JavaScript" e "Minimizar o trabalho da thread principal" para ver quais arquivos consomem mais tempo de CPU.
2. Adie o JavaScript não crítico: no plugin de performance, ative o adiamento (defer) do JavaScript para que os scripts só executem depois que o HTML for analisado, liberando a thread durante o render inicial.
3. Carregue scripts de terceiros sob demanda: atrase chats, mapas e widgets de redes sociais para carregar na interação do usuário, e mova o Tag Manager para o final ou para um web worker, tirando-os da execução inicial.
4. Remova plugins e scripts não usados por página: desative recursos que enfileiram JavaScript onde ele não é necessário e limite o carregamento de bibliotecas de slider e formulário às páginas que realmente as usam.
5. Divida e minifique os arquivos JavaScript: minifique o JavaScript e evite combinar tudo num único arquivo gigante; tarefas menores quebram a thread em pedaços e reduzem o tempo de bloqueio contínuo.
6. Meça de novo no PageSpeed: rode o teste outra vez e confirme se o TBT caiu de 200ms; acompanhe também o INP nos dados de campo, que refletem usuários reais.

## Código

```html
<!-- Adia o JS nao critico: so executa apos o HTML ser analisado -->
<script src="/wp-content/plugins/exemplo/app.js" defer></script>

<!-- Carrega o script de terceiros (chat/mapa) so na 1a interacao do usuario -->
<script>
  function carregaTerceiro() {
    var s = document.createElement('script');
    s.src = 'https://exemplo-terceiro.com/widget.js';
    document.body.appendChild(s);
    ['scroll','mousemove','touchstart','keydown'].forEach(function (ev) {
      window.removeEventListener(ev, carregaTerceiro);
    });
  }
  ['scroll','mousemove','touchstart','keydown'].forEach(function (ev) {
    window.addEventListener(ev, carregaTerceiro, { once: true, passive: true });
  });
</script>
```

## Perguntas frequentes

### Qual é o valor ideal de TBT no WordPress?

A meta no teste de laboratório do PageSpeed é TBT abaixo de 200 milissegundos. Entre 200ms e 600ms o status é "precisa melhorar" e acima de 600ms é considerado ruim, sinalizando JavaScript demais bloqueando a thread principal.

### Qual a diferença entre TBT e INP?

O TBT é uma métrica de laboratório que soma o tempo de bloqueio da thread durante o carregamento; o INP é uma métrica de campo que mede a resposta a interações reais ao longo da visita. O TBT é o melhor proxy de laboratório para prever um INP ruim.

### Adiar o JavaScript pode quebrar o site?

Pode, se um script depender de outro que ainda não executou ou esperar um evento já disparado. Por isso, ative o defer e teste o site (menus, sliders, formulários) antes de publicar, excluindo do adiamento os scripts que quebrarem.

### Scripts de terceiros contam para o TBT?

Sim, e costumam ser a maior fatia. Tag managers, pixels de anúncios, chats e mapas executam na thread principal e somam tempo de bloqueio. Carregá-los sob demanda, na interação do usuário, reduz bastante o TBT.

### Plugins de cache ajudam a baixar o TBT?

Ajudam quando trazem recursos de otimização de JavaScript, como adiar, minificar e atrasar scripts de terceiros. Mas configure com cuidado, porque adiar scripts essenciais sem testar pode combinar mal e quebrar funcionalidades.

### Reduzi o TBT no laboratório mas o INP de campo continua ruim. Por quê?

Porque os dados de campo são uma média de 28 dias de usuários reais e demoram a refletir as mudanças. Além disso, o INP também sofre com handlers de evento lentos durante a navegação, que o TBT de carregamento não captura inteiramente.

**Fonte:** [web.dev — Total Blocking Time (TBT)](https://web.dev/articles/tbt)