Mito 1: Cache é apenas para CDNs; se o usuário não volta, não importa

O cache não é uma bala de prata apenas para visitas repetidas. Ele atua na velocidade percebida do usuário, reduzindo_latência e tempo de resposta em visitas subsequentes, além de diminuir custo e carga no servidor.

• Mito: o cache não ajuda a primeira visita.
• Verdade: cabeçalhos de cache bem configurados reduzem viagens de rede em retornos; assets com fingerprinting e hashing ajudam invalidações controladas.
• Boas práticas: cache estável para assets estáticos, use longos TTLs com versionamento de conteúdo; utilize ETag/Last-Modified onde aplicável; combine com invalidation inteligente.

Exemplo de configuração de cabeçalhos para assets estáticos:

Cache-Control: public, max-age=31536000, immutable
ETag: "v1.2.3"
Content-Type: image/webp

Dicas rápidas: use fingerprint no nome do arquivo (ex.: app.abcdef.js) para facilitar invalidação sem revalidar tudo.

Mito 2: Melhorar a performance é tarefa exclusiva do front-end

Web performance é um fluxo de construção que envolve servidor, rede, renderização e experiência do usuário. Focar apenas no frontend deixa gargalos invisíveis sem correção efetiva.

• Verdades-chave: medir com Core Web Vitals (LCP, FID, CLS); priorizar o que impacta o tempo de renderização; reduzir TTFB (tempo até o primeiro byte) no backend.
• Práticas recomendadas: compressão (gzip, brotli), HTTP/2 ou HTTP/3, CDN para geolocalização, cache compartilhado, e entrega de código crítico de forma eficiente.
• Hints de recurso: use preconnect, dns-prefetch e preloads para reduzir latência na aquisição de recursos críticos.

Exemplos simples de hints de recurso:

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preload" href="/css/critical.css" as="style">
<link rel="prefetch" href="/images/ghost-track.png">

Mito 3: Tamanho do bundle é tudo; basta minificar

O tamanho importa, mas a organização do código é o segredo. Bundles grandes prejudicam a interatividade. Code-splitting, lazy loading e remoção de código morto reduzem o tempo de resposta e o uso da CPU no carregamento inicial.

• Verdades úteis: minificação, tree-shaking, e dead code elimination ajudam, mas não substituem uma estratégia de carregamento inteligente.
• Boas práticas: dividir o código em partes menores com importações dinâmicas, atrasar a execução de JS não crítico e priorizar o conteúdo visível.
• Observação: medir impacto com LCP/JS-bundle impact e ajustar thresholds conforme o contexto.

Exemplo de code-splitting com import():

// Carrega analytics apenas quando necessário
if (shouldLoadAnalytics) {
  import('./analytics.js')
    .then(mod => mod.init())
    .catch(err => console.error('Falha ao carregar analytics', err));
}

Dica prática: use lazy loading para componentes que não são vitais na renderização inicial.

Mito 4: Imagens são o único vilão da performance

Imagens são uma parte significativa, mas não única. O desempenho melhora com escolhas de formato, dimensionamento correto, lazy loading e imagens responsivas bem definidas.

• Verdades úteis: use formatos modernos (AVIF/WebP quando disponível); sirva imagens no tamanho adequado com srcset e sizes; combine com lazy loading.
• Boas práticas: otimize compressão, utilize placeholders/low-quality previews, e assegure proporção de aspecto para evitar layout shift.
• Notas: carregue apenas o que é necessário para o entusado para a primeira renderização.

Exemplo de imagem responsiva com lazy loading:

<img
  src="image-960.webp"
  srcset="image-480.webp 480w, image-960.webp 960w, image-1920.webp 1920w"
  sizes="(max-width: 600px) 480px, 960px"
  alt="Descrição da imagem"
  loading="lazy"
  decoding="async"
  width="960" height="540">