Você abriu o Google Search Console hoje cedo, foi até o relatório de Experiência na Página e encontrou aquela notificação vermelha: “URLs com desempenho ruim“. Os Core Web Vitals do seu portal de notícias estão reprovando e você sabe que isso afeta diretamente o tráfego orgânico, a posição no Google News, Google Discover e, por consequência, a receita de ads.
Não é um problema isolado. Portais de notícias em WordPress enfrentam um desafio único: precisam carregar rápido mesmo publicando dezenas de artigos por dia, exibindo anúncios programáticos em múltiplos slots, carregando widgets sociais e ainda servindo imagens em alta resolução para matérias de impacto. É o ambiente mais hostil para performance que existe.
A boa notícia é que os problemas têm solução. Neste guia, o mais completo disponível em PT-BR sobre o tema, você vai entender exatamente o que o Google mede, por que portais de notícias têm dificuldades específicas com LCP, INP e CLS, e como resolver cada um deles com ações práticas e priorizadas.
Se você é editor, gestor técnico ou desenvolvedor de um portal WordPress e precisa de um plano real para passar nos Core Web Vitals, este artigo foi escrito para você.
Nota rápida: se você também quer entender como a performance impacta a receita de ads do seu portal e como aparecer no Google News e performance, temos artigos específicos no blog. O SEO técnico completo do portal também está em SEO técnico do portal.
O que são Core Web Vitals no WordPress para portais de notícias?
Core Web Vitals são três métricas de experiência do usuário usadas pelo Google como fator de ranqueamento: LCP (velocidade de carregamento do maior elemento visível, meta: <2,5 s), INP (tempo de resposta a interações, meta: <200 ms) e CLS (estabilidade visual da página, meta: <0,1). Para portais de notícias WordPress, a aprovação exige otimização de imagens, eliminação de JavaScript bloqueante, cache avançado e controle rigoroso de ad slots para evitar saltos de layout.
O que são Core Web Vitals e por que portais de notícias precisam priorizá-los
Os Core Web Vitals são um subconjunto das métricas de experiência na página (Page Experience) que o Google usa para avaliar a qualidade real da navegação em um site. Diferente de métricas tradicionais de “velocidade”, como o tempo total de carregamento, os CWV medem o que o usuário sente: quando o conteúdo aparece, quando ele pode clicar em algo e se a página “pula” enquanto carrega.
Desde 2021, esses sinais fazem parte do algoritmo de ranqueamento do Google, com peso maior em disputas acirradas (quando dois conteúdos são igualmente relevantes, o que tem CWV melhores tende a rankear acima). Em março de 2024, o Google substituiu o FID (First Input Delay) pelo INP (Interaction to Next Paint), tornando o sinal de interatividade ainda mais rigoroso.
As três métricas e seus benchmarks
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
| LCP | Velocidade de carregamento do maior elemento visível (imagem ou bloco de texto) | < 2,5 s | 2,5 s – 4,0 s | 4,0 s |
| INP | Latência de resposta a qualquer interação do usuário (cliques, toques, teclas) | < 200 ms | 200 ms – 500 ms | 500 ms |
| CLS | Deslocamento acumulado de elementos visuais durante o carregamento | < 0,1 | 0,1 – 0,25 | 0,25 |
Por que portais de notícias são diferentes
Um blog pessoal com 5 posts e sem anúncios consegue bons CWV com relativa facilidade. Um portal de notícias enfrenta uma combinação de fatores que tornain isso exponencialmente mais difícil:
- Volume de publicação: dezenas de posts por dia significa variação constante de imagens, embeds e estrutura de página.
- Anúncios programáticos: slots de header bidding (Google Ad Manager, Taboola, Outbrain) inserem scripts pesados e elementos dinâmicos que destroem o CLS e atrasam o LCP.
- Tráfego mobile alto: portais de notícias têm 70-85% do tráfego em mobile, onde as redes são mais lentas e os dispositivos têm menos poder de processamento.
- Widgets e redes sociais: embeds do Twitter/X, YouTube, Instagram adicionam JavaScript de terceiros que impacta o INP.
- Imagens de alta resolução: fotojornalismo exige qualidade, mas sem compressão e lazy load corretos, essas imagens destroem o LCP.
O Google avalia os CWV usando dados reais de usuários (Chrome UX Report – CrUX), não apenas dados de laboratório. Isso significa que não adianta otimizar a homepage se as páginas de artigo, onde está 80% do tráfego de um portal, estiverem ruins.
Portais que passam nos Core Web Vitals consistentemente relatam ganhos de 10-25% no tráfego orgânico após a aprovação, além de melhora direta na taxa de rejeição e no RPM de anúncios (usuários que ficam mais tempo na página veem mais ads).
LCP (Largest Contentful Paint): como diagnosticar e corrigir em portais WordPress
O LCP mede o tempo até que o maior elemento visível da viewport seja renderizado. Em portais de notícias, esse elemento quase sempre é a imagem de destaque (featured image) do artigo, aquela foto de impacto no topo de cada matéria.
Como o Google identifica o elemento LCP
O navegador analisa todos os elementos renderizados acima da dobra e identifica o maior (por área). Em portais, a ordem de prevalência é:
- Imagem de destaque (
<img>ou imagem de background em CSS) - Imagem em carousel/slider do topo
- Bloco de texto grande (título + lide) quando não há imagem acima da dobra
Causas comuns de LCP ruim em portais WordPress
1. Imagens sem preload e sem formatos modernos
A imagem de destaque de um artigo frequentemente é carregada via CSS ou como <img> sem prioridade, fazendo o navegador esperá-la na fila. Além disso, imagens JPEG pesadas de 500 KB – 2 MB são comuns em portais sem pipeline de otimização.
Solução:
- Converter imagens para WebP ou AVIF (30–50% menor que JPEG equivalente)
- Adicionar fetchpriority=”high” na tag <img> da featured image
- Usar <link rel=”preload” as=”image”> no <head> para a imagem hero
- Plugins: Imagify, ShortPixel ou Cloudflare Image Resizing fazem a conversão automaticamente
2. Render-blocking resources (CSS e JS bloqueantes)
Scripts e estilos carregados no <head> sem async ou defer travam a renderização. Em portais com muitos plugins (SEO, ads, social, comentários), é comum ter 10–20 recursos bloqueantes.
Solução:
- Usar WP Rocket ou FlyingPress para defer de JS não-crítico
- Inline do CSS crítico (above-the-fold) e defer do restante
- Auditar com PageSpeed Insights, aba “Diagnóstico” mostra exatamente quais recursos estão bloqueando
3. Servidor lento (TTFB alto)
Se o Time to First Byte (TTFB) for maior que 600 ms, o LCP quase nunca passa — o navegador nem começou a renderizar enquanto o servidor ainda está respondendo.
Solução:
- Cache de página full-page (WP Rocket, W3 Total Cache, LiteSpeed Cache)
- Object cache com Redis ou Memcached para queries do banco de dados
- Upgrade de hosting: portais sérios precisam de VPS/Cloud (Google Cloud Plataform, AWS, DigitalOcean, Cloudways). Hospedagem compartilhada é inviável acima de 50k pageviews/mês
- CDN com edge caching: Cloudflare (plano gratuito já ajuda; Enterprise tem APO)
4. Lazy load aplicado na imagem hero
Lazy load é excelente para imagens abaixo da dobra, mas se aplicado na featured image (que está acima da dobra), ele atrasa o LCP. É um erro clássico de configuração.
Solução:
- No WP Rocket: em “Mídia > Lazy Load”, ative a opção de excluir a imagem de destaque
- Via código: adicione loading=”eager” e fetchpriority=”high” na featured image
- No tema: identifique qual função gera a featured image e adicione os atributos corretos
Checklist LCP para portais WordPress
- TTFB < 600 ms (verificar com WebPageTest)
- Imagens de destaque em WebP/AVIF
- Featured image com fetchpriority=”high” e sem lazy load
- CSS crítico inline; restante deferido
- JavaScript não-crítico com defer ou async
- CDN configurado com cache de borda
INP (Interaction to Next Paint): o novo sinal que substituiu o FID
Em março de 2024, o Google substituiu o FID (First Input Delay) pelo INP (Interaction to Next Paint). A mudança foi significativa: enquanto o FID media apenas o delay da primeira interação, o INP mede a latência de todas as interações do usuário durante a sessão, cliques, toques, pressionamentos de tecla e reporta o pior percentil.
Por que o INP é mais difícil de passar
O FID era relativamente fácil de passar porque media apenas a primeira interação, que geralmente ocorre antes que scripts pesados terminem de carregar. O INP pega o usuário no meio da navegação, quando todos os scripts já carregaram e estão competindo pela thread principal do navegador.
Meta: INP < 200 ms (bom) | 200–500 ms (precisa melhorar) | > 500 ms (ruim)
Causas comuns de INP alto em portais WordPress
1. JavaScript de terceiros pesado
Scripts de anúncios (Google Publisher Tag, header bidding), analytics (GA4, Hotjar, Clarity), widgets sociais e comentários ficam todos na main thread. Quando o usuário clica em alguma coisa, esses scripts podem estar bloqueando a resposta.
Solução:
- Carregar scripts de terceiros via async ou defer
- Usar Partytown (integrado ao plugin WP Offload Scripts) para mover scripts de terceiros para web workers
- Eliminar scripts desnecessários — auditar com a aba Coverage do Chrome DevTools
2. Temas com JavaScript pesado
Temas de portais de notícias frequentemente incluem mega menus, carrosséis, tabs e acordeons com jQuery ou vanilla JS complexo. Cada interação com esses elementos gera INP ruim.
Solução:
- Migrar para temas otimizados para performance (GeneratePress, Kadence, Blocksy) ou temas específicos para portais
- Substituir jQuery por vanilla JS quando possível
- Dividir bundles JS com code splitting
3. Long Tasks no carregamento da página
“Long Tasks” são tarefas que bloqueiam a main thread por mais de 50 ms. Portais com muitos plugins têm dezenas delas durante o carregamento, aumentando o INP mesmo antes de qualquer interação.
Como identificar:
- Abra Chrome DevTools > aba Performance
- Grave uma interação com a página
- Procure blocos vermelhos na track “Main”, esses são Long Tasks
- Identifique o script responsável e avalie se pode ser diferido, removido ou otimizado
4. Layouts com reflow intenso
Cliques que acionam mudanças de layout grandes (expandir menu, abrir modal, carregar mais notícias via AJAX) forçam o navegador a recalcular toda a geometria da página — operação cara que aumenta o INP.
Solução:
- Usar transform e opacity para animações (não width, height, top, left)
- Aplicar content-visibility: auto em seções abaixo da dobra
- Lazy load de widgets e comentários (carregar apenas quando o usuário chegar na seção)
CLS (Cumulative Layout Shift): o vilão silencioso dos portais com ads
O CLS mede a soma dos deslocamentos inesperados de elementos visuais durante o carregamento da página. O usuário está lendo o lide de uma matéria, a página ainda está carregando ads, e de repente o texto sobe 200px, o usuário clica no link errado. Isso é CLS alto.
Meta: CLS < 0,1 (bom) | 0,1–0,25 (precisa melhorar) | > 0,25 (ruim)
Como o CLS é calculado
O score CLS é a soma dos Layout Shift Scores individuais. Cada shift score = Impact Fraction × Distance Fraction. Em termos práticos: quanto maior o elemento que se move e maior a distância que ele percorre, pior o score.
Causas de CLS em portais de notícias
1. Imagens sem dimensões definidas
Quando o navegador não sabe o tamanho de uma imagem antes de baixá-la, ele não reserva espaço e quando a imagem carrega, empurra o conteúdo abaixo para baixo.
Solução:
A partir do WordPress 5.5+ é adicionado width/height automaticamente para imagens do Media Library. Verifique se seu tema não está removendo esses atributos.
2. Fontes web causando FOUT/FOIT
Quando fontes personalizadas carregam após o texto já ter sido renderizado com fallback font, o reflow de texto causa CLS. Portais que usam Google Fonts via @import no CSS são especialmente afetados.
Solução:
- font-display: swap para evitar FOIT (Flash of Invisible Text)
- Hospedar fontes localmente (plugin OMGF ou manualmente)
- <link rel=”preload”> para a fonte principal do corpo do texto
3. Banners e embeds sem dimensões reservadas
Embeds do YouTube, Twitter e iframes de formulários sem height definida causam CLS quando carregam.
Solução:
- YouTube: usar wrapper com padding-bottom: 56.25% (aspect ratio 16:9)
- Twitter/Instagram: usar Embedly ou versão lite (Lite YouTube Embed)
- Iframes: sempre definir height mínimo
