Performance Web e Core Web Vitals: Guia Prático para 2026

Seu site carrega em mais de 3 segundos? Então você está perdendo visitantes — e dinheiro. O Google confirma: velocidade é fator de ranking. Sites lentos caem nas buscas, perdem cliques e convertem menos. E desde que os Core Web Vitals se tornaram sinais oficiais de ranking, performance web deixou de ser item técnico para virar prioridade de negócio.

Mas aqui está o problema: a maioria das empresas não sabe exatamente o que otimizar. Ouvem falar de LCP, INP, CLS — siglas que parecem saídas de um manual de engenharia — e não conseguem traduzir isso em ações práticas que melhorem o site.

Neste guia, vamos descomplicar os Core Web Vitals, mostrar as técnicas de otimização que geram mais impacto e dar exemplos reais de antes e depois. Sem teoria excessiva — direto ao que funciona.

O que são Core Web Vitals

Core Web Vitals são três métricas que o Google usa para medir a experiência do usuário no seu site. Elas medem três aspectos fundamentais: velocidade de carregamento, interatividade e estabilidade visual.

LCP — Largest Contentful Paint

O que mede: quanto tempo leva para o maior elemento visível da página carregar. Geralmente é a imagem hero, o título principal ou um bloco grande de texto.

Meta: menos de 2.5 segundos.

Por que importa: o LCP é a primeira impressão do usuário. Se a maior parte da página leva 4-5 segundos para aparecer, o visitante já está pensando em fechar a aba.

INP — Interaction to Next Paint

O que mede: o tempo que o site leva para responder quando o usuário clica em um botão, link ou qualquer elemento interativo. Substituiu o FID (First Input Delay) em março de 2024.

Meta: menos de 200 milissegundos.

Por que importa: se o usuário clica em "Adicionar ao Carrinho" e nada acontece por 500ms, a experiência é frustrante. INP mede se o site é responsivo a interações.

CLS — Cumulative Layout Shift

O que mede: quanto o conteúdo da página se move de forma inesperada durante o carregamento. Sabe quando você vai clicar em um botão e de repente a página pula porque uma imagem carregou? Isso é layout shift.

Meta: menos de 0.1.

Por que importa: shifts visuais são irritantes e fazem o usuário clicar no elemento errado. É uma das experiências mais frustrantes na web.

Como medir Core Web Vitals

Antes de otimizar, meça. Estas são as ferramentas que recomendamos:

Google PageSpeed Insights

A ferramenta mais acessível. Cole a URL e receba um relatório com as três métricas + sugestões de melhoria. Mostra dados de campo (usuários reais via CrUX) e dados de laboratório (simulação).

URL: pagespeed.web.dev

Google Search Console

Na aba "Experiência da página", o Search Console mostra quais páginas do seu site passam ou falham nos Core Web Vitals — baseado em dados de usuários reais. É a métrica que realmente afeta o ranking.

Lighthouse (Chrome DevTools)

Abra o Chrome DevTools (F12), vá na aba "Lighthouse" e rode uma auditoria. Gera um relatório detalhado com score de 0-100 e sugestões priorizadas.

WebPageTest

Para análises mais detalhadas: mostra waterfall de carregamento, filmstrip visual, comparação entre conexões (3G, 4G, WiFi) e localizações diferentes.

Core Web Vitals Extension (Chrome)

Extensão que mostra as métricas em tempo real enquanto você navega. Útil para monitoramento contínuo durante o desenvolvimento.

Otimizando LCP: velocidade de carregamento

O LCP é geralmente a métrica que mais precisa de atenção. Vamos às técnicas mais impactantes:

1. Otimize a imagem hero

A imagem principal da página é quase sempre o elemento LCP. Otimize:

Formato: use WebP ou AVIF em vez de JPEG/PNG. WebP é 25-35% menor que JPEG com qualidade equivalente. AVIF é ainda menor, mas com menor compatibilidade.
Dimensões: sirva imagens no tamanho exato em que serão exibidas. Uma imagem de 4000px renderizada em 800px desperdiça 80% dos dados.
Responsive images: use srcset e sizes para servir imagens diferentes para telas diferentes.
Preload: adicione <link rel="preload"> para a imagem LCP no <head> do HTML. Isso diz ao navegador para começar a baixar a imagem antes mesmo de processar o CSS.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Priority hints: use fetchpriority="high" na tag <img> do elemento LCP.

Impacto típico: 0.5-2 segundos de melhoria no LCP.

2. Elimine JavaScript e CSS bloqueantes

JavaScript e CSS no <head> bloqueiam a renderização — o navegador não mostra nada até processar esses arquivos.

