Widget de Chat com Core Web Vitals Perfeitos

Como carregar um widget de chat do jeito certo

Eu já disse isso várias e várias vezes. Alguns scripts são mais importantes do que outros. Ninguém na história da internet já se irritou por um widget de chat não ter carregado nos primeiros 500ms de carregamento da página. Aquele momento em que a página ainda está em branco.

Não faria nenhum sentido, certo, carregar um widget de chat antes que o conteúdo principal da página sequer tenha começado a carregar? Não, faria muito mais sentido carregar primeiro as partes mais importantes (seu logotipo, sua imagem principal, suas folhas de estilo, suas fontes, talvez alguns scripts super importantes que lidam com navegação e conversão).

Estudos mostram que apenas 3 a 10 por cento dos visitantes realmente usam um widget de chat durante a sua sessão. Adiar o script de chat não custa nada em termos de user experience, mas faz você ganhar tudo em termos de velocidade da página.

Infelizmente, não é assim que a maioria dos sites está fazendo as coisas. Diariamente, vejo scripts sem importância (como scripts de chat) carregarem com a prioridade mais alta imediatamente no início do carregamento da página.

Neste artigo, vou explicar como carregar corretamente um script de chat e como isso afeta métricas importantes como a Largest Contentful Paint e a Interaction to Next Paint.

Revisado pela última vez por Arjen Karel em fevereiro de 2026

Contexto: como funcionam os widgets de chat

Um widget de chat geralmente funciona carregando um pequeno script na sua página. Esse script vai carregar alguns estilos e injetar um iframe na sua página. Um iframe é uma pequena página da web isolada dentro de uma página da web. E esse iframe vai lidar com tudo que ele precisa para conversar com seus clientes.

Como os widgets de chat afetam as Core Web Vitals?

Os widgets de chat afetam as Core Web Vitals de algumas maneiras:

1. Eles afetam a First Contentful Paint e a Largest Contentful Paint competindo por recursos iniciais de rede.

2. Eles afetam a Interaction to Next Paint bloqueando a thread principal e, às vezes, atualizando lentamente após a interação.

3. Eles podem causar layout shifts quando não renderizam corretamente na página.

O impacto varia muito entre os provedores. Os widgets de chat mais pesados (Zendesk, Tawk.to) carregam de 500 a 750 KB de JavaScript. Alternativas mais leves como Zoho Desk e Crisp ficam abaixo de 155 KB. Em média, um widget de chat adiciona de 300 a 600 ms de tempo de bloqueio na thread principal. Isso é o suficiente para empurrar uma pontuação de INP que, de outra forma, passaria, para a faixa de "precisa melhorar".

Problemas de Largest Contentful Paint causados por widgets de chat

Um widget de chat pode afetar as Core Web Vitals quando está competindo por recursos de rede. Os arquivos JavaScript geralmente entram na fila de download antes das imagens. Isso significa que, no pior dos cenários (quando o script de chat é bloqueador de renderização), o navegador precisa esperar o script de chat ser baixado e executado antes de poder continuar com qualquer outra coisa. Um widget de chat que bloqueia a renderização pode dobrar a First Contentful Paint de 1,0 segundo para mais de 2,3 segundos.

Mesmo quando o script de chat é adiado, ele ainda pode impactar as métricas de pintura de algumas maneiras. Primeiro, deixe-me explicar o que os scripts adiados fazem. O navegador pode baixar scripts adiados em paralelo e o navegador pode continuar renderizando até o evento DOMContentLoaded. Depois disso, ele executará os scripts. O problema é que, para visitantes recorrentes, o elemento de LCP provavelmente não estará carregado no evento DOMContentLoaded, mas o script de chat (em cache) será executado causando um atraso nas métricas de LCP.

Problemas de Interaction to Next Paint (INP) causados por widgets de chat

Um widget de chat pode e vai impactar a Interaction to Next Paint de 2 maneiras. A primeira maneira é bloqueando a thread principal por um curto período de tempo enquanto o widget de chat executa seus scripts ou verifica atualizações. É simplesmente assim que as coisas funcionam. Tudo o que você adiciona a uma página vai atrasar a página um pouco.

A segunda maneira pela qual ele pode causar problemas de INP é através de código ruim (e acredite em mim, existem alguns widgets de chat mal codificados por aí). Quando se trata de widgets de chat, "mais popular" não significa "mais bem codificado". Quando um código ruim leva muito tempo para atualizar a apresentação, você terá automaticamente problemas de INP. Eu acho que alguns provedores de chat precisam melhorar o nível. Essa parte infelizmente está fora do meu controle. Se você escolheu um widget de chat mal codificado, não há como eu melhorar esse código.

