Performance Web e Core Web Vitals: Guia Completo para Sites Rápidos

Velocidade não é um detalhe técnico. É o fator que determina se um visitante vai ver seu conteúdo ou não. 53% dos usuários mobile abandonam páginas que levam mais de 3 segundos para carregar. O Google incluiu a performance de página como fator de ranking em 2021.

Este guia cobre tudo que você precisa saber sobre performance web e Core Web Vitals - do básico ao avançado.

O que é performance web

Performance web é a medida de quão rápido e responsivo um site ou aplicação é para os usuários. Inclui:

• Velocidade de carregamento: quanto tempo até o usuário ver o conteúdo
• Interatividade: quão rápido a página responde a ações do usuário
• Estabilidade visual: se o layout “pula” durante o carregamento

Performance não é só sobre sentir que o site é rápido - é mensurável com métricas específicas.

Por que performance importa

Para usuários

• Usuários abandonam páginas lentas (53% abandonam após 3 segundos no mobile)
• Experiência de usuário ruim gera frustração e desconfiança
• No celular com conexão limitada, lentidão é ainda mais crítica

Para negócios

• Amazon calculou que cada 100ms de lentidão reduz 1% nas vendas
• Google reportou que reduzir LCP melhora conversões em 10-20%
• Taxa de bounce aumenta exponencialmente com o tempo de carregamento

Para SEO

O Google usa Core Web Vitals como sinal de ranking desde 2021. Não é o fator mais importante, mas é desempate real quando conteúdo é similar.

O que são Core Web Vitals

Core Web Vitals são três métricas definidas pelo Google para medir experiência de página:

LCP - Largest Contentful Paint

Mede quando o maior elemento visível da página é renderizado. Representa quando o usuário percebe que o conteúdo principal carregou.

Meta: abaixo de 2,5 segundos
O maior elemento costuma ser: imagem hero, thumbnail de vídeo, bloco de texto grande

Causas de LCP ruim:

• Imagem hero pesada sem otimização
• Servidor lento
• JavaScript bloqueando renderização
• Recurso crítico não precarregado

INP - Interaction to Next Paint

Mede o tempo de resposta da página a interações do usuário: clique, toque, teclado.

Substituiu o FID (First Input Delay) em março de 2024. INP é mais abrangente - mede todas as interações ao longo da sessão, não só a primeira.

Meta: abaixo de 200ms
Causas de INP ruim: JavaScript pesado na thread principal, event listeners ineficientes, third-party scripts

CLS - Cumulative Layout Shift

Mede a estabilidade visual - quanto o layout “pula” durante o carregamento.

Meta: abaixo de 0.1
Causas de CLS ruim: imagens sem dimensões definidas, ads e embeds carregando dinamicamente, fontes web causando reflow

Como medir performance

Ferramentas de campo (dados reais de usuários)

Google Search Console: seção “Experiência da página” com dados de Core Web Vitals de usuários reais do Chrome. Melhor fonte para dados de campo.

Chrome User Experience Report (CrUX): dataset público com métricas de campo. Acesse via PageSpeed Insights ou diretamente.

Web Vitals extensão do Chrome: mostra Core Web Vitals em tempo real enquanto você navega.

Ferramentas de laboratório (dados simulados)

Google PageSpeed Insights (pagespeed.web.dev): gratuito, mostra dados de laboratório e campo, sugestões específicas de melhoria.

Lighthouse: embutido no Chrome DevTools (F12 > aba Lighthouse). Auditoria completa de performance, acessibilidade e SEO.

WebPageTest (webpagetest.org): mais detalhado, permite simular diferentes dispositivos, localizações e conexões.

As melhorias com maior impacto

1. Otimização de imagens (impacto no LCP)

Imagens são a causa mais comum de LCP ruim e a correção com maior impacto.

Ações:

• Converta imagens para WebP (30-50% menor que JPEG/PNG sem perda visual)
• Comprima sem perda de qualidade (Squoosh, TinyPNG, ShortPixel)
• Defina dimensões explícitas (width e height em toda tag <img>)
• Use loading="lazy" para imagens abaixo do fold
• Precarregue a imagem LCP: <link rel="preload" as="image" href="hero.webp">

2. Redução de JavaScript (impacto no INP e LCP)

JavaScript é frequentemente o maior culpado por páginas lentas:

• Remova scripts não utilizados
• Adie scripts não críticos com defer ou async
• Carregue scripts de terceiros de forma assíncrona
• Use code splitting para carregar código sob demanda

3. Servidor e hospedagem

• Time to First Byte (TTFB) abaixo de 800ms
• Use CDN para servir assets estáticos
• Habilite compressão Brotli ou GZIP no servidor
• Cache agressivo para recursos estáticos

4. Dimensões de imagem para CLS

<!-- CORRETO: dimensões definidas -->
<img src="produto.webp" width="800" height="600" alt="Produto">

<!-- ERRADO: sem dimensões -->
<img src="produto.webp" alt="Produto">

5. Fonts web e CLS

@font-face {
  font-family: 'MinhaFonte';
  src: url('minha-fonte.woff2');
  font-display: swap; /* evita FOIT, reduz CLS */
}

Performance por plataforma

Monitoramento contínuo

Performance não é configurar uma vez e esquecer. Cada atualização de plugin, tema ou conteúdo pode afetar as métricas.

Monitore regularmente:

• Google Search Console (Core Web Vitals reais a cada 28 dias)
• PageSpeed Insights antes e depois de cada atualização significativa
• Web Vitals library no JavaScript para monitoramento em tempo real

FAQ

Performance mobile vs. desktop: qual priorizar?

Mobile. O Google usa mobile-first indexing, e a maioria dos sites tem mais tráfego mobile do que desktop. O score mobile no PageSpeed Insights é o mais relevante para SEO.

Qual score no PageSpeed Insights é considerado bom?

90-100: excelente. 70-89: bom. 50-69: requer melhorias. Abaixo de 50: problemático. Para mobile, é muito mais difícil atingir 90+ do que para desktop.

Site em WordPress pode ter score 90+?

Sim, mas requer configuração cuidadosa: tema leve (Astra, GeneratePress), mínimo de plugins, plugin de cache bem configurado, CDN, imagens otimizadas. Um WordPress “vanilla” com Elementar e 20 plugins raramente ultrapassa 60 no mobile sem otimização.

Performance afeta conversão além do SEO?

Muito. Cada segundo adicional de carregamento reduz conversão de 7% a 20% dependendo do tipo de negócio. Para landing pages de tráfego pago, melhorar performance de 4s para 2s pode dobrar a conversão.

O que é TTFB e por que importa?

TTFB (Time to First Byte) é o tempo até o navegador receber o primeiro byte de resposta do servidor. Um TTFB abaixo de 800ms é bom. TTFB alto indica problema de servidor, hospedagem lenta ou ausência de cache. É o fundamento sobre o qual as outras métricas são construídas.