title: "Core Web Vitals: por que a velocidade do seu site afeta vendas e SEO" description: "Guia sobre Core Web Vitals: LCP, CLS e INP. Como a velocidade do site impacta SEO, conversão e experiência do usuário em 2026." date: "2026-10-15" image: "/assets/images/blog/core-web-vitals-velocidade-site.jpg" tags: ["desenvolvimento web", "performance", "SEO", "dicas"] author: "Work Technology"

53% das visitas são perdidas se o site demora 3 segundos para carregar

Esse número, da Google, não é estimativa. É dado de comportamento real. E o pior: o usuário que abandona seu site por lentidão raramente volta. Ele clica no próximo resultado do Google, visita o concorrente e, na maioria das vezes, fecha a compra lá.

Por anos, "site rápido" foi tratado como detalhe estético, algo que o desenvolvedor arruma se sobrar tempo depois que o layout fica bonito. Essa visão custou dinheiro a muita empresa. Desde 2021, o Google usa as Core Web Vitals, um conjunto de métricas que medem a experiência real de carregamento, interatividade e estabilidade visual, como sinal oficial de ranking. Em 2024, a métrica de interatividade foi atualizada (o antigo FID deu lugar ao INP), o que tornou o critério mais difícil de passar. Em 2026, com a chegada do Core Web Vitals para Anúncios, que ajusta o custo e o alcance de campanhas pagas conforme a velocidade da página de destino, sites lentos perdem não só no orgânico. Perdem também no pago.

Se o seu site depende de tráfego do Google para gerar leads e vendas, entender essas três métricas deixou de ser opcional. Faz parte do mínimo para continuar competitivo.

O que são as Core Web Vitals (e o que cada uma mede)

As Core Web Vitals são três métricas criadas pelo Google para quantificar, com números, o que significa "boa experiência" em uma página web. Elas não medem abstração. Medem o que o usuário realmente sente ao abrir e usar o site no celular, na rede 4G, com a página ainda carregando.

Métrica	O que mede	Meta "boa" (verde)	Meta "precisa melhorar" (laranja)	Meta "ruim" (vermelho)
LCP: Largest Contentful Paint	Tempo até o maior elemento visível (imagem, banner, bloco de texto) aparecer	até 2,5 s	2,5 a 4 s	acima de 4 s
INP: Interaction to Next Paint	Latência de resposta às interações (clique, toque, digitação)	até 200 ms	200 a 500 ms	acima de 500 ms
CLS: Cumulative Layout Shift	Quanto a página "pula" enquanto carrega (elementos que mudam de lugar)	até 0,1	0,1 a 0,25	acima de 0,25

LCP: o tempo até "o site apareceu"

O LCP marca o momento em que o usuário percebe que a página "chegou". Geralmente é quando a imagem principal ou o bloco de texto do topo é renderizado. Se esse momento passa de 2,5 segundos no celular, a sensação já é de lentidão. Acima de 4 segundos, o usuário está prestes a desistir.

Os culpados mais comuns de um LCP alto:

Imagens do hero (banner principal) gigantes: JPG de 4 MB enviado direto da câmera, sem compressão nem formato moderno (WebP/AVIF)
Sem prioridade de carregamento: a imagem mais importante da página não recebe fetchpriority="high" ou preload
Servidor lento na primeira resposta: hospedagem compartilhada barata, sem cache, gerando o HTML no momento da requisição
CSS e JavaScript bloqueando a renderização: arquivos pesados no <head> que travam o pintar da tela

INP: o tempo até "o site respondeu"

O INP é a métrica que substituiu o FID em março de 2024 e é, hoje, a que mais derruba sites em ferramentas como o PageSpeed Insights. O FID media só a primeira interação. O INP mede todas as interações durante toda a visita e considera a pior (tecnicamente, a que quase foi a pior). Um único botão lento compromete a pontuação da página inteira.

Sites com INP ruim costumam ter:

JavaScript pesado rodando na thread principal: bibliotecas de animação, sliders, trackers que travam o navegador quando o usuário clica
Manipulação de DOM cara: cliques que re-renderizam grandes partes da página sem otimização
Event listeners mal posicionados: capturando interações em elementos que não precisavam
Frameworks sem hydration adequada: sites renderizados no servidor, mas que precisam "hidratar" todo o JavaScript no cliente antes de responder

A meta de 200 ms é dura. Ao tocar em um botão, o feedback visual precisa aparecer em menos de um quinto de segundo. Em sites WordPress com muitos plugins, esse número facilmente passa de 600 ms.

CLS: o tempo até "o site parou de pular"

O CLS mede a instabilidade visual. Aquele comportamento irritante em que você vai clicar em um botão e, no último milissegundo, um banner empurra tudo para baixo e você clica no lugar errado. Ou quando o texto salta três vezes enquanto as imagens carregam.

Causas típicas de CLS alto:

