O que descobri medindo o Core Web Vitals de um portal de notícias em hospedagem compartilhada

Sete dias medindo um portal de notícias em WordPress numa hospedagem compartilhada. As três causas reais estavam fora da lista de suspeitos do Google, e o painel de diagnóstico apontou a imagem errada duas vezes. A apuração é do Direto Notícias, portal de Guarapari, no Espírito Santo. Os números foram medidos entre 6 e 14 de setembro de 2026 e estão datados por isso. O portal estava reprovado no Core Web Vitals do Google no celular. O maior elemento da tela levava 2,8 segundos para aparecer, contra o limite de 2,5. Isso barra a entrada no Discover, que é de onde vem tráfego de descoberta para veículo pequeno. A parte fácil do diagnóstico o próprio Google entrega: o relatório aponta JavaScript bloqueando a renderização, imagens pesadas e refluxo forçado. A parte difícil é descobrir qual desses itens é a causa e qual é sintoma. Passei sete dias medindo, e as três causas reais não estavam na lista de suspeitos. Primeira: o site gastava o servidor gerando páginas para ninguém O plugin de cache tinha uma fila de pré-carregamento ligada. Ela completava entre 130 e 180 páginas a cada quinze minutos, o dia inteiro, com quase sete mil pendentes e mais de dois mil erros acumulados. Numa hospedagem compartilhada, isso não é otimização, é concorrência. Medi a home já em cache respondendo em 1,2 segundo enquanto a fila trabalhava. A mesma home, com a fila parada, responde em 0,22. O detalhe que quase me enganou: eu achava que a página estava fria. Não estava. O arquivo de cache tinha sido gravado horas antes. O servidor é que estava ocupado. Segunda: 100% dos cliques de celular caíam em matérias, e nenhum na home Puxei o Search Console por página e por dispositivo. Em 28 dias, todos os cliques de celular vindos da busca caíram em matérias espalhadas pelo acervo. A home recebeu zero. Isso inverte a estratégia inteira. Eu vinha otimizando a home, que é o que todo mundo mede. Quem decide a nota de campo é o acervo, e o acervo estava sempre frio: cada publicação limpava o cache do site todo, o portal publica dezenas de textos por dia, e o cache vive sete dias. A correção foi cirúrgica, por filtro: publicação nova limpa home e categoria; atualização de texto limpa apenas aquela matéria. Mais um aquecedor que mantém quentes as matérias que o Google efetivamente manda gente, com a lista vinda do próprio Search Console. E uma regra que ficou: disparar uma requisição não é aquecer. Requisição não bloqueante com tempo limite curto é descartada pela hospedagem antes de o cache gravar. Só o arquivo em disco prova. O aquecedor confere a data do arquivo e registra se gravou ou não. Terceira: a capa invisível que era baixada com prioridade máxima O tema imprimia a imagem de destaque num bloco próprio, acima do texto. Meses antes, uma regra de CSS tinha escondido esse bloco em todos os aparelhos, porque a mesma foto já aparecia no corpo da matéria. Esconder por CSS não impede o download. O navegador baixava 24 KB com prioridade alta para uma imagem que ninguém via, disputando banda com a foto que o leitor realmente enxerga. Fica a lição: compare sempre o que está visível com o que está sendo baixado. São listas diferentes, e a segunda é a que custa. O painel de causas do Google apontou a imagem errada. Duas vezes O relatório do PageSpeed acusava a capa da matéria de "elemento de imagem sem tamanho definido", e depois o logotipo do cabeçalho. Testei segurando cada imagem por seis segundos com o navegador controlado e medindo a caixa antes e depois de carregar. Nos dois casos a caixa já estava reservada, porque os atributos de largura e altura geram proporção. Falso positivo nos dois. A causa real só apareceu ao instrumentar o próprio navegador com observador de deslocamento de layout, processador estrangulado e rede lenta, olhando quais nós se moviam. Eram dois: A fonte dos títulos. Em Arial o título ocupava três linhas; quando a fonte condensada chegava, virava duas, e tudo abaixo subia trinta pixels. Resolvido com pré-carregamento da fonte e uma fonte reserva com métrica ajustada, para as duas ocuparem a mesma altura. O anúncio automático, que insere um bloco entre a foto e o primeiro parágrafo depois de a página já estar montada. Esse eu não toquei: é a receita do veículo. O que eu mediria diferente da próxima vez Nota de laboratório é ruído quando há anúncio. A mesma matéria, sem nenhuma mudança no código, deu 89 e depois 66 em rodadas seguidas, só porque o anúncio sorteado travou a thread por mais tempo. Compare tempo de carregamento e deslocamento de layout, nunca a nota. Medir logo após limpar o cache mede página fria. Duas medições minhas foram para o lixo por isso. Amostra de um não mede nada. Registrei como lição que o compressor de imagens não gerava formato moderno para miniaturas. Uma semana depois conferi mês a mês e estava errado: ele gera. Minha conclusão tinha saído de um único arquivo, e esse arquivo era de um lote que nunca chegou a ser processado. Voltei e corrigi o registro. Campo é janela de 28 dias. Nada do que se faz hoje aparece antes de semanas. No dia das mudanças o número de campo até piorou, porque a janela ainda carregava os dias ruins. Onde chegou No laboratório, em celular: a home saiu de 93 para 97 e a matéria passou a carregar o maior elemento em 2,2 segundos, contra 2,4 a 2,6 antes. O bloqueio de renderização caiu de cerca de dois segundos para pouco mais de um. As imagens do acervo recente passaram a ser servidas em formato moderno, com 29% menos peso. O número que decide, o de campo, só será lido no começo de outubro. Até lá, não se mexe em mais nada, porque cada mudança nova suja a leitura. Se o assunto for útil, o portal fica em diretonoticias.com.br e a página de transparência explica quem o mantém e como ele se financia.