Medi o Core Web Vitals de um portal de notícias por sete dias e as três causas não estavam na lista do Google

Um portal de notícias de cidade, em WordPress e hospedagem compartilhada, estava reprovado no Core Web Vitals do Google no celular: 2,8 segundos para o maior elemento aparecer, contra o limite de 2,5. Isso barra a entrada no Discover.

O relatório do Google apontava os suspeitos de sempre: JavaScript bloqueando a renderização, imagens pesadas, refluxo forçado. Passei sete dias medindo e as três causas reais eram outras.

A primeira foi o próprio plugin de cache. Ele tinha uma fila de pré-carregamento ligada, completando entre 130 e 180 páginas a cada quinze minutos, o dia inteiro. Em hospedagem compartilhada isso não é otimização, é concorrência por processador. A home já em cache respondia em 1,2 segundo enquanto a fila trabalhava. Com a fila parada, 0,22.

A segunda foi uma inversão de estratégia. O Search Console por página e por dispositivo mostrou que todos os cliques de celular vindos da busca caíam em matérias do acervo. A home recebia zero. Eu vinha otimizando justamente a home. Quem decide a nota de campo é o acervo, e o acervo estava sempre frio, porque cada publicação limpava o cache inteiro.

A terceira foi uma imagem que ninguém via. O tema imprimia a foto de destaque num bloco escondido por CSS meses antes. Esconder não impede o download: o navegador baixava aquilo com prioridade máxima, disputando banda com a foto que o leitor enxerga.

E o painel de diagnóstico do Google apontou a imagem errada duas vezes. A causa do deslocamento de layout só apareceu ao instrumentar o navegador e ver quais nós se moviam: era a fonte dos títulos trocando de largura, e o anúncio automático entrando depois da página montada.

O artigo completo tem as medições, os enganos que cometi no caminho e o que eu faria diferente:
https://dev.to/aryribeiro/o-que-descobri-medindo-o-core-web-vitals-de-um-portal-de-noticias-em-hospedagem-compartilhada-ce5