CSS crítico inline: extraia o CSS necessário para renderizar o conteúdo acima da dobra e coloque inline no <head>. O restante do CSS carrega de forma assíncrona.
Defer JavaScript: use defer ou async em scripts que não são essenciais para o primeiro render.
Remova JavaScript não utilizado: analise com o Coverage tab do Chrome DevTools para identificar código que carrega mas nunca executa.

Impacto típico: 0.3-1.5 segundos de melhoria.

3. Otimize o servidor

O tempo de resposta do servidor (TTFB — Time to First Byte) impacta diretamente o LCP.

CDN: use uma CDN (Cloudflare, Vercel Edge, AWS CloudFront) para servir conteúdo de servidores próximos ao usuário. Para visitantes brasileiros, ter edge servers no Brasil é essencial.
Caching: configure cache adequado. Páginas estáticas devem ter cache longo (1 ano). Recursos dinâmicos devem ter cache curto ou stale-while-revalidate.
Compressão: habilite Brotli (melhor) ou Gzip para compressão de texto. Reduz o tamanho de HTML, CSS e JS em 60-80%.
HTTP/2 ou HTTP/3: garanta que o servidor usa HTTP/2 no mínimo. HTTP/3 (QUIC) oferece ainda mais performance, especialmente em conexões instáveis.

Impacto típico: 0.2-1 segundo de melhoria.

Seu site está lento e perdendo posições?

Fazemos uma análise de performance gratuita do seu site e mostramos exatamente o que otimizar para melhorar ranking e conversão.

Falar com especialista

4. Server-Side Rendering (SSR) e Static Site Generation (SSG)

Para sites construídos com React, Vue ou frameworks modernos:

SSG (Static Site Generation): gera HTML em tempo de build. O servidor entrega HTML pronto, sem processamento. Ideal para páginas que não mudam frequentemente (landing pages, blog, institucional).
SSR (Server-Side Rendering): gera HTML no servidor a cada requisição. Necessário para conteúdo dinâmico e personalizado.
ISR (Incremental Static Regeneration): combina o melhor dos dois — HTML estático que se atualiza automaticamente em intervalos definidos.

Frameworks como Next.js oferecem todas essas opções. Para sites empresariais, SSG/ISR é a combinação ideal: máxima performance com conteúdo atualizado.

Impacto típico: 1-3 segundos de melhoria vs. client-side rendering puro.

Otimizando INP: interatividade

INP mede a responsividade do site. Se o site demora para reagir a cliques, o INP é ruim.

1. Reduza JavaScript no main thread

O JavaScript roda na thread principal do navegador — a mesma que processa interações do usuário. Se há JavaScript pesado executando, o navegador não consegue responder a cliques até que termine.

Code splitting: divida o JavaScript em chunks menores, carregando apenas o código necessário para cada página.
Lazy loading de componentes: componentes abaixo da dobra não precisam carregar imediatamente.
Web Workers: mova processamento pesado (cálculos, manipulação de dados) para Web Workers, que rodam em threads separadas.

2. Otimize event handlers

Evite computações pesadas dentro de event handlers (onClick, onChange).
Use requestAnimationFrame para atualizações visuais.
Debounce inputs que disparam muitas atualizações (como campos de busca).

3. Minimize Third-Party Scripts

Scripts de terceiros (analytics, chat, pixel de anúncio) são os maiores vilões do INP:

Google Tag Manager: carregue de forma assíncrona e só ative tags necessárias.
Chat widgets: carregue após o primeiro render ou após interação do usuário.
Pixel de Facebook/Google Ads: use loading lazy e não bloqueie o main thread.

Dica: para cada script de terceiro, pergunte: "esse script gera mais valor do que o custo de performance?" Se a resposta não for um claro sim, remova.

4. Virtualize listas longas

Se o site exibe listas com centenas de itens (produtos, resultados de busca), renderizar todos de uma vez trava o navegador. Use virtualização (react-window, react-virtuoso) para renderizar apenas os itens visíveis na tela.

Otimizando CLS: estabilidade visual

CLS é a métrica mais fácil de resolver — mas também a mais fácil de piorar sem perceber.

1. Defina dimensões em imagens e vídeos

A causa número 1 de CLS é imagens sem dimensões definidas. Quando o navegador não sabe o tamanho da imagem, ele reserva 0px de espaço. Quando a imagem carrega, o conteúdo abaixo é empurrado.

Solução: sempre inclua width e height nas tags <img>:

<img src="foto.webp" width="800" height="600" alt="Descrição">

Ou use CSS aspect-ratio:

img {
  aspect-ratio: 4/3;
  width: 100%;
  height: auto;
}

2. Reserve espaço para conteúdo dinâmico

