Qual nota mínima o Google exige nos Core Web Vitals para não penalizar um site?

O Google não opera com uma nota mínima de corte que ative uma penalização discreta: os Core Web Vitals são um sinal de ranqueamento contínuo, não um limite binário. Ainda assim, superar os limites "bom" (LCP < 2,5 s, INP < 200 ms, CLS < 0,1) tem impacto positivo no posicionamento orgânico, especialmente em mercados competitivos e em buscas no celular. Uma nota alta no PageSpeed Insights de laboratório não garante que seus dados de campo (Chrome UX Report) sejam bons: o que o Google usa em seus sinais de ranqueamento são os dados reais de usuários.

Quanto custa otimizar os Core Web Vitals em um site WordPress?

A faixa varia conforme a complexidade do site e quantas causas raiz precisam ser resolvidas. Uma auditoria técnica de CWV costuma custar entre USD 100–300; a otimização completa de imagens, cache e scripts em um site sem customizações pesadas se resolve entre USD 500–2.000. Se o problema raiz é o tema (page builder pesado) ou a hospedagem, a solução envolve um refactor de tema ou substituição do stack, oscilando entre USD 2.000 e USD 5.000+ conforme o escopo.

Em quanto tempo as melhorias de Core Web Vitals aparecem no Google?

Os dados de campo que o Google usa em seus sinais de ranqueamento vêm do Chrome UX Report (CrUX), que acumula 28 dias de dados reais de usuários. Isso significa que mudanças feitas hoje só aparecem no relatório do CrUX cerca de um mês depois. No PageSpeed Insights você verá a melhora dos dados de laboratório imediatamente; no Google Search Console (relatório de Experiência da página) e no CrUX, o impacto leva entre 4 e 8 semanas para se consolidar.

O que fazer se o tema for a causa principal dos meus problemas de CWV?

Se o diagnóstico confirma que o tema é a causa (por exemplo: Elementor, Divi ou Avada adicionando mais de 15–20 recursos bloqueantes por página), você tem três opções ordenadas por impacto: (1) trocar para um tema nativo de blocos do Gutenberg ou um tema leve como Astra ou GeneratePress e reconstruir os templates; (2) aplicar carregamento condicional de scripts (Asset CleanUp, Perfmatters) para reduzir o JavaScript do page builder apenas nas páginas que o utilizam; (3) se o site é estratégico e o tráfego orgânico está em risco, avaliar uma migração para um stack fora do WordPress. A opção certa depende do orçamento e do volume de tráfego.

Qual das três métricas de Core Web Vitals devo priorizar?

Na maioria dos sites WordPress, o LCP é a métrica que falha com mais frequência e a que mais impacta a percepção de velocidade pelo usuário: se a imagem ou o bloco principal demora mais de 2,5 segundos para aparecer, o usuário já foi embora. Comece sempre pelo LCP — otimização de imagens, TTFB da hospedagem e eliminação de recursos bloqueantes. Quando o LCP estiver no verde, ataque o INP (scripts de terceiros e JS bloqueante) e depois o CLS (dimensões de imagens e fontes). Se as três falham ao mesmo tempo, o problema costuma ser a hospedagem ou o tema: resolver a raiz melhora as três métricas de uma vez.

Core Web Vitals no WordPress: o guia 2026

Q: Quanto custa otimizar os Core Web Vitals em um site WordPress?

A faixa varia conforme a complexidade do site e quantas causas raiz precisam ser resolvidas. Uma auditoria técnica de CWV costuma custar entre USD 100–300; a otimização completa de imagens, cache e scripts em um site sem customizações pesadas se resolve entre USD 500–2.000. Se o problema raiz é o tema (page builder pesado) ou a hospedagem, a solução envolve um refactor de tema ou substituição do stack, oscilando entre USD 2.000 e USD 5.000+ conforme o escopo.

Q: Em quanto tempo as melhorias de Core Web Vitals aparecem no Google?

Os dados de campo que o Google usa em seus sinais de ranqueamento vêm do Chrome UX Report (CrUX), que acumula 28 dias de dados reais de usuários. Isso significa que mudanças feitas hoje só aparecem no relatório do CrUX cerca de um mês depois. No PageSpeed Insights você verá a melhora dos dados de laboratório imediatamente; no Google Search Console (relatório de Experiência da página) e no CrUX, o impacto leva entre 4 e 8 semanas para se consolidar.

