Guias

O que é o Total Blocking Time (TBT)? A métrica mais pesada da pontuação Lighthouse

vuetelemetry
Guias
7 min de leitura

O TBT pesa 30 por cento da pontuação de desempenho do Lighthouse, mais do que qualquer outra métrica, e não é um Core Web Vital. O que conta, porque só se mede a parte de uma tarefa acima dos 50 ms, e porque dividir o JavaScript vale mais do que reduzi-lo.

O Total Blocking Time é a métrica com maior peso na pontuação de desempenho do Lighthouse, 30 por cento, à frente do LCP e do CLS com 25 cada. Ainda assim não é um Core Web Vital, e segurar estes dois factos ao mesmo tempo é precisamente a razão para o perceber bem.

O que mede não é quanto tempo a sua página demora a carregar. Mede quanto tempo o navegador esteve demasiado ocupado para lhe responder.

O que o TBT conta realmente

Carros parados para-choques contra para-choques com as luzes de travagem acesas. Um veículo que não avança segura tudo o que vem atrás, que é exatamente o que uma única tarefa longa faz à thread principal.

Durante o carregamento, o navegador executa o seu JavaScript na thread principal, a mesma que trata dos cliques e das teclas. Enquanto ali corre trabalho, nada mais pode acontecer. Uma tarefa que ocupa a thread principal mais de 50 milissegundos chama-se tarefa longa, e é a unidade com que o TBT é construído.

Aqui está a parte que surpreende. O TBT não conta a tarefa inteira, apenas a porção acima do limiar de 50 ms. Uma tarefa de 70 ms contribui com 20 ms. Uma de 45 ms não contribui com nada. O TBT é a soma dessas porções bloqueantes de cada tarefa longa entre o First Contentful Paint e o momento em que a página se torna interativa.

O limite de 50 ms não é arbitrário. É aproximadamente o ponto em que uma pessoa repara que a interface não respondeu de imediato, por isso a métrica conta o tempo em que a página esteve visivelmente inerte, e não o tempo que passou a trabalhar.

Porque pesa 30 por cento e ainda assim não é um Core Web Vital

O Lighthouse arruma o TBT em três faixas, medidas no seu dispositivo móvel simulado: bom com 200 ms ou menos, a melhorar entre 200 e 600 ms, e mau acima de 600 ms. Esses números pressupõem um telemóvel de gama média, deliberadamente mais lento do que a máquina a partir da qual está a testar.

Bom - 200 ms ou menos
A melhorar - entre 200 e 600 ms
Mau - acima de 600 ms

O TBT é uma métrica de laboratório. É medida numa execução controlada, com um perfil de dispositivo fixo e sem utilizador real, e é exatamente por isso que não é um Core Web Vital: os Core Web Vitals são métricas de campo recolhidas de visitas reais. O seu equivalente de campo é o Interaction to Next Paint, e os dois estão ligados sem serem a mesma coisa.

O TBT olha para a thread principal bloqueada durante o carregamento. O INP olha para o que aconteceu mesmo quando uma pessoa interagiu, em qualquer momento da visita. Uma página pode ter um TBT razoável e um INP mau porque o trabalho caro chega mais tarde, ao abrir um menu ou ao aplicar um filtro.

O que o piora

As causas são quase sempre JavaScript, normalmente numa de três formas. Um bundle grande tem de ser analisado, compilado e executado antes de qualquer outra coisa poder correr, e esse trabalho aterra na thread principal de uma só vez.

A hidratação do framework é a segunda fonte comum. O HTML gerado no servidor chega depressa, e depois o framework percorre a árvore de componentes para lhe agarrar o comportamento; numa página grande esse percurso é uma única tarefa longa exatamente no momento em que o utilizador é mais propenso a tentar clicar.

Os scripts de terceiros são a terceira, e a menos controlada. Gestores de etiquetas, analítica, widgets de conversa e banners de consentimento executam cada um o seu próprio trabalho na sua thread principal, num calendário que não é definido por si, e o seu custo quase nunca aparece no orçamento de bundle de ninguém.

Dividir vale mais do que reduzir

O instinto é reduzir o tamanho do bundle. Ajuda, mas não é a mesma alavanca, e isto é o mais útil que se pode saber sobre o TBT. A métrica conta o tempo acima dos 50 ms por tarefa, portanto a mesma quantidade de trabalho dividida em várias tarefas curtas pontua muito melhor do que uma só longa, com exatamente os mesmos bytes.

É por isso que devolver o controlo conta. Partir um ciclo pesado para que o navegador possa atender a entrada entre pedaços, mover o cálculo para um Web Worker onde não toca de todo na thread principal, e adiar os terceiros até a página estar utilizável reduzem todos o TBT sem retirar uma única linha de lógica.

- vuetelemetry

O laboratório e o campo não medem o mesmo

Uma ressalva honesta antes de otimizar para o número. Uma execução de laboratório usa um único perfil de dispositivo e nunca clica em nada, por isso o TBT pode parecer bom enquanto utilizadores reais com equipamento mais barato continuam à espera. Trate-o como um diagnóstico que lhe diz onde a thread principal está ocupada, e consulte os dados de campo para saber o que as pessoas viveram realmente.

Lidos em conjunto, os dois respondem a perguntas diferentes. O TBT diz-lhe que a página esteve bloqueada durante o carregamento, e aproximadamente quanto. O INP diz-lhe se isso importou a alguém.

FAQ

O que é um bom Total Blocking Time?

200 ms ou menos numa execução do Lighthouse, que usa um dispositivo móvel de gama média simulado. Entre 200 e 600 ms é a melhorar, e acima de 600 ms é mau. Como a execução é limitada de propósito, um valor medido no seu próprio portátil sem limitação não é comparável e parecerá quase sempre bastante melhor do que a realidade.

O Total Blocking Time é um Core Web Vital?

Não. Os Core Web Vitals são o Largest Contentful Paint, o Interaction to Next Paint e o Cumulative Layout Shift, e são recolhidos de visitas reais. O TBT é uma métrica de laboratório medida numa execução controlada, e é por isso que pode pesar 30 por cento da pontuação de desempenho do Lighthouse e ainda assim ficar fora do conjunto que toca o posicionamento.

Qual é a diferença entre TBT e INP?

O TBT mede o bloqueio da thread principal durante o carregamento, em laboratório, sem nenhum utilizador a interagir. O INP mede quanto tempo interações reais demoraram a produzir uma resposta visível, em qualquer momento da visita. Correlacionam-se, porque uma thread principal ocupada prejudica ambos, mas uma página pode pontuar bem no TBT e mal no INP quando o trabalho caro chega depois do carregamento.

Porque é que uma tarefa de 45 ms não conta nada?

Porque o TBT só conta a porção de uma tarefa acima dos 50 ms. Uma tarefa de 45 ms não é uma tarefa longa e contribui com zero; uma de 70 ms contribui com 20 ms. O limiar está aproximadamente onde uma pessoa começa a reparar que a interface não respondeu, por isso a métrica mede a inércia percetível e não o trabalho total.

Como reduzo o Total Blocking Time?

Divida o trabalho antes de tentar retirá-lo. A mesma quantidade de JavaScript repartida por tarefas curtas pontua muito melhor do que uma só tarefa longa: devolva o controlo ao navegador entre pedaços, mova o cálculo para um Web Worker e adie os scripts de terceiros até a página estar utilizável. Depois reduza o que envia: divisão de código, remoção de dependências não usadas e menor custo de hidratação em páginas grandes.