Lighthouse 100 em Portal Regional de Notícias de Alto Volume

O problema

Um grande portal regional do Centro-Oeste estava vazando leitores mobile. A audiência é 70%+ em Android mediano em 3G/4G, onde cada segundo extra é bounce mensurável. Lighthouse Performance estava em 32 no mobile. CLS lá em cima por causa de unidades de anúncio que carregavam tarde e empurravam o corpo do artigo.

A restrição: a origem WordPress tinha que ficar. Editores são produtivos nela, o time não vai a lugar nenhum e o workflow editorial não suportaria uma migração de CMS.

A abordagem

Resolver no edge e deixar o CMS em paz.

Varnish 7.x na frente — já existia, mas sub-tuned. Reescrevi VCL para normalizar cache keys, separei paths autenticados dos anônimos e empurrei TTLs de minutos para horas onde a cadência editorial permitia.

CSS crítico inline para templates de artigo e home. O bundle completo de CSS virou post-load. First paint caiu na hora.

JS adiado ou removido — metade do JS era um tag-manager-de-tag-managers carregando scripts não usados há 18 meses. Podado agressivamente.

Imagens convertidas a WebP no edge com um Worker, servidas com `<picture>` para fallback em clientes legados. O peso de imagem por artigo caiu ~60%.

Slots de anúncio com CSS reservado — containers de altura fixa que seguram espaço antes do anúncio carregar. CLS despencou.

Compressão Brotli para HTML, CSS e JS. Deploys antigos ainda estavam em gzip.

O conjunto inteiro foi rollado seção-por-seção com monitoramento sintético por rota. Qualquer regressão fazia rollback automático.

O resultado

Lighthouse Performance saiu de 32 para 95 sustentado (mediana de 30 runs sintéticos diários). Time to Interactive no mobile caiu 1,7 segundo. Sessões por usuário subiram ~18% no primeiro trimestre pós-lançamento — os leitores já estavam ali, só estavam saindo antes do artigo renderizar.

Sem migração de CMS. Sem mudança de workflow editorial. O time manteve suas ferramentas e ganhou um site rápido.

Por que isso importa

Portais de notícia ouvem que precisam migrar para a stack mais recente para serem rápidos. Não precisam. Precisam parar de deixar a camada de cache apodrecer, parar de carregar JS morto e parar de deixar anúncios refluírem o artigo. A maior parte do ganho é higiene que o time já conhece — só precisam de alguém que faça sem quebrar o fluxo de publicação.