Core Web Vitals: impacto no SEO e na experiência da página

O que são as Core Web Vitals?

As Core Web Vitals são um conjunto de métricas de experiência do utilizador focadas em três aspectos observáveis durante o carregamento e a interação: velocidade do conteúdo principal, interatividade percebida e estabilidade visual. Em vez de depender de opiniões subjetivas — “o site parece lento” — estas métricas medem comportamentos reais de utilizadores em condições do mundo real.

As três métricas essenciais

As Core Web Vitals atualmente usadas como padrão são:

• Maior Pintura de Conteúdo (LCP): mede o tempo até que o maior elemento visível (imagem hero, bloco de texto principal, vídeo) seja renderizado. O objetivo é que o utilizador perceba o conteúdo principal rapidamente.

• Interação para Próxima Pintura (INP): mede a capacidade da página de responder a interações do utilizador (cliques, toques, teclas) ao longo da sessão. Substituiu o FID como métrica de interatividade mais representativa.

• Cumulative Layout Shift (CLS): avalia a estabilidade visual, quantificando quanto os elementos da página se deslocam inesperadamente durante o carregamento.

Como o Google usa estas métricas (mecânica e referência)

O Google integra as Core Web Vitals nas avaliações de experiência da página. Essas métricas são calculadas a partir de dados de campo agregados; segundo a documentação pública do Google, os valores de campo para Core Web Vitals usam o 75.º percentil das experiências reais de carregamento para refletir a experiência da maioria dos utilizadores. O Google também publica recomendações de limiares para “good”, “needs improvement” e “poor” em sua documentação de Core Web Vitals.

Laboratório vs. campo: quando usar cada abordagem

Duas fontes de dados são complementares:

• Dados de campo (RUM): indicam o comportamento real dos utilizadores e são essenciais para priorizar correções com impacto real. Ex.: Chrome User Experience Report (CrUX) e o relatório Core Web Vitals do Google Search Console.

• Testes de laboratório (sintéticos): Lighthouse, WebPageTest e o painel Lighthouse do Chrome DevTools permitem depurar causas e testar antes/depois em condições controladas.

Como verificar — ferramentas e passos práticos

Verificação rápida (campo)

1. Google Search Console — para domínios que você controla, abra o relatório Core Web Vitals para identificar URLs problemáticas e tendências por grupo de dispositivo.

2. PageSpeed Insights — combina dados de campo (CrUX) com uma análise de laboratório (Lighthouse), útil para ver uma visão imediata por URL.

Verificação de diagnóstico (laboratório e depuração)

• Chrome DevTools (Lighthouse) — execute auditorias locais para ver rastreios de filme e identificar tarefas longas que afetam o INP.

• WebPageTest — escolha dispositivos e redes específicas, capture filmstrip e trace long tasks. Útil para otimizar o LCP em condições móveis reais.

• Biblioteca web-vitals (RUM) — implemente na sua página para recolher métricas reais e enviar eventos para o seu sistema de telemetria (por exemplo, Google Analytics ou ferramenta própria).

• Extensão Web Vitals e ferramentas de performance do navegador — para inspeções rápidas em produção.

Inspeção de HTML e servidor

Para verificar o que o servidor devolve a um user-agent específico — por exemplo, um smartphone — use um comando curl apropriado. Se quiser só ver os cabeçalhos: execute curl -I https://exemplo.com/pagina. Para obter o HTML completo como um user-agent móvel, use curl -A "Mozilla/5.0 (Linux; Android)" -L https://exemplo.com/pagina. Lembre-se de que o DevTools fornece renderização e scripts executados — curl retorna o HTML servidor-side sem execução de JavaScript.

Problemas comuns e correções por métrica

LCP — causas típicas e ações

Causas comuns: tempo de resposta do servidor elevado, imagens grandes sem compressão ou sem dimensionamento adequado, recursos críticos bloqueados por CSS/JS e fontes web que atrasam a pintura do conteúdo principal.

Correções práticas:

• Reduza o TTFB com caching, CDN e otimizações do backend (queries, renderização).

• Otimize imagens (servir formatos modernos, gerar várias resoluções, usar lazy loading para imagens abaixo do fold). Para garantir espaço reservado e evitar CLS, inclua atributos width/height: por exemplo <img src="hero.jpg" width="1200" height="800">.

• Pré-carregue recursos críticos com <link rel="preload" href="/styles/hero.css" as="style"> ou preload para imagens/ fontes críticas quando necessário.

INP — reduzir latência de interação

Causas comuns: tarefas longas de JavaScript que bloqueiam o main thread, bibliotecas pesadas e execução síncrona de scripts durante interações do utilizador.

Correções práticas:

• Quebre tarefas longas em pedaços menores (usar requestIdleCallback, setTimeout para dividir trabalho quando apropriado) e mova trabalho não crítico para web workers.

• Remova ou reprograme scripts de terceiros que introduzem long tasks (tag managers, widgets sociais, trackers). Meça o impacto removendo-os em ambiente de teste.

CLS — evitar deslocamentos de layout

Causas comuns: imagens sem dimensões, inserção dinâmica de conteúdo acima do conteúdo existente (ads/iframes), fontes que trocam o layout e animações mal planeadas.

Correções práticas:

• Reserve espaço para imagens e iframes definindo width/height ou usando caixas CSS (aspect-ratio) para prevenir saltos.

• Carregue anúncios de forma previsível (espaços reservados) e evite inserções que empurrem conteúdo já visível.

• Use font-display e pré-carregue fontes críticas para reduzir mudanças de layout causadas por troca de fontes.

Checklist prático de implementação e verificação

1) Faça uma linha de base com dados de campo (Search Console / CrUX) e testes de laboratório (Lighthouse).

2) Priorize páginas com maior tráfego equelas com problemas de conversão — melhorias nas páginas com mais visitas tendem a gerar maior impacto na UX.

3) Reduza o número de recursos críticos: combine CSS crítico, adie scripts não essenciais e use preconnect/preload para recursos de terceiros confiáveis.

4) Meça alterações com RUM após deploy (biblioteca web-vitals) para confirmar que as mudanças tiveram efeito nas experiências reais.

5) Evite otimizações que ofereçam ganhos artificiais em laboratório mas prejudicam experiências reais (por exemplo, esconder conteúdo crítico que só carrega por interação).

Erros comuns de estratégia

• Tratar Core Web Vitals como uma lista de verificação sem contexto: melhorar uma métrica isolada pode não aumentar conversões se a experiência global continuar ruim.

• Focar só em resultados de laboratório e ignorar dados reais de utilizadores. Os testes sintéticos ajudam a depurar, mas as prioridades vêm do RUM.

• Otimizações que afetam indexabilidade: por exemplo, renderizar conteúdo principal apenas via JavaScript sem fallback pode reduzir o conteúdo que Google vê no processo de indexação; lembre-se de que mobile-first indexing usa a versão móvel como base para indexação e que o conteúdo exclusivo em desktop pode não ser considerado.

Medição contínua e governança

Implemente RUM para acompanhar tendências, crie alertas quando métricas chave caírem e trate regressões de performance como bugs críticos. Integre testes de performance no seu pipeline de deploy para prevenir regressões em novas versões.

Considere também agrupar correções por tipo de dispositivo e rede: melhorias que ajudam utilizadores móveis numa rede lenta podem exigir abordagens distintas das aplicadas a desktop em rede rápida.

Perguntas frequentes