Q: O que fazer se o tema for a causa principal dos meus problemas de CWV?

Se o diagnóstico confirma que o tema é a causa (por exemplo: Elementor, Divi ou Avada adicionando mais de 15–20 recursos bloqueantes por página), você tem três opções ordenadas por impacto: (1) trocar para um tema nativo de blocos do Gutenberg ou um tema leve como Astra ou GeneratePress e reconstruir os templates; (2) aplicar carregamento condicional de scripts (Asset CleanUp, Perfmatters) para reduzir o JavaScript do page builder apenas nas páginas que o utilizam; (3) se o site é estratégico e o tráfego orgânico está em risco, avaliar uma migração para um stack fora do WordPress. A opção certa depende do orçamento e do volume de tráfego.

Q: Qual das três métricas de Core Web Vitals devo priorizar?

Na maioria dos sites WordPress, o LCP é a métrica que falha com mais frequência e a que mais impacta a percepção de velocidade pelo usuário: se a imagem ou o bloco principal demora mais de 2,5 segundos para aparecer, o usuário já foi embora. Comece sempre pelo LCP — otimização de imagens, TTFB da hospedagem e eliminação de recursos bloqueantes. Quando o LCP estiver no verde, ataque o INP (scripts de terceiros e JS bloqueante) e depois o CLS (dimensões de imagens e fontes). Se as três falham ao mesmo tempo, o problema costuma ser a hospedagem ou o tema: resolver a raiz melhora as três métricas de uma vez.

Se você abriu o PageSpeed Insights e viu três luzes vermelhas, este artigo é para você. Os Core Web Vitals WordPress são três métricas que o Google usa como sinal de ranqueamento, e falham quase sempre pelas mesmas quatro causas: tema pesado, plugins acumulados, imagens sem otimização e scripts de terceiros bloqueantes. Este guia traz o diagnóstico por causa raiz, os limites atualizados para 2026 (com INP no lugar do FID) e um plano priorizado por impacto, não por complexidade técnica.

Não é um guia plugin-cêntrico. Se o problema é a hospedagem ou o tema e nenhum plugin vai resolver, também digo isso.

O que são os Core Web Vitals em 2026? (e o que mudou com o INP)

Os Core Web Vitals são três métricas de experiência do usuário que o Google publica como parte de seus sinais de ranqueamento: medem velocidade de carregamento, capacidade de resposta a interações e estabilidade visual. Em 2026 as três métricas oficiais são LCP, INP e CLS — não FID. Se você ler um guia que ainda fala em FID, está desatualizado.

LCP, INP e CLS: tabela de limites e o que cada métrica mede

Métrica	O que mede	Limite “bom”	Causa mais comum no WordPress
LCP (Largest Contentful Paint)	Tempo até que o maior elemento visível seja renderizado (geralmente a imagem hero ou o `<h1>`)	≤ 2,5 s	Imagem hero sem otimização, TTFB alto da hospedagem, tema pesado
INP (Interaction to Next Paint)	Latência entre a primeira interação do usuário (clique, toque, tecla) e o momento em que o navegador pinta a resposta	≤ 200 ms	JavaScript de plugins (page builders, widgets de chat, analytics)
CLS (Cumulative Layout Shift)	Soma dos deslocamentos visuais inesperados durante a vida da página	≤ 0,1	Imagens sem `width`/`height`, anúncios ou embeds que carregam tarde, fontes que provocam FOUT

As definições canônicas e os limites estão em web.dev/articles/vitals. Qualquer número diferente que você veja circulando em blogs antigos está obsoleto.

Por que o INP substituiu o FID em março de 2024 — e o que isso significa para o seu WordPress

Em março de 2024 o Google substituiu o First Input Delay (FID) pelo Interaction to Next Paint (INP) como métrica oficial. O motivo: o FID só media a primeira interação e apenas o atraso inicial, dando notas enganosamente boas em sites cujo JavaScript travava depois do primeiro clique. O INP mede todas as interações da sessão e reporta o pior quantil. A documentação oficial está em web.dev/articles/inp.