Anúncios: reserve o espaço do banner antes dele carregar.
Embeds (YouTube, mapas): defina dimensões fixas no container.
Fontes web: use font-display: swap e carregue a fonte com preload para minimizar o flash de texto.

3. Evite injetar conteúdo acima do viewport

Nunca insira banners, avisos ou elementos acima do conteúdo que o usuário está vendo. Isso empurra tudo para baixo e gera CLS alto.

Se precisar exibir um aviso ou banner, use posicionamento fixo (fixed/sticky) que não desloca o conteúdo existente.

4. Cuidado com fontes web

Fontes carregando tarde causam "flash of unstyled text" (FOUT) ou "flash of invisible text" (FOIT), ambos contribuem para CLS.

Preload a fonte principal: <link rel="preload" href="fonte.woff2" as="font" type="font/woff2" crossorigin>
Use font-display: optional para a fonte não causar layout shift se demorar para carregar.
Limite o número de fontes: cada fonte adicional é uma requisição a mais. 2-3 variações são suficientes para a maioria dos sites.

Exemplo real: antes e depois

Vamos mostrar um caso real de otimização que fizemos para um site empresarial:

Antes da otimização

| Métrica | Valor | Status | |---|---|---| | LCP | 5.8s | Ruim | | INP | 380ms | Precisa melhorar | | CLS | 0.32 | Ruim | | Lighthouse Score | 34/100 | Ruim | | Posição média Google | 18ª | Página 2 |

Ações realizadas

Converteu imagens para WebP com compressão otimizada (economia de 70% em tamanho)
Implementou lazy loading em imagens abaixo da dobra
Extraiu CSS crítico inline e deferiu o restante
Adicionou preload para a imagem hero e fonte principal
Configurou CDN (Cloudflare) com cache agressivo
Definiu dimensões explícitas em todas as imagens
Moveu scripts de terceiros para carregamento assíncrono
Implementou SSG para páginas estáticas

Depois da otimização

| Métrica | Valor | Status | |---|---|---| | LCP | 1.2s | Bom | | INP | 95ms | Bom | | CLS | 0.03 | Bom | | Lighthouse Score | 96/100 | Excelente | | Posição média Google | 5ª | Página 1 |

Resultado: o site subiu da página 2 para o top 5 do Google em 6 semanas. O tráfego orgânico aumentou 180% e a taxa de conversão (formulário de contato) subiu de 1.2% para 3.8%.

Checklist de performance para 2026

Use esta checklist como referência para qualquer site:

Imagens

[ ] Todas as imagens em WebP ou AVIF
[ ] Dimensões width/height definidas em todas as imagens
[ ] Lazy loading em imagens abaixo da dobra
[ ] Responsive images com srcset para diferentes telas
[ ] Preload na imagem LCP

CSS

[ ] CSS crítico inline no <head>
[ ] CSS não-crítico carregado de forma assíncrona
[ ] Sem CSS não utilizado
[ ] Fontes web com preload e font-display adequado

JavaScript

[ ] Todos os scripts não-essenciais com defer/async
[ ] Code splitting por rota/página
[ ] Third-party scripts carregados de forma assíncrona
[ ] Sem JavaScript bloqueante no <head>

Servidor

[ ] CDN configurada com edge servers no Brasil
[ ] Compressão Brotli habilitada
[ ] HTTP/2 ou HTTP/3 ativo
[ ] Cache headers configurados corretamente
[ ] TTFB abaixo de 600ms

Monitoramento

[ ] Google Search Console configurado
[ ] Lighthouse CI no pipeline de deploy
[ ] Alertas para degradação de performance
[ ] Testes em 3G/4G além de WiFi

Conclusão

Performance web não é otimização técnica por vaidade — é estratégia de negócio. Cada segundo a menos no tempo de carregamento se traduz em mais visitantes que ficam, mais páginas navegadas e mais conversões. E com os Core Web Vitals como fator de ranking do Google, performance rápida significa mais tráfego orgânico.

A boa notícia é que a maioria das otimizações mais impactantes são simples: otimizar imagens, configurar uma CDN, eliminar JavaScript bloqueante e definir dimensões em mídias. Essas ações cobrem 80% dos problemas de performance da maioria dos sites.

O segredo é medir, otimizar e monitorar. Use PageSpeed Insights para identificar problemas, aplique as correções priorizando o maior impacto e monitore continuamente para garantir que novas atualizações não degradem a performance.

Se você quer uma análise detalhada da performance do seu site com um plano prático de otimização — quais mudanças fazer, em que ordem e qual o impacto esperado — fale com nosso time.

Acelere seu site e suba no Google

Análise gratuita de Core Web Vitals com plano de otimização priorizado — saiba exatamente o que melhorar primeiro.

Solicitar análise gratuita