O CHECKLIST DE CWV

Os doze testes que executo antes de considerar um site ou template pronto para lançamento. Curto o bastante para usar, rigoroso o bastante para detectar falhas reais.

O CHECKLIST DE CWV
Performance e Core Web Vitals guia 4 min de leitura revisado 25 de jul. de 2026

← Todos os guias Todos os guias deste tema

Nesta página
  1. Por que checklists curtos funcionam
  2. Os 12 itens
  3. Como realmente usá-lo
  4. Onde eu reprozo times
  5. Onde essa checklist fica no cluster

Por que checklists curtos funcionam

Auditorias de performance longas são ignoradas. Uma lista de doze itens que um desenvolvedor líder consegue executar numa tarde é usada. Esta é a lista que executo antes do lançamento, antes de uma mudança major de template, e depois de qualquer surpresa "adicionamos um script pequeno".

Assume que você já conhece as métricas. Se precisa da história de diagnóstico, leia por que seu website é lento. Se precisa de cirurgia em uma métrica, leia o guia de LCP, INP, CLS. Esta página é o portão.

Ponto-chave: Uma checklist que você termina bate uma auditoria de 40 páginas que ninguém abre duas vezes.

Os 12 itens

#VerificarPassar parece com
1Dados de campo extraídosCrUX ou RUM para os templates principais, percentil 75 mobile
2Elemento LCP identificadoVocê consegue nomear o elemento e sua URL na página de destino
3Orçamento de mídia LCPHero com peso sensato, formato moderno, dimensionado, pré-carregado se necessário
4TTFB sãoHTML em cache ou estático mantém TTFB fora da zona de perigo
5JS no caminho críticoSem chat, A/B ou hidratação pesada antes da necessidade de primeira interação
6Verificação pontual de INPToques primários permanecem responsivos em um telefone de médio alcance
7FontesSubset, auto-hospedagem ou CDN controlado, sem texto invisível de múltiplos segundos
8Espaço reservado para CLSImagens, embeds e anúncios têm dimensões ou caixas de aspect-ratio
9Third parties listadasToda tag tem um proprietário e uma razão de existir
10Cache headersHTML e assets têm política de cache intencional, não acidental
11Paridade de templateHomepage, hub e templates de artigo são verificados, não apenas home
12Regra de paradaVocê para quando CWV passa, não quando Lighthouse atinge 100

Imprima, cole no ticket de lançamento, ou execute como checklist de PR. O ponto é pass ou fail binário por linha, não respostas discursivas.

Ponto-chave: Se você não consegue marcar o item 1 e o item 2, você não está pronto para os itens 3 a 12.

Como realmente usá-lo

Execute a lista nos templates que geram receita ou rankings: homepage, página de landing primária, categoria ou hub, e uma página de artigo ou produto representativa. Uma homepage verde com um template de artigo vermelho ainda é um lançamento falhado.

Atribua um responsável por falha. Trabalho de performance sem responsável vira uma thread no Slack. Execute novamente dados de campo uma semana depois do lançamento, não apenas em staging. Staging mente sobre third parties, warmth de cache, e dispositivos reais.

Quando tudo passa, pare. Otimização adicional é polimento de brand opcional a menos que um teste de conversão específico diga o contrário.

Ponto-chave: use a checklist como gate em templates que importam, depois saia quando os dados de campo se limparem.

Onde eu reprozo times

Chamar lab verde de aprovado quando Search Console ainda mostra um grupo de URL ruim. Lançar uma página de marketing nova que nunca esteve na checklist. Deixar chat widgets no caminho crítico porque sales pediu. Corrigir CLS em staging com slots de anúncio vazios que explodem em produção.

Também: tratar a checklist como one-off. Templates derivam. Uma reexecução trimestral nas money pages pega a morte lenta de "só mais uma tag".

Se mais de três linhas falharem, não paralelizem doze micro-tasks. Corrijam LCP e third parties primeiro, depois reexecutem. Mais boards limpam rápido desse jeito do que com um sprint de garrafão.

Ponto-chave: Reprove o lançamento quando dados de campo ou cobertura de template estão faltando, não quando um lab score de vaidade é 89.

Onde essa checklist fica no cluster

Use why-is-my-website-slow quando você ainda precisa da história de server versus front end. Use o LCP, INP, CLS guide quando uma métrica única está vermelha e você precisa de alavancas. Use o performance pillar quando a pergunta é roadmap e investimento, não um launch gate.

Essa checklist é o meio chato: binária, repetível, curta o bastante para as pessoas realmente rodarem.

Ponto-chave: Gate lançamentos com a checklist. Diagnostique com os outros guides de performance.

QUANDO QUISER CONVERSAR