Imagens e vídeos sem dimensões definidas: o navegador reserva espaço só depois de saber o tamanho, e se o atributo width/height falta, tudo abaixo reorganiza
Anúncios e banners injetados dinamicamente: empurram o conteúdo quando aparecem
Fontes web carregadas de forma assíncrona sem fallback: o texto troca de tamanho quando a fonte personalizada finalmente carrega (FOUT/FOIT)
Conteúdo injetado no topo: um cookie banner ou popup que empurra o conteúdo principal para baixo

O CLS é a métrica mais barata de corrigir. Na maioria dos casos, basta definir dimensões nas imagens e reservar espaço para banners.

Por que velocidade vira venda (e não só ranking)

O impacto das Core Web Vitals vai além do Google. Ele atinge diretamente a conversão. É aqui que o problema deixa de ser técnico para virar financeiro.

Estudos recorrentes da indústria mostram um padrão:

Cada 100 ms de atraso no carregamento reduz a conversão em torno de 1% em e-commerces (dados da Amazon já antigos, mas replicados por Walmart, Deloitte e Google)
Sites que passam de 1s para 3s de carregamento têm 32% mais bounce rate
Páginas com INP acima de 500 ms têm taxa de conversão até 15% menor que páginas com INP abaixo de 200 ms
Em mobile, onde mais de 60% das buscas acontecem no Brasil, o efeito é amplificado pela rede instável

A velocidade é a primeira impressão. Antes de ler o título, antes de avaliar a proposta, o usuário já formou uma opinião sobre a empresa baseado em quão rápido a página apareceu. Site lento transmite desleixo. Site que pula transmite amadorismo. Site que não responde ao toque transmite "isso aqui está quebrado".

O Google sabe disso. Por isso as Core Web Vitals são um sinal de ranking. Não o mais forte, mas um critério de desempate entre páginas com conteúdo equivalente. Quando dois sites respondem igualmente bem à busca do usuário, o mais rápido ganha a posição.

Como otimizar: o checklist prático

A maioria dos problemas de Core Web Vitals se resolve com um conjunto repetível de ações. Não tem bala de prata. Tem método.

Para o LCP (carregamento):

Comprima imagens e converta para WebP ou AVIF (redução de 30 a 50% no peso sem perda visível)
Adicione fetchpriority="high" e preload à imagem principal do topo
Use CDN para entregar imagens e arquivos estáticos próximos ao usuário
Ative cache no servidor e gere HTML estático quando possível (SSG)
Reduza JavaScript no caminho crítico: adie scripts não essenciais com defer

Para o INP (interatividade):

Reduza o tamanho do bundle JavaScript. Audite bibliotecas não usadas
Divida o código em chunks carregados sob demanda (code splitting)
Mova tarefas longas para Web Workers quando possível
Use requestIdleCallback para adiar trabalho não essencial
Avalie frameworks com renderização hidratada parcial (React Server Components, por exemplo)

Para o CLS (estabilidade visual):

Defina width e height (ou aspect-ratio no CSS) em todas as imagens e vídeos
Reserve espaço para anúncios e banners com placeholders de tamanho fixo
Evite injetar conteúdo no topo da página depois do carregamento
Use font-display: swap e pré-carregue fontes web críticas

Para medir:

PageSpeed Insights: relatório completo com dados de laboratório e campo
Google Search Console: mostra as Core Web Vitals reais dos visitantes ao longo do tempo
Lighthouse: auditoria técnica detalhada no Chrome DevTools
Core Web Vitals no Chrome UX Report: dados agregados de experiência real

Meça, corrija os três maiores gargalos, meça de novo. Em quatro ciclos, a maioria dos sites sai do vermelho para o verde.

Como a Work Technology pode ajudar

Site rápido não é acidente. É consequência de escolhas técnicas desde a arquitetura. A Work Technology desenvolve e otimiza sites com performance como requisito, não como bônus:

Sites institucionais e landing pages construídos para velocidade: Next.js com renderização estática, imagens otimizadas automaticamente, JavaScript mínimo no cliente
Diagnóstico de Core Web Vitals: analisamos seu site atual no PageSpeed Insights e no Search Console, identificamos os gargalos e entregamos um plano de correção priorizado
Otimização de imagens e assets: conversão para formatos modernos, CDN, lazy loading e dimensões definidas em todo o conteúdo
Migração para arquitetura performática: saída de WordPress lento para stacks modernas com SSG/SSR, sem perder conteúdo nem SEO
Monitoramento contínuo: acompanhamos as métricas no Search Console e intervimos antes que uma atualização do Google derrube seu posicionamento

Se seu site leva mais de 3 segundos para abrir, pula quando carrega ou trava quando o usuário clica, ele está perdendo leads e posições no Google agora. Não no próximo trimestre. Solicite uma auditoria gratuita de Core Web Vitals e receba um diagnóstico do que está pesando contra o seu negócio e como corrigir.