Por que sites lentos raramente são um problema de código

Quando um site fica lento, o primeiro instinto é olhar para o código: será que o componente está re-renderizando demais? Será que falta um useMemo ali? Na prática, na maioria dos casos que vemos, o código React ou Vue por trás da tela é o de menos. O que trava o carregamento normalmente nem foi escrito por quem construiu o site.

O maior vilão é o que você nem escreveu

Scripts de terceiros — pixel de anúncio, chat widget, um A/B testing tool, três gerenciadores de tags diferentes porque ninguém removeu o antigo — chegam a pesar mais do que toda a aplicação. Cada um deles bloqueia a thread principal por alguns milissegundos, e eles se somam. Fontes carregadas de um CDN externo, sem preload, adiam a exibição do texto. Imagens sem dimensão definida empurram o layout inteiro quando finalmente carregam.

Nenhuma dessas causas aparece quando você abre o arquivo do componente. Elas aparecem na aba de rede do navegador — e é ali que a investigação deveria começar, não no editor de código.

Lighthouse não mente, mas também não conta a história toda

É comum rodar um Lighthouse local, ver a nota de performance despencar e entrar em pânico. Vale lembrar que o Lighthouse mobile aplica um throttling de CPU e rede bastante agressivo — simulando um aparelho mediano em conexão ruim — e que rodar essa simulação numa máquina de desenvolvimento, com outros processos disputando CPU, pode inflar os números de forma que não reflete o que um usuário real vai sentir no ar. Isso não significa ignorar o Lighthouse; significa não tratá-lo como verdade absoluta sem cruzar com uma auditoria no ambiente de produção real, onde CDN, HTTP/2 e cache de borda mudam o resultado.

A prática que funciona: rodar o teste local para pegar problemas óbvios (JS não usado, imagem sem otimização, fonte bloqueante) e validar o número final direto na URL publicada.

Onde o ganho realmente está

Auto-hospedar fontes em vez de depender de um Google Fonts externo elimina uma requisição inteira de terceiro no caminho crítico. Dividir o JavaScript por rota — e, dentro da rota, adiar o que está abaixo da dobra — reduz o que o navegador precisa baixar e executar antes da primeira interação. Definir sempre largura e altura de imagem evita o reflow que gera Cumulative Layout Shift. E qualquer biblioteca de animação, por mais leve que pareça, deveria ficar de fora do carregamento inicial se ela anima algo que não está visível nos primeiros segundos.

Nada disso é sofisticado. É, na maior parte, questão de tirar coisa do caminho — o mesmo princípio de qualquer bom projeto de engenharia: performance se ganha subtraindo, não otimizando o que sobrou.