Widget de Chat com Core Web Vitals Perfeitos

Como carregar um widget de chat da maneira certa

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

Não faria sentido, certo, carregar um widget de chat antes mesmo de o conteúdo principal da página começar 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 sessão. Adiar o script do chat não custa nada em termos de user experience, mas você ganha 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, explicarei como carregar corretamente um script de chat e como isso afeta métricas importantes como o Largest Contentful Paint e o Interaction to Next Paint.

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

Contexto: como os widgets de chat funcionam

Um widget de chat geralmente funciona carregando um pequeno script na sua página. Esse script 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 lidará com tudo o que for necessário para conversar com seus clientes.

Como os widgets de chat afetam os Core Web Vitals?

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

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

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

3. Eles podem causar Cumulative Layout Shift 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 da thread principal. Isso é suficiente para empurrar uma pontuação INP que de outra forma seria aprovada para a faixa de "precisa de melhorias".

Problemas de Largest Contentful Paint causados por widgets de chat

Um widget de chat pode afetar os Core Web Vitals quando está competindo por recursos de rede. Arquivos JavaScript geralmente são colocados na fila para download antes das imagens. Isso significa que, no pior cenário (quando o script de chat é de bloqueio de renderização), o navegador tem que esperar o script de chat ser baixado e executado antes de poder continuar com qualquer outra coisa. Um widget de chat de bloqueio de renderização pode dobrar o 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 pode continuar renderizando até o evento DOMContentLoaded. Depois disso, ele executará os scripts. O problema é que, para visitantes recorrentes, o elemento LCP provavelmente não será 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 irá impactar o Interaction to Next Paint de 2 maneiras. A primeira maneira é bloqueando a thread principal por um curto período enquanto o widget de chat executa seus scripts ou verifica se há atualizações. É assim que as coisas funcionam. Tudo o que você adiciona a uma página a tornará um pouco mais lenta.

A segunda maneira pela qual ele pode causar problemas de INP é por 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 "melhor codificado". Quando o código ruim demora a atualizar a apresentação, você automaticamente terá 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 Cumulative Layout Shift. Existem 3 suspeitos habituais que eu procuro ao verificar mudanças de layout relacionadas a widgets de chat.

• Mudanças de layout que ocorrem todas as vezes no carregamento do chat
• Mudanças de layout que acontecem em um "chat aberto" com atraso
• Mudanças de layout que ocorrem quando um histórico de chat é carregado (visitante de chat recorrente)

Como corrigir 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 do Interaction to Next Paint (INP). Na minha declaração de abertura, eu disse que os scripts têm uma hora e um lugar. E para scripts de chat, não é "imediatamente e a todo custo". Eu gosto de carregar scripts de chat após o evento de load, quando a página não está respondendo a interações do usuário e também gosto de ignorar o scanner de pré-carregamento para evitar a competição de rede.

Então, como fazemos isso? Usamos o evento de load porque quando o evento de load for disparado, o elemento LCP terá sido pintado na página (a menos que você o tenha carregado lentamente com JavaScript). Usamos o requestIdleCallback para esperar por um momento ocioso quando o navegador não estiver respondendo a interações do usuário. E usamos JavaScript para injetar o script de chat e 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 o 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>

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

Com este evento de load mais o padrão requestIdleCallback, o impacto de um widget de chat na pontuação do Lighthouse 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 de load, você pode esperar até que o visitante realmente interaja com a página. Ouça mousemove, scroll ou touchstart e carregue o script do chat no primeiro evento. Isso garante impacto zero em todos os Core Web Vitals para visitantes que nunca rolam 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>

Corrija problemas de Cumulative Layout Shift causados por widgets de chat

Os widgets de chat geralmente causam um pequeno Cumulative Layout Shift. Isso não precisa ser um grande problema. Mas às vezes os widgets de chat simplesmente renderizam mal. Felizmente, podemos (mais ou menos) consertar isso também, escondendo a renderização ruim até que o widget termine de renderizar.

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

Agora, com um estilo inteligente, podemos ocultar e exibir o chat com a propriedade de opacidade CSS. Primeiro, adicionamos algumas classes para ocultar o widget de chat por padrão (altere os seletores para corresponder ao seu widget de chat). Então, no retorno de chamada chat.ready(), adicionamos "showchat" à classlist do body para ativar a segunda linha 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 é tudo! Boa sorte em acelerar o seu widget de chat. Para verificar suas alterações com visitantes reais, configure o RUM. As pontuações de laboratório são úteis para depuração, mas os dados de campo de usuários reais são o que o Google usa para classificação.