Sua loja sem fila: quando a vitrine chama, mas o caixa trava, o cliente desiste. Um site lento faz o mesmo. A diferença é que online você nem vê a pessoa indo embora. É por isso que performance virou assunto de crescimento, não só de TI.
Core Web Vitals no centro: o Google continua olhando para experiência real de quem visita. As três métricas — LCP, INP e CLS — medem carregamento, resposta e estabilidade. Em muitos mercados, ainda há espaço para ganhar vantagem: segundo o Web Almanac 2025 (via Nimbus Digital), só 48% das páginas mobile e 56% das desktop passam nas três ao mesmo tempo. Isso abre oportunidade para quem trata Core Web Vitals como rotina de produto.
Onde muita gente erra: perseguir nota 100 no Lighthouse, instalar plugins milagrosos e ignorar dados de campo. O score 0–100 não é usado pelo Google para ranquear e pode mascarar gargalos que só aparecem na navegação real, como picos de INP e saltos de layout — assunto recorrente em guias técnicos sérios como o SEO Handbook.
O que você vai levar: um mapa prático, direto ao ponto. Vamos ver o que medir de verdade, o que pode ser deixado de lado, como ler dados de campo no Search Console, correções que mais movem o ponteiro no WordPress e quando trocar de hospedagem. A ideia é tirar ruído da pauta e colocar melhorias que geram tráfego, conversão e uma experiência que o Google reconhece.
As três métricas que contam e o que cada uma mede de verdade
O resumo rápido: são três sinais que você sente na pele: LCP mede carregamento, INP mede resposta e CLS mede estabilidade. Em 2026, os Limiares 2026 oficiais seguem iguais: LCP ≤ 2,5s, INP ≤ 200ms e CLS ≤ 0,1, avaliados no 75º percentil (p75) de visitas reais em janela móvel de 28 dias.
LCP na prática: renderização do maior bloco, servidor, imagens e CSS crítico
LCP mede carregamento: é o tempo até o maior elemento visível (geralmente a hero image ou um bloco grande de texto) aparecer por completo.
Na prática, o LCP sofre com TTFB alto (servidor lento), imagens pesadas e CSS bloqueando a renderização. Ferramentas dividem o LCP em partes como atraso de rede, tempo de download e render delay, o que ajuda a achar o gargalo. Se a hero image vem sem preload ou está enorme, o LCP estoura; se o CSS crítico não está inline, a pintura atrasa.
INP além do clique: input delay, processamento e pintura da próxima tela
INP mede resposta: é o atraso entre sua ação (clique, toque, tecla) e a próxima pintura visível. Ele substituiu o FID em março de 2024.
O INP considera três partes: input delay (fila ocupada), tempo de execução do event handler e a apresentação (pintura). Rolagem não conta. Em páginas com muitas interações, a medição usa um recorte alto para ignorar ruído. Se o main thread está preso com scripts, menus demoram a abrir e o INP piora.
CLS real: mudanças de layout, fontes, banners e como medir corretamente
CLS mede estabilidade: ele soma os saltos de layout que você não esperava durante o carregamento. O cálculo pesa o quanto da tela se moveu e a distância do movimento.
As causas comuns são imagens sem dimensões, fontes web sem font-display swap, banners que empurram o conteúdo e componentes que montam tarde. O alvo bom é ≤ 0,1; acima de 0,25 é ruim. Corrigir envolve reservar espaço estático, usar placeholders e carregar fontes e anúncios sem empurrar nada.
Limiares 2026: LCP 2,5s, INP 200ms, CLS 0,1 (priorize mobile)
Limiares 2026 oficiais: LCP ≤ 2,5s (ruim > 4s), INP ≤ 200ms (ruim > 500ms) e CLS ≤ 0,1 (ruim > 0,25). A avaliação vale quando 75% das visitas estão no “bom”.
Esses números valem para dados de campo (CrUX) em janela de 28 dias. Olhe primeiro mobile, onde as redes variam mais e o impacto em SEO costuma ser maior. Um site pode marcar 90 no Lighthouse e ainda falhar no p75 real. É por isso que ajustes como preload de hero, CSS crítico e menos JavaScript costumam render os maiores ganhos.
Como medir com dados de campo, não só de laboratório
Dados de campo primeiro: para decidir se você passa, olhe o p75 em 28 dias do CrUX no Search Console. Use o PSI une campo + lab para uma URL e o DevTools para causa-raiz. Se precisar acompanhar de perto, implemente RUM com web-vitals.js sem pesar o site.
Search Console e CrUX: leitura do relatório por modelo de página
Comece pelo Search Console: ele mostra o CrUX agregado por grupos de URLs, que costumam refletir seus templates.
Separe mobile e desktop. Encontre o grupo que falha e escolha uma URL representativa para investigar. Lembre que o CrUX é uma média móvel de 28 dias, então mudanças levam semanas para aparecer. O objetivo é levar LCP ≤ 2,5s, INP ≤ 200ms e CLS ≤ 0,1 no 75º percentil de visitas reais.
PageSpeed Insights vs Lighthouse: quando confiar e quando desconfiar
PSI une campo + lab: no topo, você vê o campo (CrUX); abaixo, o laboratório (Lighthouse) com diagnósticos.
Use o campo para decidir prioridade e o laboratório para achar o porquê. Desconfie de “nota 100” com p75 ruim no CrUX. O Lighthouse roda em ambiente controlado e não capta interações pós-carregamento como picos de INP.
Janela móvel de 28 dias: impacto no tempo de recuperação de ranking
O relógio é do CrUX: o campo usa janela de 28 dias. Melhorias hoje entram no relatório gradualmente.
Planeje a comunicação: valide em laboratório no dia do deploy, monitore PSI nos dias seguintes e espere o ciclo fechar para ver impacto no Search Console e, só então, no ranqueamento. Foque primeiro em mobile, onde as redes variam mais.
RUM leve: medir INP e LCP com web-vitals.js sem pesar o site
Implemente RUM leve: use web-vitals.js para coletar LCP, INP e CLS em produção e enviar para seu analytics.
Carregue o script de forma assíncrona, amostre tráfego para não pesar. Isso flagra regressões por script (ex.: chat, tags de marketing) que só aparecem para usuários reais. Cruce esses dados com campanhas e páginas para priorizar correções.
Diagnóstico de causa-raiz: traços no DevTools e regressões por script
DevTools para causa-raiz: grave um trace na aba Performance para ver blocos no main thread, long tasks e mudanças de layout.
Compare antes e depois do deploy. Teste com e sem terceiros. Se um script trava o main thread, você verá no profiler. Reproduza o LCP vendo rede, imagens e CSS crítico; para INP, clique em elementos e observe o tempo até a próxima pintura.
As correções que mais movem o ponteiro no WordPress
O caminho curto para resultados: foque na imagem LCP otimizada, em Delay JS não crítico, em Cache em camadas e em baixar o TTFB abaixo de 600ms. Fontes com font-display: swap e menos variações seguram o CLS.
Imagens e fontes: pré-carregar, dimensionar, AVIF/WebP e exibição swap
Preload do LCP: pré-carregue a hero se ela for o LCP e use WebP/AVIF e srcset com width/height no markup.
Adicione fetchpriority=”high” na imagem LCP e nunca faça lazy-load dela. Converta imagens e limite heróis a ~300KB quando possível. Em fontes, prefira self-host, font-display: swap e só 1–2 pesos críticos; preloa os arquivos centrais e mantenha um fallback bem ajustado.
CSS/JS: remover bloat, dividir, deferir e isolar scripts de terceiros
JavaScript sob controle: minifique, divida bundles e aplique defer/delay em scripts não críticos; isole chat, mapas e pixels.
Use gerenciadores de assets para desligar CSS/JS onde o plugin não é usado. Gere Critical CSS inline e carregue o restante de forma assíncrona. Quebre long tasks > 50ms e reduza handlers de rolagem com debounce. Teste menus e formulários ao atrasar jQuery para não quebrar UX.
Cache em camadas: plugin + servidor + CDN com regras para HTML e API
Cache em camadas: habilite page cache para anônimos, objetos via Redis para consultas pesadas e CDN para edge.
Confirme HTML cacheado para visitantes logados-out. Defina TTLs longos para estáticos e invalide de forma granular. Em lojas, combine página + objeto e avalie cache no edge com regras para não quebrar carrinho e APIs dinâmicas.
INP sob controle: minimizar work no main thread e eventos problemáticos
Corte filas no main thread: remova scripts globais desnecessários e atrasar terceiros até interação; distribua trabalho em partes curtas.
Use DevTools para encontrar long tasks. Otimize handlers de clique, input e autocomplete. Evite animações pesadas em mobile. Para picos de INP, pare de carregar sliders e widgets em páginas que não usam esses recursos.
Plugins e temas: escolhas leves, FSE bem configurado e limpeza quinzenal
Menos, porém melhores: escolha tema leve, desative recursos que não usa e faça auditoria quinzenal de plugins.
Troque plugins pesados por alternativas focadas ou código sob medida. No FSE, evite blocos que injetam CSS/JS globalmente. Atualize para PHP 8.3+, ative OPcache e monitore regressões; cada ajuste leva semanas para refletir no p75 do CrUX.
Quando o problema é a hospedagem e não o site
Nem sempre é o seu código: quando o servidor não entrega, o site sofre. Se o TTFB alto persistente continua mesmo com cache e imagens otimizadas, é sinal de limite no provedor. Olhe CPU, memória e filas. Recursos apertados deixam tudo lento e jogam seu LCP para cima.
TTFB alto, CPU estourando e filas: sinais de gargalo no provedor
O alarme é o TTFB: se o tempo do primeiro byte segue alto em páginas cacheadas, há gargalo de CPU/IO ou fila de processos.
Métricas típicas: bom abaixo de 200 ms, aceitável abaixo de 800 ms; acima de 600 ms cacheado já indica problema de plataforma. Quedas sob pico e throttling em horários comerciais confirmam o quadro. Sem CPU livre e OPcache quente, cada request vira uma espera.
HTTP/2, HTTP/3, TLS 1.3 e brotli: o que o serviço precisa ter
O básico da pilha moderna: suporte a HTTP/2 e HTTP/3 e TLS 1.3, compressão Brotli para HTML/CSS/JS e keep-alive ativo.
HTTP/2 multiplexa e reduz conexões. HTTP/3 corta handshakes, ajuda muito em mobile. TLS 1.3 finaliza em menos idas e voltas. Brotli entrega arquivos menores que gzip. Sem isso, você paga latência extra a cada visita.
Edge + CDN no Brasil: latência menor e cache dinâmico com regras
Leve o conteúdo para perto: use CDN com PoPs no Brasil e ative cache de HTML para anônimos.
Sirva a imagem de LCP no edge. Configure TTLs e invalidação granular. Regras evitam cachear carrinho, checkout e APIs dinâmicas. A CDN reduz distância e melhora LCP; não corrige INP/CLS causados pelo front.
Quando migrar: limites do compartilhado, VPS gerenciado e object cache
Migre quando o teto bate: se o TTFB cacheado é alto, há quedas sob carga ou CPU vive no limite, troque de plano ou provedor.
De compartilhado para VPS gerenciado com NVMe, PHP 8.x, OPcache, e object cache (Redis). Em WordPress pesado ou WooCommerce, isso reduz consultas e filas. Com edge cache, quedas de 800+ ms para <200 ms são comuns.
Observabilidade: APM, logs lentos e testes de carga para decisões
Medir antes de mover: ative APM, colete slow logs e rode testes de carga leves.
Mapeie TTFB por região e horário. Conte queries por página, veja long tasks de PHP e gargalos de banco. Compare com e sem CDN. Registre o antes/depois: as melhorias aparecem no p75 em 28 dias no CrUX e no Search Console.
Quanto isso realmente pesa no ranqueamento
O peso real no ranking: Core Web Vitals contam, mas o impacto é moderado. Não vencem relevância e qualidade do conteúdo. Onde fazem diferença? Como desempate em buscas competitivas e como margem de experiência que melhora engajamento e receita. O Google considera o que usuários sentem em navegações reais, não a nota de laboratório, e as mudanças levam um tempo para refletir.
Quer transformar isso em ganho prático? Una medição de dados de campo com correções que movem LCP, INP e CLS e decisões certas de hospedagem/CDN. Peça um diagnóstico de Core Web Vitals com dados de campo na Mistura Tech: priorização objetiva, plano de ação enxuto e monitoramento contínuo para evitar regressões — do WordPress ao servidor.
Key Takeaways
Domine os Core Web Vitals em 2026 com foco no que o Google realmente mede e no que mais impacta ranking, experiência e receita:
- Meça o que importa: LCP ≤ 2,5s, INP ≤ 200ms e CLS ≤ 0,1, avaliados no p75 de dados de campo (CrUX) em janela móvel de 28 dias.
- Campo antes do laboratório: Search Console/CrUX definem o que conta para ranking; use PSI para cruzar campo + laboratório e Lighthouse apenas para diagnóstico.
- Peso moderado no ranking: É fator desde 2021 e atua como desempate; relevância e qualidade do conteúdo ainda pesam mais.
- Ganhos rápidos no WordPress: Preload da imagem LCP com fetchpriority=high, WebP/AVIF e CSS crítico inline; nunca aplique lazy-load na imagem LCP.
- Domine o INP: Corte trabalho no main thread, quebre long tasks (>50ms) e atrase scripts de terceiros até interação para reduzir latência.
- Cache em camadas: Page cache + object cache (Redis) + CDN com edge no Brasil para reduzir latência; mire TTFB entre <200–600 ms.
- Quando é a hospedagem: TTFB alto mesmo cacheado e CPU no limite indicam migração para VPS gerenciado com HTTP/2/3, TLS 1.3 e Brotli.
- Monitore regressões: RUM com web-vitals.js, revisão contínua no Search Console e validações no PSI; efeitos aparecem conforme o ciclo de 28 dias.
Trate Core Web Vitals como processo contínuo: medir em campo, priorizar correções que movem o ponteiro e blindar a performance contra regressões.
FAQ – Core Web Vitals em 2026
O que são Core Web Vitals?
São três métricas do Google que medem a experiência real do usuário: LCP (carregamento do maior conteúdo), INP (resposta às interações) e CLS (estabilidade visual). A avaliação usa dados de campo (CrUX) no 75º percentil, em uma janela móvel de 28 dias.
Core Web Vitals é fator de ranqueamento?
Sim. São um sinal de ranqueamento desde 2021 e continuam em 2026, com impacto moderado. Não superam relevância e qualidade do conteúdo, mas funcionam como desempate em buscas competitivas e influenciam engajamento.
Como melhorar o LCP do meu site?
Reduza TTFB (hospedagem/CDN), faça preload da imagem LCP com fetchpriority=high, use WebP/AVIF com dimensões no HTML, injetar CSS crítico inline e adiar o restante, não aplique lazy-load na imagem LCP e elimine bloqueios de JS.
Qual a diferença entre dados de laboratório e de campo?
Laboratório (Lighthouse) é simulado e serve para diagnóstico imediato. Campo (CrUX/Search Console) vem de usuários reais, no p75/28 dias, e é o que o Google usa para ranquear. Uma página pode ter nota 100 em lab e ainda falhar no campo.
Como testar os Core Web Vitals do meu site de graça?
Use PageSpeed Insights (pagespeed.web.dev) para ver dados de campo + laboratório por URL, o relatório Core Web Vitals no Google Search Console para visão do site inteiro e o Lighthouse nas DevTools do Chrome para depurar problemas.
