O CHECKLIST DE CWV

Checklists longos nunca são usados. O checklist de Core Web Vitals que funciona é curto o suficiente para um engenheiro executar antes de fazer push para produção sem achar que é uma tarefa chata. O meu tem doze itens.

Sites que passam nos doze itens no lançamento raramente têm problemas com CWV em produção. Sites que pulam três ou quatro acabam falhando no percentil 75 e o time se vê obrigado a corrigir depois que o Google nota.

1. A imagem hero é pré-carregada com link rel=preload as=image no head.

2. Imagens above-the-fold têm atributos de largura e altura explícitos, então o layout reserva espaço antes do carregamento.

3. Formato WebP, qualidade 82, redimensionado para as dimensões reais de renderização antes do upload.

4. CSS crítico inserido inline no head, o resto adiado para carregamento assíncrono.

5. Web fonts auto-hospedadas com font-display: swap.

6. JavaScript inicial abaixo de 100KB em todas as páginas públicas.

7. Scripts de análise, marketing e social pixel todos adiados.

8. Colunas de CSS Grid usam minmax(0, 1fr) em vez de 1fr para evitar overflow em conteúdo longo.

9. Renderização estática sempre que o conteúdo permitir.

10. Cloudflare ou CDN equivalente na frente da origem.

11. Dados de campo medidos semanalmente via Search Console > Core Web Vitals.

12. O linter de SEO em tempo de build falha a build em regressões.

Passe pela lista manualmente antes de qualquer lançamento maior. Para trabalho de engenharia contínuo, automatize os itens 6, 8, 11 e 12 em CI; o resto são verificações em nível de template que acontecem em tempo de design e raramente regridem.

Quando CWV regride em produção, a regressão quase sempre rastreia para um desses doze itens sendo silenciosamente violado. O fluxo de diagnóstico é: passe pela lista, encontre a violação, corrija-a, aguarde 28 dias para o CrUX atualizar, confirme.