O que são Core Web Vitals?
Core Web Vitals são três medições que o Google usa para descrever como uma página realmente se comporta ao ser usada: com que rapidez o conteúdo principal aparece, com que agilidade a página responde à interação e quanto o layout se desloca enquanto carrega. Não são o único fator de posicionamento, mas em sites B2B que competem por termos de serviço de cauda longa elas costumam decidir quem leva o clique.
Por que elas importam para as decisões de compra B2B
Uma página lenta não só incomoda o visitante; ela muda o comportamento dele. Tanto estudos quanto auditorias reais mostram de forma consistente que páginas mais lentas que cerca de três segundos perdem uma fatia relevante de visitantes antes que eles leiam qualquer coisa. Para uma empresa B2B que disputa termos de serviço de alto valor, uma fração de segundo no celular pode ser a diferença entre um contato qualificado e um bounce que alimenta o concorrente.
LCP: Carregamento
O Largest Contentful Paint mede quanto tempo o maior elemento visível - normalmente uma imagem principal ou um título - leva para terminar de renderizar. A meta é ficar abaixo de 2,5 segundos. Nos sites B2B os culpados habituais são uma foto principal não otimizada, uma fonte que bloqueia a renderização e um widget de chat de terceiros que carrega antes do conteúdo da página.
O que é considerado bom, precisa melhorar ou é ruim
O Google agrupa cada métrica em três faixas. Para o LCP, abaixo de 2,5 segundos é bom, de 2,5 a 4 segundos precisa melhorar, e acima de 4 segundos é ruim. Como a nota se baseia em dados reais de campo dos seus visitantes de verdade, e não em um teste de laboratório, uma página pode parecer boa na conexão rápida do seu escritório e ainda assim ter nota ruim para um prospect em uma rede móvel lenta.
Causas B2B comuns de um LCP lento
As causas mais frequentes que vemos são imagens principais pesadas e sem compressão, exportadas direto da ferramenta do designer, fontes carregadas de um provedor externo que bloqueiam a renderização, e vários scripts de terceiros - chat, analytics, gerenciador de tags, pixels de marketing - empilhados no head antes do conteúdo. Cada um soma atraso, e juntos ultrapassam facilmente os quatro segundos.
INP: Interatividade
O Interaction to Next Paint substituiu o First Input Delay como métrica de responsividade. Ele mede o pior atraso entre uma ação do usuário - tocar um menu, apertar um botão, enviar um formulário - e o próximo quadro que o navegador consegue pintar. Pacotes pesados de analytics, scripts de chat e grandes frameworks de JavaScript elevam esse número, e a correção normalmente começa removendo código, não adicionando.
O que é uma boa nota de INP
Um INP abaixo de 200 milissegundos é bom, de 200 a 500 milissegundos precisa melhorar, e acima de 500 milissegundos é ruim. Em um site B2B isso importa porque as ações do comprador - abrir a navegação, filtrar uma lista de produtos, iniciar um pedido de orçamento - são exatamente os momentos em que uma resposta travada convence ele a testar outro fornecedor.
O que costuma deixar o INP lento
Os suspeitos de sempre são pacotes de JavaScript grandes demais, um gerenciador de tags disparando scripts demais ao mesmo tempo, chatbots que tomam o thread principal no carregamento, e incorporações de terceiros mal feitas, como mapas ou calculadoras. O primeiro passo de diagnóstico raramente é contratar uma hospedagem mais rápida; é auditar qual código realmente roda em cada página e apagar o que ninguém pediu.
CLS: Estabilidade visual
O Cumulative Layout Shift pontua quanto a página se move visivelmente durante o carregamento. Um banner de cookies que empurra todo o layout para baixo, imagens sem atributos de largura e altura e fontes injetadas tardiamente são as causas clássicas. É a mais fácil das três de corrigir e a mais incômoda para o visitante sentir.
Os culpados de sempre dos saltos de layout
Os saltos mais comuns vêm de inserir um banner ou intersticial depois que a página já renderizou, imagens e vídeos sem dimensões reservadas, fontes da web que trocam de uma face reserva ao carregar, e widgets de captação ou anúncios injetados dinamicamente. Corrigir é basicamente reservar espaço no markup, para que o navegador saiba o tamanho de cada elemento antes de pintar.
Como medir e corrigir
Comece por dados reais de usuários, não por um teste sintético de laboratório. Olhe o relatório de campo no Google Search Console para encontrar as URLs reais onde os seus visitantes têm dificuldade, depois reproduza os piores casos em uma conexão móvel limitada. Corrija primeiro a página que mais tráfego traz e tem a pior nota, depois siga para a próxima.
De onde medir
Ferramentas de campo, como o relatório Chrome User Experience e o Search Console, mostram o que os seus visitantes reais sentem; ferramentas de laboratório, como o Lighthouse, mostram o que dá para melhorar. Use os dados de campo para decidir o que corrigir e as de laboratório para confirmar que o ajuste funcionou. Nunca otimize só contra uma nota de laboratório, porque as condições de laboratório raramente correspondem a um chão de fábrica em rede móvel.
Perguntas frequentes
As perguntas que gestores de marketing e de TI de B2B mais fazem antes de começar um trabalho de performance.
Os Core Web Vitals decidem diretamente o ranking do Google?
Eles são um sinal de ranking entre muitos, não uma regra que move posições sozinha. O efeito deles é indireto mas real: páginas que carregam mais rápido e respondem melhor tendem a reter mais, engajar mais e converter melhor, e esses sinais comportamentais são o que o Google recompensa. Corrigir as métricas raramente dá um salto mágico, mas ignorá-las em termos competitivos é uma desvantagem real.
Qual dos três devemos corrigir primeiro?
Comece por aquele que os seus dados de campo mostram ser o pior nas suas páginas de maior tráfego. Na prática, o CLS costuma ser a vitória mais rápida porque é sobretudo ajuste de markup, o LCP vem depois com trabalho de imagem e fonte, e o INP demora mais porque significa remover ou adiar JavaScript. Sequenciar por esforço e impacto funciona melhor do que atacar os três de uma vez.
Os Core Web Vitals são medidos no desktop ou no celular?
O Google reporta separadamente para celular e desktop, e as notas do celular costumam pesar mais para o ranking. Como a maior parte da pesquisa B2B hoje acontece no celular, trate os números do mobile como os que valem e teste seus ajustes em uma conexão 3G limitada, não no Wi-Fi rápido do escritório.
Conclusão
Trate os Core Web Vitals como rotina de manutenção, não como projeto. Meça em dispositivos reais, corrija primeiro a pior página e revalide após cada redesenho ou integração de terceiros. Se preferir delegar essa rotina, é exatamente o que o nosso trabalho de performance cobre.