Core Web Vitals: Por Que Sites HTML Já Vencem no Google

Core Web Vitals são as métricas que o Google usa para medir a experiência real do usuário no seu site. Se você nunca ouviu falar nelas, saiba que Core Web Vitals podem ser a diferença entre aparecer na primeira página do Google ou ficar enterrado na terceira. E aqui vai a boa notícia: sites HTML estáticos têm uma vantagem natural e significativa nessas métricas, sem precisar de plugins, configurações complicadas ou horas de otimização.

Desde 2021, o Google incorporou essas métricas como fator de ranking. Isso significa que, entre dois sites com conteúdo equivalente, aquele que carrega mais rápido, responde melhor a interações e não "pula" visualmente durante o carregamento vai aparecer na frente. E sites HTML puros, por natureza, se encaixam perfeitamente nesses critérios.

Neste artigo, vamos explicar cada métrica em detalhes, comparar plataformas com dados reais e mostrar como você pode garantir nota máxima no PageSpeed Insights.

O que são Core Web Vitals

Core Web Vitals são um conjunto de três métricas criadas pelo Google para avaliar a experiência do usuário em uma página web. Elas não medem coisas abstratas — medem situações concretas que qualquer pessoa já viveu: uma página que demora para carregar, um botão que não responde ao clique, ou um texto que "pula" na tela enquanto a página carrega.

O Google coleta esses dados de usuários reais através do Chrome User Experience Report (CrUX). Isso significa que não basta o seu site ser rápido num teste de laboratório — ele precisa ser rápido para as pessoas que realmente o acessam, nos dispositivos e conexões que elas usam.

Antes de 2021, a velocidade do site já era um fator de ranking, mas de forma vaga. Com os Core Web Vitals, o Google formalizou exatamente o que mede e como mede. Três métricas, três thresholds, sem ambiguidade.

Para quem quer entender como o Google avalia sites de forma mais ampla, vale a pena também estudar como configurar corretamente as meta tags Open Graph, que complementam a otimização técnica com uma boa apresentação nas redes sociais.

As 3 métricas que o Google mede

LCP (Largest Contentful Paint)

O LCP mede o tempo que o maior elemento visível da página leva para ser renderizado. Pode ser uma imagem hero, um bloco de texto grande ou um vídeo. É a métrica mais intuitiva: quanto tempo o usuário espera até ver o conteúdo principal?

Os thresholds definidos pelo Google são:

Bom: menos de 2,5 segundos
Precisa melhorar: entre 2,5 e 4 segundos
Ruim: acima de 4 segundos

O que causa LCP ruim? Servidores lentos, CSS e JavaScript bloqueantes, imagens pesadas sem otimização e fontes web que demoram para carregar. Em um site HTML estático, o servidor simplesmente entrega o arquivo pronto — não há processamento no backend, não há consulta a banco de dados, não há fila de plugins para executar. O LCP de um site HTML bem feito fica, tipicamente, abaixo de 1 segundo.

Para manter o LCP baixo, uma prática essencial é comprimir imagens. O Compressor de Imagens do Htmly converte para WebP e reduz o tamanho sem perda visível de qualidade.

INP (Interaction to Next Paint)

O INP mede a responsividade do site a interações do usuário — cliques, toques e pressionamentos de tecla. Ele substituiu o FID (First Input Delay) em março de 2024 porque o FID só media a primeira interação, enquanto o INP avalia todas as interações durante a visita inteira e reporta o pior caso (percentil 98).

Os thresholds são:

Bom: menos de 200 milissegundos
Precisa melhorar: entre 200 e 500 milissegundos
Ruim: acima de 500 milissegundos

O que causa INP ruim? JavaScript pesado que bloqueia a thread principal. Frameworks SPA (Single Page Application) como React, Angular ou Vue, quando mal otimizados, podem congelar a interface por centenas de milissegundos durante uma interação. Sites WordPress com dezenas de plugins injetando scripts sofrem particularmente com isso.

Um site HTML estático com JavaScript mínimo tem INP praticamente zero. Não há framework renderizando componentes, não há estado global sendo recalculado, não há hydration travando a página. O navegador processa a interação e pinta o resultado em poucos milissegundos.

CLS (Cumulative Layout Shift)

O CLS mede a instabilidade visual da página. Quando você está lendo um texto e de repente ele pula para baixo porque um banner carregou acima, isso é um layout shift. Quando você vai clicar num botão e ele se move porque uma imagem acima finalmente renderizou, isso também é um layout shift. É frustrante.

