O que são Core Web Vitals?
Quando o site de marketing de uma SaaS perde posições nos resultados de busca apesar de ter conteúdo forte, as Core Web Vitals costumam ser a causa silenciosa. Muitos líderes de ops e gerentes de conteúdo conhecem essas métricas dentro do Google Search Console, sinalizadas como "ruins" em páginas que passaram por todas as verificações internas de QA. Entender o que cada métrica realmente mede, e onde o Google traça a linha entre aprovado e reprovado, é o ponto de partida para diagnosticar se uma falha de desempenho técnico está custando posições no ranking e cadastros de teste.
Atualizado em
Resposta rápida: Core Web Vitals são três métricas do Google, Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS), que medem a rapidez, a capacidade de resposta e a estabilidade visual de uma página para visitantes reais. O Google as usa como parte dos sinais de experiência da página no ranking, e elas importam para sites de marketing de SaaS porque páginas lentas e instáveis perdem visibilidade na busca e cadastros de teste. Uma página é aprovada quando pelo menos 75% das visitas de usuários reais têm resultado "bom" nas três métricas.
O Google criou as Core Web Vitals para quantificar algo que antes era subjetivo: se uma página realmente é agradável de usar. Para times de SaaS que competem por visibilidade orgânica com G2, Capterra e uma dúzia de concorrentes bem capitalizados, o desempenho técnico deixou de ser uma preocupação de bastidores. Ele aparece diretamente nos rankings, nas taxas de rejeição e na confiança que um prospect deposita no seu produto antes mesmo de agendar uma demo.
Quais são as três métricas das Core Web Vitals?
Core Web Vitals é um conjunto de métricas que medem a experiência real do usuário quanto ao desempenho de carregamento, à interatividade e à estabilidade visual da página. Cada métrica foca um momento diferente da experiência do visitante e tem seu próprio limite de aprovação e reprovação.
Largest Contentful Paint (LCP)
O Largest Contentful Paint mede o desempenho de carregamento. Para oferecer uma boa experiência ao usuário, procure fazer o LCP ocorrer nos primeiros 2,5 segundos após o início do carregamento da página. Em um site de marketing de SaaS, o maior elemento costuma ser uma imagem hero, uma captura de tela do produto ou um título grande. Qualquer coisa que atrase essa renderização, como uma imagem não otimizada, um servidor lento ou scripts que bloqueiam a renderização, empurra o LCP para a faixa de "precisa melhorar" ou "ruim".
Interaction to Next Paint (INP)
O Interaction to Next Paint mede a capacidade de resposta. Para oferecer uma boa experiência ao usuário, procure manter o INP abaixo de 200 milissegundos. O INP é a mais recente das três métricas. O INP substituiu totalmente o First Input Delay (FID) em março de 2024, então qualquer guia que ainda liste o FID está desatualizado. Diferente do FID, que captava apenas o primeiro clique ou toque, o INP avalia a latência de todas as interações na página, o que o torna uma medida bem mais rigorosa e representativa da capacidade de resposta. Isso importa para sites de SaaS cheios de widgets de chat, calculadoras de preço e demos interativas, já que cada um desses elementos pesa na nota de INP.
Cumulative Layout Shift (CLS)
O Cumulative Layout Shift mede a estabilidade visual. Para oferecer uma boa experiência ao usuário, procure manter o CLS abaixo de 0,1. O CLS dispara quando imagens carregam sem dimensões definidas, quando banners de cookies ou embeds de terceiros inserem conteúdo após a renderização inicial, ou quando fontes web são trocadas e reorganizam a página. Um único deslocamento ruim, como uma tabela de preços que pula quando o widget de chat carrega, pode comprometer a nota de uma sessão inteira.
Como as Core Web Vitals afetam o ranking no Google?
Não existe um sinal único. Nossos sistemas principais de ranking analisam vários sinais que refletem a experiência geral da página. Nossos sistemas de ranking usam as Core Web Vitals como parte dessa avaliação. Na prática, as Core Web Vitals funcionam mais como critério de desempate do que como trunfo. Embora as Core Web Vitals sejam um fator de ranking, criar conteúdo relevante é, claro, fundamental para a Search Engine Optimization, mas o Google pode usar as Core Web Vitals como "critério de desempate" entre páginas com qualidade de conteúdo semelhante.
Essa distinção importa para a forma como times de SaaS priorizam seu tempo. Uma página belissimamente rápida, mas com conteúdo raso e pouco útil, ainda perde para uma página mais lenta que responde melhor à dúvida de quem pesquisa. Mas quando dois concorrentes publicam conteúdo com profundidade comparável para a mesma palavra-chave de comparação, a página mais rápida e estável costuma ficar com a posição. É exatamente esse tipo de vantagem que a Seedling ajuda times de conteúdo de SaaS a identificar: conteúdo forte o bastante para competir em relevância, apoiado em uma base técnica que não custa a vantagem no ranking na margem.
O argumento de negócio vai além dos rankings. Em um estudo recente com milhões de impressões de página, o Google constatou que sites que atingiam os limites das Core Web Vitals tinham 24% menos chance de sofrer abandono antes do carregamento completo da página. Para um site de SaaS que direciona tráfego pago e orgânico para as mesmas landing pages, essa diferença de abandono se traduz diretamente em verba desperdiçada e pipeline perdido.
Como as Core Web Vitals são medidas?
O Google traça uma linha clara entre dois tipos de dados, e confundi-los é um dos erros mais comuns em SEO técnico.
Dados de campo são a camada relevante para o ranking. O Google coleta dados globais de campo do 75º percentil dos usuários reais que acessaram sua aplicação nos últimos 28 dias pelo navegador Chrome. Esses dados ficam no Chrome User Experience Report (CrUX) e aparecem no relatório de Core Web Vitals do Google Search Console.
Dados de laboratório, gerados por ferramentas como PageSpeed Insights ou Lighthouse, são úteis para depuração, mas não determinam os rankings. As notas do Lighthouse não afetam diretamente o ranking no Google. Uma nota baixa de Performance em um teste de laboratório não significa que seu site vá mal nos dados reais de Core Web Vitals dos usuários. É comum os dados de laboratório serem muito diferentes dos dados de usuários reais.
O Google define o limite de aprovação em um percentil específico, não em uma média. Para passar nas Core Web Vitals, pelo menos 75% dos seus visitantes precisam ter notas 'boas' de LCP, INP e CLS no conjunto de dados CrUX do Google, no nível da URL. Não basta a página ser rápida no seu notebook potente com internet de fibra: ela também precisa ser rápida para o quarto usuário mais lento a cada quatro, normalmente alguém com um celular intermediário e uma conexão móvel instável. Esse único princípio explica por que tantos sites de marketing de SaaS passam nas próprias verificações internas de QA e ainda assim aparecem como "ruins" no Search Console.
Quais erros comuns prejudicam as Core Web Vitals de sites SaaS?
Sites de marketing de SaaS falham nas Core Web Vitals de maneiras diferentes das de sites de ecommerce ou de publishers, principalmente por causa do conjunto de ferramentas em que os times de marketing se apoiam.
- Excesso de widgets de terceiros. Ferramentas de chat, softwares de tour de produto e scripts de automação de marketing bloqueiam a thread principal e pioram o INP. Cada um adiciona uma latência mensurável a todas as interações na página.
- Dashboards ou embeds do produto em páginas de marketing. Prévias ao vivo do produto, muitas vezes o ponto central da seção hero de uma home, costumam ser o maior responsável pelo LCP ruim, porque carregam mais devagar que uma imagem estática ou um vídeo.
- Modais de cookies e de consentimento. Eles entram tarde no ciclo de renderização e são uma das principais causas de falhas de CLS em sites B2B sujeitos à GDPR ou a exigências de consentimento semelhantes.
- Testar apenas a home. A home geralmente passa. Posts de blog com muito tráfego, páginas de comparação e landing pages pagas é que concentram os problemas de CWV, e são as páginas que carregam a maior parte do peso do tráfego orgânico e pago.
- Confiar mais nas notas de laboratório do que nos dados de campo. Uma nota verde no Lighthouse passa uma falsa confiança. Somente os dados de campo do CrUX refletem o que o Google realmente usa para avaliar a experiência da página.
Como melhorar as Core Web Vitals?
Corrigir o LCP costuma ser o ganho mais direto: converta imagens hero para WebP ou AVIF, adicione atributos explícitos de largura e altura, faça preload de recursos críticos e adie scripts não essenciais. O INP é mais difícil e muitas vezes exige repensar a arquitetura de JavaScript, quebrar tarefas longas, adiar widgets de terceiros e aplicar lazy-loading a tudo que não é necessário para a primeira interação. O CLS se resolve reservando espaço para cada imagem, anúncio e embed antes de carregar, e usando font-display swap para evitar a reorganização do texto.
A disciplina que realmente faz diferença não é uma correção isolada. É levar os dados de campo do CrUX, ou de uma ferramenta de monitoramento de usuários reais, para o mesmo dashboard onde ficam suas métricas de conteúdo e tráfego, para que uma regressão apareça em dias e não na janela móvel de 28 dias que o CrUX usa por padrão. Para times de SaaS que já usam a Seedling para gerenciar a produção de conteúdo e acompanhar a visibilidade orgânica, combinar esse fluxo com um monitor de Core Web Vitals fecha o ciclo entre o que você publica e o desempenho real quando visitantes de verdade, em dispositivos reais, carregam a página.
As Core Web Vitals vão continuar evoluindo à medida que o Google refina o que significa uma "boa experiência" no campo. Tratá-las como uma auditoria pontual, e não como uma disciplina contínua, é o erro que custa silenciosamente rankings e conversões aos sites de SaaS, muito depois de a correção inicial ter sido entregue.
Fontes
- Core Web Vitals, Google Search Central
- Introducing INP to Core Web Vitals, Google Search Central
- Chrome User Experience Report (CrUX) overview, Chrome Developers
- Web Vitals, web.dev