Performance web: como deixar um site rápido de verdade

Um site rápido não nasce da instalação de um plugin. Ele resulta de medição, diagnóstico e controle contínuo do que é entregue ao navegador.

O site está lento. Em qual parte? “Site lento” pode descrever problemas diferentes: a tela permanece vazia por vários segundos; o conteúdo principal demora a aparecer; o botão responde com atraso; elementos mudam de posição durante a leitura; a navegação começa rápida e piora depois de alguns minutos; somente determinadas páginas apresentam lentidão; o problema ocorre apenas em celulares ou redes móveis. Aplicar compressão, instalar cache ou trocar de hospedagem sem localizar a causa pode produzir pouco resultado. Em alguns casos, a intervenção ainda cria novas falhas: conteúdo desatualizado, scripts incompatíveis ou páginas diferentes para usuários autenticados. Performance web deve ser tratada como um processo de investigação. Três experiências que precisam ser separadas As Core Web Vitals vigentes na data de referência observam três dimensões principais. LCP: quando o conteúdo principal aparece Largest Contentful Paint mede quanto tempo leva para o maior bloco de texto ou imagem visível na área inicial ser renderizado. Um LCP ruim pode ser causado por: resposta inicial lenta; imagem principal pesada; imagem descoberta tarde; CSS bloqueando renderização; fonte atrasando o texto; JavaScript necessário para montar o conteúdo; recurso servido por uma origem lenta. O guia de otimização de LCP recomenda decompor a métrica em etapas, em vez de tratar todo o tempo como um único problema. INP: quanto a interface demora a reagir Interaction to Next Paint avalia a latência observada nas interações realizadas durante a visita. Uma interação lenta pode envolver: 1. espera antes do código começar; 2. execução do manipulador; 3. trabalho necessário para o navegador apresentar o próximo quadro. Causas frequentes: tarefas JavaScript longas; bibliotecas executando trabalho desnecessário; renderização excessiva; manipulação grande do DOM; validação pesada no mesmo ciclo da interação; terceiros ocupando a thread principal. O guia de INP orienta começar por dados de campo quando disponíveis e usar ferramentas de laboratório para reproduzir as interações problemáticas. CLS: quanto a página se move inesperadamente Cumulative Layout Shift mede mudanças visuais inesperadas. Problemas típicos: imagens sem dimensões reservadas; anúncios inseridos acima do conteúdo; fontes alterando significativamente o layout; banners que aparecem sem espaço previsto; componentes carregados depois e empurrando a página; animações que modificam propriedades de layout. Um site pode carregar rápido e ainda ser frustrante se o botão se deslocar no momento do clique. Os limites são referências, não metas isoladas A documentação de Web Vitals considera uma página com boa experiência quando, no percentil 75 das visitas: LCP é de até 2,5 segundos; INP é de até 200 milissegundos; CLS é de até 0,1. O percentil 75 significa que pelo menos três quartos das experiências avaliadas precisam estar dentro do limite. Esses valores não devem ser lidos como autorização para ignorar o restante dos usuários. Também não substituem métricas específicas do produto. Uma busca interna pode aparecer rapidamente e ainda levar dez segundos para retornar resultados. Campo e laboratório respondem perguntas diferentes Dados de campo Mostram o que aconteceu com usuários reais, considerando: dispositivos; redes; localização; cache; conteúdo; extensões; estado da aplicação; interações efetivamente realizadas. O Chrome UX Report reúne dados agregados de experiência real para origens e URLs elegíveis. Um site pequeno pode não possuir dados públicos suficientes no CrUX. Nesse caso, uma solução de Real User Monitoring pode coletar métricas diretamente, respeitando privacidade e consentimento aplicáveis. Dados de laboratório São produzidos em condições controladas. O Lighthouse executa auditorias de performance, acessibilidade, SEO e outras categorias. Ele é útil para: reproduzir problemas; comparar versões; investigar a cadeia de recursos; automatizar verificações; encontrar oportunidades técnicas. Uma execução do Lighthouse não representa todos os usuários. Resultado local varia conforme hardware, rede, extensões, estado do cache, página e configuração de simulação. Use laboratório para explicar e corrigir. Use campo para verificar o impacto real. Diagnóstico 1: a tela demora a mostrar qualquer conteúdo Comece pelo documento HTML. Verifique: DNS; conexão; TLS; redirecionamentos; tempo de resposta do servidor; processamento no backend; cache; distância entre usuário e infraestrutura; consultas ao banco; chamadas externas bloqueantes. A especificação Navigation Timing Level 2 expõe tempos associados à navegação do documento. Exemplo simples: O exemplo ajuda no diagnóstico local. Dados enviados para analytics precisam de política de coleta, amostragem, validação e proteção contra informações identificáveis. Se o tempo até o primeiro byte for alto, reduzir a imagem principal não resolverá a causa inicial. Avalie backend, banco, cache e infraestrutura. A escolha da hospedagem deve considerar capacidade, monitoramento e suporte, e não apenas espaço em disco. Diagnóstico 2: o HTML chega, mas o conteúdo principal demora Abra a cadeia do recurso responsável pelo LCP. Uma imagem pode ser descoberta tarde porque está: inserida por JavaScript; declarada como background image ; escondida atrás de CSS carregado posteriormente; dependente de um componente que só renderiza depois da hidratação. Para uma imagem realmente prioritária: Não faça preload de muitas imagens. Recursos marcados como prioritários competem entre si. Outras ações: comprimir no formato adequado; não enviar resolução muito superior ao espaço exibido; evitar lazy loading no elemento LCP inicial; reduzir CSS bloqueante; carregar fontes necessárias conscientemente; renderizar conteúdo importante no HTML inicial quando apropriado. Diagnóstico 3: a página aparece, mas os botões demoram Grave uma interação no painel Performance do navegador. Procure tarefas longas na thread principal. Exemplo problemático: Possíveis correções: processar apenas o necessário; paginar ou virtualizar; dividir trabalho; adiar tarefas não essenciais; usar Web Worker para cálculo compatível; reduzir re renderizações; remover bibliotecas desnecessárias; evitar manipuladores globais excessivos. Divisão simples de uma tarefa: Essa técnica permite que o navegador processe outras tarefas entre lotes, mas não é uma correção universal. O melhor resultado pode exigir reduzir o trabalho total. Diagnóstico 4: o conteúdo “pula” Reserve espaço. Para banners dinâmicos, escolha entre: reservar altura; exibir sobre o conteúdo sem encobrir controles; inserir em posição que não desloque o que a pessoa já está lendo. Fontes também podem causar mudanças. Avalie: fallback com métricas próximas; subconjuntos; quantidade de pesos; estratégia font display ; necessidade real da fonte externa. Diagnóstico 5: a home está rápida, mas o sistema degrada Aplicações de longa duração podem acumular: listeners não removidos; timers; nós desconectados; caches em memória; estados duplicados; dados carregados sem descarte; conexões abertas; componentes renderizados repetidamente. Nesse caso, uma medição de carregamento inicial não basta. Analise: memória; quantidade de nós DOM; tarefas após navegações internas; tempo de renderização por tela; crescimento de estados; impacto de filtros, tabelas e gráficos. A solução pode envolver arquitetura de frontend, descarte correto, paginação, virtualização e simplificação dos componentes. O servidor também precisa explicar seu tempo A API pode enviar o cabeçalho Server Timing : O navegador pode exibir essas informações nas ferramentas de desenvolvimento. Não exponha nomes internos, topologia ou detalhes sensíveis. Use identificadores genéricos e restrinja o que é publicado. A Performance API da MDN apresenta interfaces para métricas nativas e medições específicas da aplicação. Otimize terceiros pelo valor entregue Scripts de terceiros incluem: analytics; chat; mapas; vídeo; publicidade; testes A/B; pixels; widgets sociais; antifraude. Cada script adiciona custo de rede, processamento e risco operacional. Monte um inventário: Script Responsável Finalidade Dados Peso Execução Pode atrasar? Analytics A Marketing Medição Eventos 90 KB Todas as páginas Sim Chat B Atendimento Suporte Sessão 310 KB Todas as páginas Talvez Mapa C Comercial Localização Terceiro 600 KB Contato Carregar sob ação Remova integrações sem uso comprovado. Carregue recursos pesados apenas onde são necessários. Um mapa pode aparecer inicialmente como imagem ou botão e carregar a aplicação completa depois da interação. Cache não pode servir a resposta errada Caching reduz transferências e processamento, mas exige política adequada. Recursos versionados podem usar retenção longa: Isso pressupõe nomes alterados a cada versão: HTML normalmente exige estratégia diferente, porque referencia os arquivos atuais. Conteúdo autenticado, personalizado ou sensível pode não ser apropriado para cache compartilhado. Não aplique regras globais sem classificar respostas. Compressão e protocolo Texto como HTML, CSS, JavaScript, JSON e SVG costuma se beneficiar de Brotli ou gzip. Imagens e vídeos já comprimidos precisam de otimização de formato e resolução, não apenas compressão HTTP. HTTP/2 e HTTP/3 alteram características de transporte, mas não tornam irrelevante: tamanho; prioridade; quantidade de JavaScript; trabalho na thread principal; cache; resposta do backend. Uma página com megabytes de código desnecessário continuará custosa. Crie um orçamento de performance Um orçamento estabelece limites que exigem revisão quando ultrapassados. Exemplo: Não transforme a pontuação do Lighthouse no único critério. Ela varia e pode esconder experiências específicas. A documentação da MDN sobre performance budgets recomenda relacionar limites à experiência e às metas do produto. Ordem prática de correção 1. Corrija erros e indisponibilidade. 2. Reduza resposta inicial lenta. 3. Torne o recurso LCP descobrível e leve. 4. Remova JavaScript desnecessário. 5. Quebre tarefas longas. 6. Reserve dimensões. 7. Revise terceiros. 8. Configure cache e compressão. 9. Valide dados de campo. 10. Crie barreiras contra regressão. Não sacrifique segurança para obter alguns pontos. Desabilitar validações, remover autenticação ou manter software desatualizado não é otimização. O equilíbrio entre proteção e experiência é tratado em segurança digital em camadas. Critério de pronto Uma melhoria está pronta quando: o problema foi reproduzido; a causa foi identificada; existe comparação antes e depois; o fluxo funcional continua correto; acessibilidade não regrediu; segurança não foi enfraquecida; dados de campo serão acompanhados; existe limite automatizado quando aplicável. O artigo sobre testes web orientados por risco mostra como transformar desempenho em parte da estratégia de validação. Um site rápido de verdade não é aquele que recebeu uma nota alta em uma única execução. É aquele que entrega conteúdo e interação de forma consistente para pessoas reais e possui processo para não piorar silenciosamente na próxima versão.