Os thresholds são:

Bom: menos de 0,1
Precisa melhorar: entre 0,1 e 0,25
Ruim: acima de 0,25

As causas mais comuns de CLS alto são: imagens sem dimensões definidas (width/height no HTML), anúncios injetados dinamicamente, fontes web que causam FOUT (Flash of Unstyled Text) e conteúdo inserido via JavaScript após o carregamento inicial.

Sites HTML estáticos evitam a maioria desses problemas naturalmente. Não há conteúdo sendo injetado dinamicamente por plugins, não há anúncios carregando em posições indefinidas, e o desenvolvedor tem controle total sobre dimensões de imagens e carregamento de fontes.

HTML estático vs WordPress vs Wix: comparação real

Vamos aos números. A tabela abaixo mostra scores típicos do PageSpeed Insights para cada plataforma, baseados em dados reais de milhares de sites:

Métrica	HTML Estático	WordPress (sem cache)	WordPress (com cache)	Wix
Score Mobile	95-100	30-50	50-75	50-70
Score Desktop	98-100	60-80	75-90	70-85
LCP Mobile	0,8-1,5s	3-6s	2-4s	2,5-4s
INP	< 50ms	200-500ms	150-400ms	150-350ms
CLS	< 0,05	0,1-0,35	0,05-0,2	0,1-0,3
TTFB	50-200ms	800ms-2s	300-800ms	200-600ms

Por que a diferença é tão grande? A resposta está na arquitetura.

HTML estático: o servidor recebe a requisição e entrega um arquivo pronto. Não tem PHP para executar, não tem banco de dados para consultar, não tem 47 plugins para carregar. Com um CDN na frente (como o Cloudflare), o arquivo nem precisa chegar ao servidor de origem — é servido do ponto de presença mais próximo do usuário. Para uma análise mais aprofundada, veja nosso comparativo entre HTML e WordPress.

WordPress: cada requisição dispara o PHP, que carrega o core do WordPress, ativa os plugins, consulta o MySQL, monta o HTML e envia a resposta. Isso leva tempo. Plugins de cache (WP Rocket, W3 Total Cache) amenizam o problema, mas adicionam complexidade e nunca chegam na performance de um arquivo estático real. Além disso, cada plugin de "otimização" adiciona seu próprio JavaScript.

Wix: usa um framework JavaScript proprietário que renderiza a página no cliente. O HTML inicial é pesado, carregado de scripts do framework, e a interatividade depende do JavaScript do Wix carregar completamente. O usuário vê um loading antes de ver o conteúdo real.

Sites hospedados no Htmly já nascem com score 90+ no PageSpeed porque são HTML puro servido via CDN Cloudflare, sem processamento server-side e sem JavaScript desnecessário.

Como testar seu site no PageSpeed Insights

Testar é simples e gratuito. Siga estes passos:

Acesse pagespeed.web.dev
Cole a URL do seu site no campo de busca
Clique em "Analisar"
Aguarde o resultado (leva 10-30 segundos)

O relatório mostra dois conjuntos de dados:

Dados de campo (Field Data): métricas reais coletadas de usuários do Chrome nos últimos 28 dias. São os dados que o Google realmente usa para ranking. Se o seu site é novo ou tem pouco tráfego, essa seção pode aparecer vazia — isso é normal.

Dados de laboratório (Lab Data): testes simulados feitos na hora, com uma conexão 4G lenta e um dispositivo de gama média. São úteis para diagnóstico, mas não são os que o Google usa diretamente para ranking.

Preste atenção especial nas métricas marcadas em vermelho — essas são as que estão prejudicando seu ranking. O relatório também lista sugestões específicas de correção na seção "Oportunidades" e "Diagnósticos".

Outra ferramenta útil é o Google Search Console, que mostra o status dos Core Web Vitals de todas as páginas do seu site agrupadas por tipo de problema.

Dicas para manter a performance perfeita

Mesmo com um site HTML estático, existem práticas que fazem a diferença entre score 90 e score 100.

Otimize imagens agressivamente. Imagens são responsáveis por 50-70% do peso total de uma página típica. Use formato WebP (30-50% menor que JPEG com qualidade equivalente). Defina width e height no HTML para evitar CLS. Use lazy loading (loading="lazy") em imagens abaixo da dobra. O Compressor de Imagens do Htmly faz essa conversão automaticamente.

