Porque o Google e o visitante medem a mesma coisa: quanto o site demora para mostrar o conteúdo, responder ao toque e parar de pular. Um site bonito que falha nisso perde para um simples que passa. A boa notícia é que beleza e velocidade não são opostas.
O que são os Core Web Vitals em 2026?
São as três métricas de experiência que o Google usa como referência. O LCP mede quando o maior elemento visível aparece. O INP mede quanto a página demora para reagir a cliques, toques e teclas. O CLS mede quanto o layout se mexe sozinho.
O INP é a mudança mais recente: virou Core Web Vital estável em 12 de março de 2024, no lugar do antigo FID (web.dev, março de 2024). A diferença importa para site animado. O FID olhava só a primeira interação; o INP observa as interações da visita inteira e reporta a mais lenta, descontando valores fora da curva (web.dev, setembro de 2025).
Core Web Vitals contam para o SEO?
Contam, mas não sozinhos. A documentação do Google afirma que os Core Web Vitals são usados pelos sistemas de ranking e, na mesma página, que a busca sempre tenta mostrar o conteúdo mais relevante, mesmo quando a experiência de página é fraca (Google Search Central, setembro de 2026).
Velocidade não salva conteúdo ruim, mas desempata entre boas respostas. E o visitante não espera o desempate: se a página trava no primeiro toque, ele volta para a busca.
Por que o site bonito trava?
Quase nunca é a beleza. É onde ela foi construída. Animar top, left, width ou height obriga o navegador a recalcular o layout a cada quadro; animar transform e opacity vai direto para a etapa de composição. No exemplo do guia de animações do web.dev, a versão com top e left perdeu 50% dos quadros e a versão com transform, 1% (web.dev, outubro de 2020).
O resto é peso mal distribuído: imagem de herói enorme, biblioteca 3D baixada antes do texto, fonte que troca de tamanho, chat e pixels disputando a thread principal. Construtores visuais somam código que você não controla, como comparamos em Wix, Framer, Webflow ou site sob medida.
| Métrica | Limite bom | O que costuma estragar | Como consertar |
|---|---|---|---|
| LCP (carregamento) | até 2,5 s | imagem de herói pesada, fonte bloqueando o texto, abertura encenada que esconde o conteúdo | imagem em formato moderno e no tamanho da tela, pré-carregar o elemento principal, mostrar o texto logo |
| INP (resposta) | até 200 ms | JavaScript longo no clique, scripts de terceiros, 3D compilando na thread principal | dividir tarefas longas, adiar terceiros, carregar o 3D depois do primeiro quadro |
| CLS (estabilidade) | até 0,1 | imagem e vídeo sem dimensão, troca de fonte, banner inserido acima do conteúdo | reservar espaço com largura e altura, fonte de fallback com métrica parecida, nada entra acima do que já está na tela |
Fontes: limites em web.dev, outubro de 2024; causas de CLS na documentação de CLS do web.dev, consultada em outubro de 2026; LCP ruim acima de 4 s e elementos que contam em web.dev, setembro de 2025. Colunas de conserto: prática da Brave Cross.
O que a nossa própria home mostra?
Medimos a home da Brave Cross, que tem um monólito em 3D, com o Lighthouse em modo laboratório, celular emulado e CPU quatro vezes mais lenta, numa única execução. É medição de laboratório da Brave Cross em outubro de 2026, não dado de campo.
4,6 s
LCP da home, acima do limite bom de 2,5 s
medição de laboratório da Brave Cross, out/2026
30 ms
Total Blocking Time: a thread principal fica livre mesmo com 3D
medição de laboratório da Brave Cross, out/2026
0
CLS: nada pula na tela
medição de laboratório da Brave Cross, out/2026
404 KB
peso total do primeiro carregamento, em 24 requisições
medição de laboratório da Brave Cross, out/2026
O número ruim tem causa conhecida. O elemento de LCP é o texto do herói, que entra desfocado por uma cortina de abertura de cerca de 1,2 s. A cortina adia o LCP de propósito: trocamos velocidade medida por uma entrada encenada, ideia que defendemos em O intervalo é o produto. É uma escolha de projeto, e está na lista para revisar, porque acima de 4 s o web.dev já classifica o LCP como ruim.
O resto da medição mostra que o peso do 3D não é o vilão. Nenhum modelo .glb é baixado no primeiro quadro no celular; o visitante vê um pôster de 9 KB e o monólito entra depois. O Lighthouse não mede quadros por segundo, então não afirmamos fps como resultado: o 3D é projetado para 60 fps, e o que isso exige está em Site 3D pesa?. E o INP real só aparece nos dados de campo.
Como animar sem travar?
O checklist que aplicamos nos nossos sites:
Só transform e opacity
Animações contínuas mexem apenas nessas duas propriedades, nunca em sombra, largura ou posição.
Canvas adiado
O 3D e o WebGL carregam depois do primeiro quadro, com um pôster leve no lugar.
Fontes sob controle
Poucas famílias, com fallback de métrica parecida para não pular texto.
Terceiros depois
Chat, pixels e analytics entram após a primeira interação ou alguns segundos.
Espaço reservado
Toda imagem, vídeo e canvas tem largura e altura declaradas antes de carregar.
Reduzir movimento
Com prefers-reduced-motion ligado, o site troca deslocamentos por dissolução em vez de congelar.
O último item também é acessibilidade: movimento excessivo incomoda quem tem sensibilidade vestibular, tema que tratamos em Acessibilidade digital e a NBR 17225. E conteúdo que aparece sem depender de JavaScript ajuda buscadores e IAs a ler a página, como explicamos em Site preparado para IA.
Como medir os Core Web Vitals do seu site?
Use o PageSpeed Insights. Ele mostra dois blocos diferentes: os dados de campo, de visitantes reais do Chrome nos últimos 28 dias, e os dados de laboratório, do Lighthouse em condições fixas (PageSpeed Insights, outubro de 2024). A página passa quando o percentil 75 das três métricas fica no nível bom. Se discordam, o campo diz se você passa; o laboratório ajuda a achar a causa.
Perguntas frequentes
O que é INP?
INP, Interaction to Next Paint, mede quanto a página demora para mostrar uma resposta visual depois de um clique, toque ou tecla, considerando as interações da visita inteira. Até 200 ms é bom, de 201 a 500 ms precisa melhorar e acima de 500 ms é ruim, segundo o web.dev, setembro de 2025. Substituiu o FID em março de 2024.
Core Web Vitals ainda contam para o Google em 2026?
Sim. A documentação de experiência de página do Google, atualizada em setembro de 2026, diz que os Core Web Vitals são usados pelos sistemas de ranking. Ela também deixa claro que relevância vem primeiro: velocidade pesa mais quando várias páginas boas disputam a mesma busca.
Site com animação e 3D pode passar nos Core Web Vitals?
Pode, se o movimento for construído para isso: animar só transform e opacity, carregar o 3D depois do primeiro quadro, reservar espaço para tudo que carrega e adiar scripts de terceiros. Na medição de laboratório da Brave Cross em outubro de 2026, a home com 3D teve CLS 0 e 30 ms de bloqueio; o ponto fraco foi o LCP, causado pela cortina de abertura.
Qual a diferença entre PageSpeed Insights e Lighthouse?
O Lighthouse roda um teste de laboratório, em condições fixas, e serve para diagnosticar. O PageSpeed Insights mostra esse teste e, quando há tráfego suficiente, os dados de campo de visitantes reais dos últimos 28 dias. Para saber se o site passa nos Core Web Vitals, vale o bloco de campo.
Site lento perde clientes?
Perde a chance de ser visto e usado. O Google considera os Core Web Vitals na experiência de página, e quem toca num botão que não responde tende a sair antes de ler a oferta. Por isso velocidade entra no orçamento de um projeto, como mostramos em quanto custa um site profissional.
Meça antes de enfeitar
O site bonito ganha quando a beleza não cobra do visitante. Medir LCP, INP e CLS antes de aprovar o layout evita a surpresa depois de publicar. Se o seu site já falha nos três, veja os sinais de que ele precisa de redesign antes de decidir.
Se quiser um site com movimento que abre rápido, ou entender por que o seu trava, fale com a gente pela página de contato.