Um erro bem comum é olhar apenas um número (ex.: “teve nota X no Lighthouse”) e concluir que está tudo resolvido.
Só que performance é comportamento ao longo do tempo e em diferentes condições. Sem observar
dados de campo e sinais do carregamento, você otimiza o lugar errado.

• Misturar laboratório e campo: testes locais raramente reproduzem rede 4G/3G instável.
• Não acompanhar métricas compostas e individuais: focar só em uma parte esconde gargalos reais.
• Ausência de estratégia: otimizar “o que aparece no topo” sem validar regressões.
• Confiar em cache “por acaso”: testes repetidos podem estar rodando em contexto já aquecido.

Para tomar decisões com segurança, combine:
dados reais (CrUX/Web Vitals) + rastreamento no carregamento (trace do navegador)
+ verificação de impacto (antes/depois).

Outra armadilha é o famoso “carrega tudo para não pensar depois”.
O resultado geralmente aparece em arquivos grandes, muitas requisições
e conteúdo renderizando tarde.

• JS pesado na entrada: frameworks + plugins sem carregamento progressivo.
• Recursos sem hierarquia: CSS e JS render-blocking sem prioridade.
• Imagens sem estratégia: falta de tamanho correto, compressão e formatos modernos.
• Fontes sem controle: `font-display` inadequado e arquivos tipográficos grandes.
• Requests demais: sprites não otimizados, bundles duplicados e assets sem cache.

O objetivo não é “ter pouca coisa”, e sim ter a coisa certa cedo:
entregar HTML significativo rápido, reduzir custo do main-thread e adiar o restante com precisão.

Às vezes a página carrega rápido, mas fica “travada” por alguns segundos.
Isso é sinal de CPU ocupada durante parsing, execução de JS, layout e pintura.

• Eventos e handlers demais: muitos listeners, delegação ausente ou loops repetitivos.
• Medidas forçadas: ler layout após escrever (causando reflow/layout thrashing).
• Animações que forçam layout: alternar propriedades caras (ex.: `top/left`) em vez de transformar.
• Renderização de listas sem virtualização: especialmente em feeds longos e dashboards.
• Trabalho antes do usuário: inicializações pesadas sem necessidade imediata.

Se você não controlar o fluxo, o “tempo de carregamento” vira “tempo de travamento”.
O foco aqui é reduzir tarefas síncronas e evitar padrões que geram recálculo de layout.

// Ruim: escreve e em seguida lê layout no mesmo ciclo (força reflow)
const el = document.querySelector('.item');
for (const item of items) {
  el.style.height = item.h + 'px';     // write
  const w = el.offsetWidth;             // read -> layout recalculation
  item.width = w;
}

// Melhor: separe leituras e escritas em fases distintas
const widths = [];
for (const item of items) {
  // só leitura (ou use valores já conhecidos)
  widths.push(el.offsetWidth);
}

for (let i = 0; i < items.length; i++) {
  // só escrita
  el.style.height = items[i].h + 'px';
  items[i].width = widths[i];
}

CDN, HTTP/2/3 e compressão ajudam muito — mas não substituem uma arquitetura de entrega bem definida.
O erro aparece quando assets críticos não ficam cacheáveis, compressão não é efetiva
ou o navegador baixa arquivos que deveriam ser evitados.

• Cache headers inconsistentes: cache curto demais para assets versionados.
• Conteúdo estático sem fingerprint/versionamento: força re-download e reduz ganho.
• Compressão mal aplicada: brotli/gzip não habilitados onde faz diferença.
• Transferência de dados maior que o necessário: imagens sem `srcset/sizes`, vídeos e thumbs pesados.
• Ordem e prioridade ruins: recursos importantes disputam com scripts não essenciais.

A regra que eu sigo: assets imutáveis devem ser cacheados agressivamente, e
tudo que é crítico para render deve ter prioridade e tamanho controlados.