Minimize CSS e JavaScript. Remova espaços, comentários e código não utilizado. Um arquivo CSS de 50KB pode cair para 15KB após minificação. Use o Minificador de Código para fazer isso em segundos, sem instalar nada.

Evite fontes externas pesadas. Google Fonts é conveniente, mas cada fonte adiciona uma requisição DNS + download. Se possível, use font-display: swap para evitar texto invisível durante o carregamento. Melhor ainda: hospede as fontes localmente no seu próprio site para eliminar a dependência externa.

Use preload para recursos críticos. Adicione <link rel="preload"> para o CSS principal e a imagem hero. Isso diz ao navegador para buscar esses recursos imediatamente, antes mesmo de parsear o HTML completo.

Evite JavaScript bloqueante. Todo <script> sem async ou defer bloqueia o parsing do HTML. Coloque scripts no final do body ou use defer para que eles carreguem em paralelo sem bloquear a renderização.

Sirva via CDN. Uma CDN (Content Delivery Network) distribui cópias do seu site em servidores ao redor do mundo. Quem acessa de São Paulo recebe o arquivo de um servidor em São Paulo, não de um datacenter nos EUA. Se você usa uma plataforma de hospedagem de sites como o Htmly, o CDN já está incluso automaticamente via Cloudflare.

O que fazer se seu score estiver baixo

Se você rodou o teste e o resultado não foi bom, não entre em pânico. Aqui vai um diagnóstico prático por métrica.

LCP alto (acima de 2,5s): o problema quase sempre é (1) imagem hero muito pesada, (2) servidor lento (TTFB alto) ou (3) CSS/JS bloqueante. Comece otimizando a imagem principal — converta para WebP, reduza a resolução para o tamanho real de exibição e use preload. Se o TTFB estiver acima de 600ms, o problema é o servidor ou a falta de CDN.

INP alto (acima de 200ms): revise o JavaScript da página. Identifique scripts de terceiros (analytics, chat widgets, trackers) que podem estar competindo pela thread principal. Remova o que não for essencial. Se você usa um framework JavaScript, avalie se ele é realmente necessário para o tipo de página.

CLS alto (acima de 0,1): inspecione elementos que carregam tardiamente e empurram o conteúdo. As correções mais comuns são: adicionar width/height em todas as imagens, reservar espaço para anúncios com CSS (min-height), e usar font-display: swap ou font-display: optional nas fontes web.

Se você está num WordPress ou Wix e não consegue melhorar o score, considere migrar para HTML estático. Ferramentas de IA como ChatGPT e Claude conseguem converter um design completo em HTML/CSS em minutos. Depois, basta hospedar num serviço otimizado para arquivos estáticos. Nosso comparativo de hospedagem gratuita lista as melhores opções disponíveis.

Por que isso importa para SEO

Core Web Vitals não são o único fator de ranking — o Google considera mais de 200 sinais. Mas são um fator de desempate importante. Em nichos competitivos, onde dezenas de sites têm conteúdo similar e autoridade parecida, a experiência do usuário pode ser o diferencial que coloca você na posição 3 em vez da posição 13.

Além do ranking direto, sites rápidos têm:

Menor taxa de rejeição. 53% dos usuários mobile abandonam páginas que demoram mais de 3 segundos para carregar (dados do Google).
Maior tempo de permanência. Quem não espera carregamento não lê o conteúdo, não clica em links internos e não converte.
Melhor taxa de conversão. Cada segundo a mais no tempo de carregamento reduz a conversão em até 7% (dados da Akamai).

Em resumo: performance não é um detalhe técnico — é uma vantagem competitiva real.

Conclusão

Core Web Vitals medem o que realmente importa: a experiência de quem visita seu site. LCP, INP e CLS são métricas objetivas, com thresholds claros, e o Google as usa ativamente para decidir quem aparece primeiro nos resultados de busca.

Sites HTML estáticos têm uma vantagem estrutural nessas métricas. Sem banco de dados, sem processamento server-side e sem frameworks JavaScript pesados, eles naturalmente atingem scores altos no PageSpeed. Se você quer um site rápido, seguro e bem posicionado no Google, HTML puro é o caminho mais direto.

Teste seu site agora no PageSpeed Insights, otimize imagens com o Compressor de Imagens, minifique seu código com o Minificador e hospede num serviço feito para performance. Seu ranking — e seus visitantes — vão agradecer.