Problemas de Cumulative Layout Shift (CLS) causados por widgets de chat

Às vezes, os widgets de chat causam um layout shift. Existem 3 suspeitos habituais que eu procuro enquanto verifico mudanças de layout relacionadas a widgets de chat.

• Layout shifts que ocorrem toda vez no carregamento do chat
• Layout shifts que acontecem em uma "abertura de chat" atrasada
• Layout shifts que ocorrem quando um histórico de chat é carregado (visitante de chat recorrente)

Como consertar problemas de Core Web Vitals causados por scripts de chat

Felizmente, é muito fácil minimizar o impacto que um widget de chat pode ter nas métricas de pintura (LCP e FCP) e em algumas partes da Interaction to Next Paint (INP). Na minha declaração de abertura, eu disse a você que os scripts têm uma hora e um lugar. E para scripts de chat isso não é "imediatamente e a todo custo". Eu gosto de carregar scripts de chat após o evento load, quando a página não está respondendo à entrada do usuário e eu também gosto de ignorar o scanner de pré-carregamento para evitar competição na rede.

Então, como fazemos isso? Usamos o evento load porque quando o evento load é disparado o elemento LCP já terá sido pintado na página (a menos que você tenha feito o lazy load dele com JavaScript). Usamos requestIdleCallback para esperar um momento ocioso quando o navegador não estiver respondendo à entrada do usuário. E usamos JavaScript para injetar o script de chat para garantir que o scanner de pré-carregamento não reconheça o src do script imediatamente e acione um download antecipado (e isso é exatamente o que queremos evitar). Esse é o mesmo padrão de adiamento de script usado para incorporações do YouTube e Google Maps.

<script>
window.addEventListener('load', function(){
  requestIdleCallback(function(){
    var s = document.createElement('script');
    s.src = 'https://your-chat-widget-url.com/chat.js';
    document.body.appendChild(s);
  })
})
</script>

Note que requestIdleCallback não é suportado no Safari. Use um fallback: const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1)); e substitua requestIdleCallback por idle no exemplo acima.

Com esse evento load mais o padrão requestIdleCallback, o impacto da pontuação do Lighthouse de um widget de chat cai de 9 a 16 pontos para 0 a 1 ponto.

Alternativa: carregamento baseado em interação

Em vez de carregar o widget de chat automaticamente após o evento load, você pode esperar até que o visitante realmente interaja com a página. Ouça por mousemove, scroll ou touchstart e carregue o script de chat no primeiro evento. Isso garante zero impacto em todas as Core Web Vitals para visitantes que nunca rolam a página ou interagem.

<script>
function loadChat() {
  var s = document.createElement('script');
  s.src = 'https://your-chat-widget-url.com/chat.js';
  document.body.appendChild(s);
  ['mousemove','scroll','touchstart'].forEach(function(e){
    document.removeEventListener(e, loadChat);
  });
}
['mousemove','scroll','touchstart'].forEach(function(e){
  document.addEventListener(e, loadChat, {once: true});
});
</script>

Consertar problemas de Cumulative Layout Shift causados por widgets de chat

Widgets de chat geralmente causarão um pequeno Cumulative Layout Shift. Isso não precisa ser um grande problema. Mas às vezes os widgets de chat apenas renderizam mal. Felizmente podemos (meio que) consertar isso também escondendo a renderização ruim até que o widget tenha terminado de renderizar.

Para fazer isso precisamos ler a documentação do widget de chat (existem muitos provedores de chat diferentes e todos eles funcionam um pouquinho diferente). Na documentação procure por funções de callback que são chamadas em diferentes estágios da renderização do chat. Já que não sei qual widget de chat você está usando, para ilustrar o mecanismo vamos usar a função chat.ready().

Agora com algum estilo inteligente podemos esconder e revelar o chat com a propriedade CSS opacity. Primeiro adicionamos algumas classes para esconder o widget de chat por padrão (mude os seletores para corresponder ao seu widget de chat). Em seguida, no callback chat.ready() adicionamos "showchat" à classlist do body para ativar a segunda linha do CSS que mostra o chat novamente.

<style>
/*hide chat widget by default*/
.chatwidget{opacity:0}
/*show chat widget after .showchat body class*/
body.showchat .chatwidget {opacity:1}
</style>

<script>
chat.ready(function(){
  document.documentElement.classList.add('showchat');
})
</script>

É isso! Boa sorte ao acelerar o seu widget de chat. Para verificar suas mudanças com visitantes reais, configure o Real User Monitoring. Pontuações de laboratório são úteis para depuração, mas dados de campo de usuários reais são o que o Google usa para ranqueamento.