Para o WordPress isso muda as prioridades: muitos sites passavam no FID porque o primeiro clique acontecia antes de o JS pesado do page builder terminar de executar. Com o INP, se o visitante interage com um menu ou um formulário e o thread principal está ocupado parseando o JS do Elementor ou do Tawk.to, a métrica falha. O INP castiga o que o FID disfarçava.

Como medir seus Core Web Vitals no WordPress?

Antes de mexer em qualquer coisa, meça. O erro mais caro em otimização de WordPress é perseguir uma nota Lighthouse de 100 que não se traduz em melhorias reais para o Google. O que ranqueia são os dados de campo, não os de laboratório.

Dados de campo vs. dados de laboratório: a diferença que muda o diagnóstico

Essa distinção separa quem otimiza com critério de quem otimiza por impulso. Há dois tipos de dados:

Dados de laboratório (lab data): são simulações controladas. O Lighthouse e a aba “Diagnóstico” do PageSpeed Insights executam sua página em um ambiente virtual com CPU e rede emuladas. Servem para diagnóstico técnico e para validar o efeito imediato de uma mudança. Não são o sinal de ranqueamento do Google.
Dados de campo (field data): são métricas reais de usuários reais medidas pelo Chrome UX Report (CrUX) sobre os últimos 28 dias. O PageSpeed Insights os mostra no bloco superior (“Descubra o que seus usuários reais estão experimentando”). Esses são os que o Google usa para ranqueamento — e os únicos que aparecem no Google Search Console.

Implicação prática: você pode ter o Lighthouse no verde e o CrUX no vermelho (porque sua hospedagem tem picos de TTFB que o lab não captura), ou vice-versa. Se o Search Console marca URLs com problemas de CWV, são os dados de campo que falham, e suas mudanças não vão se refletir até que passem 28 dias de tráfego real sob a versão otimizada. Fonte oficial: Google Search Central.

PageSpeed Insights, Search Console e Web Vitals Extension: quando usar cada um

PageSpeed Insights (pagespeed.web.dev) — ponto de partida obrigatório. Mostra campo e laboratório na mesma tela. Use para auditar URLs específicas.
Google Search Console → Experiência da página → Core Web Vitals — a fonte de verdade sobre quais URLs falham em produção. Apenas dados de campo. Use para priorizar.
Web Vitals Extension do Chrome — gratuita, mede CWV em tempo real enquanto você navega. Útil para depurar INP em fluxos reais (menus, formulários, modais).
Lighthouse no DevTools — diagnóstico técnico profundo. Não olhe a nota; olhe “Oportunidades” e “Diagnóstico”.

As 4 causas mais comuns para falhar nos Core Web Vitals WordPress

Em um diagnóstico típico, as causas raiz se dividem entre quatro frentes. Identificar qual pesa mais no seu site evita que você gaste tempo otimizando o que não move o ponteiro.

Causa 1 — Tema pesado ou page builder. Elementor, Divi e WPBakery adicionam entre 15 e 30 recursos bloqueantes por página mesmo quando só alguns blocos são usados. Castiga o LCP (CSS bloqueante no head) e o INP (JS pesado do builder ocupando o thread principal).

Causa 2 — Plugins acumulados. Cada plugin que registra um script em wp_enqueue_scripts o carrega em todas as páginas por padrão, mesmo que só seja usado em uma. Um site com 40 plugins pode injetar 25 scripts e 15 folhas de estilo na home, mesmo precisando só de cinco.

Causa 3 — Imagens sem otimização. Sem WebP/AVIF, sem lazy loading, sem atributos width/height, sem srcset. Causa número um de LCP ruim (hero de 1,8 MB) e muito comum em CLS (a imagem aparece de uma vez e empurra o conteúdo).

Causa 4 — Scripts de terceiros bloqueantes. Widgets de chat (Tawk, Crisp, Intercom), pixels de marketing, AdSense. Carregam síncronos no <head> e consomem o thread principal antes de o usuário poder interagir. Atacam o INP.

Plano de ação priorizado: o que arrumar primeiro e o que esperar

A ordem importa. Otimizar imagens em um site com TTFB de 1,8 s é como pintar paredes de uma casa com goteiras. Faça assim:

Hospedagem e TTFB primeiro. Meça o TTFB no PageSpeed Insights. Se estiver acima de 600 ms em medições repetidas, o problema é o servidor — nenhum plugin resolve. O monitoramento de CWV faz parte de um plano de manutenção sério: revise o guia de manutenção WordPress para empresas.
Imagens depois. WebP ou AVIF, lazy loading nativo (loading="lazy" exceto na imagem LCP), atributos width/height sempre, srcset responsivo. Plugins: ShortPixel, Imagify, EWWW. Costuma derrubar o LCP entre 30 e 60 % em uma única intervenção.
Cache e minificação. WP Rocket se você tem orçamento (USD 59/ano), LiteSpeed Cache se sua hospedagem é LiteSpeed (gratuito), W3 Total Cache ou Cache Enabler como alternativas. O cache ataca o TTFB nas visitas seguintes; a minificação reduz CSS/JS.
Scripts de terceiros por último. Carregamento adiado de widgets de chat (após 5 s ou após scroll), pixels no GTM com gatilhos atrasados, AdSense com requestIdleCallback. Isso ataca o INP diretamente.

Faixas de investimento 2026

Para você saber o que esperar antes de pedir orçamentos:

Auditoria técnica com relatório acionável: USD 100–300. Identifica as causas raiz e em que ordem atacá-las. Sem executar mudanças.
Otimização completa (imagens, cache, minificação, scripts adiados): USD 500–2.000. Cobre a maioria dos sites de PME sem customizações pesadas. Resultado típico: as três métricas no verde em laboratório, melhora em campo em 4–8 semanas.
Refactor de tema ou troca de page builder: USD 2.000–5.000+. Quando o tema (Avada, Divi, WPBakery sobre um site grande) é a causa raiz e a única saída é reconstruir templates em um tema leve ou Gutenberg nativo.

Quando o problema é o tema (e não os plugins nem a hospedagem)

Se você já otimizou imagens, instalou cache, adiou scripts e migrou para uma hospedagem decente, e mesmo assim o LCP e o INP continuam vermelhos, o suspeito é o tema. Três sinais: (a) o PageSpeed Insights reporta mais de 200 KB de JavaScript não usado do tema ou do builder; (b) “Reduza o trabalho do thread principal” do Lighthouse atribui mais de 2 s a scripts do builder; (c) a home carrega mais de 15 CSS distintos do tema.

Em 2026 os temas que cumprem CWV sem acrobacias são Astra, GeneratePress, Blocksy e Kadence: leves, baseados em Gutenberg ou com builder próprio otimizado, com menos de 50 KB de CSS/JS críticos por página. Trocar de tema implica reconstruir templates; não é operação de 30 minutos, mas em sites grandes paga a diferença em semanas.

Há um cenário em que o tema deixa de ser a alavanca: quando o site cresce além do que o WordPress sustenta sob pressão. Se um WooCommerce com 5.000+ SKUs te entrega TTFB de 2 s no horário de pico mesmo com hospedagem managed, o problema já não é o tema — é o stack.

Vale a pena migrar para um stack mais rápido? Quando sim e quando não

A pergunta honesta de fechamento. Migrar para fora do WordPress (para Astro, Next.js ou um headless com o WordPress como CMS e frontend estático) pode levar o LCP a sub-1 s e deixar o INP em 50 ms sem esforço. A contrapartida: custo, complexidade e a perda da edição visual ao vivo que sua equipe conhece.

Três sinais de que a otimização chegou ao teto na sua instalação: (1) você já investiu mais de USD 3.000 e os dados de campo continuam em amarelo; (2) o TTFB no horário de pico não cai abaixo de 800 ms nem trocando de hospedagem; (3) cada plugin novo devolve uma métrica para o vermelho. Nesses casos, a migração se paga em 12–18 meses entre economia de hospedagem, conversão recuperada e SEO técnico.

Na Overnatic, primeiro diagnosticamos antes de propor qualquer ação: uma auditoria de 2–3 horas esclarece se seu site precisa de otimização, refactor de tema ou migração de stack — e raramente é o que o cliente esperava. Se quiser revisar opções, veja nossos serviços e nos conte o caso.