Cada segundo a mais de carregamento de uma página custa conversões. Estudos do Google mostram que 53% dos usuários mobile abandonam um site que demora mais de 3 segundos para carregar. Para e-commerces, cada segundo de melhora no tempo de resposta corresponde a um aumento de 7% na taxa de conversão. Performance não é um detalhe técnico de luxo — é diretamente relacionada a receita. E as técnicas para melhorar performance drasticamente não são secrets — são práticas bem documentadas que a maioria dos sites simplesmente ignora.
Meça antes de otimizar
A regra mais importante de performance: nunca otimize sem medir. A intuição sobre onde está o gargalo frequentemente está errada. Use ferramentas de medição antes de tocar qualquer código: Lighthouse no Chrome DevTools dá um score de performance e lista específicamente os problemas encontrados com impacto estimado. PageSpeed Insights faz o mesmo para URLs públicas. WebPageTest.org oferece testes mais detalhados. Identifique os maiores problemas primeiro — o princípio de Pareto se aplica fortemente a performance: 20% das otimizações geralmente resolvem 80% do problema.
Imagens: a maior fonte de lentidão
Imagens são responsáveis por 60% a 80% do peso total de páginas web em média. As otimizações de maior impacto: use formatos modernos (WebP tem 25-35% menos tamanho que JPEG com a mesma qualidade; AVIF ainda melhor). Defina tamanhos corretos — não sirva uma imagem 2000x1500px para exibir num thumbnail de 200x150px. Use lazy loading: loading="lazy" no atributo img faz o browser carregar imagens apenas quando elas chegam perto do viewport, sem nenhuma linha de JavaScript. Use CDN para servir imagens do servidor geograficamente mais próximo do usuário.
JavaScript: carregue menos, carregue tarde
JavaScript que bloqueia a renderização é um dos maiores problemas de performance. Use defer em scripts que não precisam rodar antes do DOM estar pronto — o browser faz o download em paralelo e executa depois do parse do HTML, sem bloquear. Use async para scripts independentes que podem executar tão logo carregados. Code splitting (dividir o bundle JavaScript em chunks) permite carregar apenas o código necessário para a página atual, baixando o restante sob demanda. Ferramentas como Webpack, Vite e Rollup fazem isso automaticamente com configuração mínima.
Tree shaking elimina código importado mas não utilizado do bundle final. Importar uma função de uma lib de 200KB quando você usa apenas 5KB delas é desperdício que tree shaking resolve — mas requer que você importe nomeadamente (import { format } from 'date-fns') em vez de importar tudo (import * as dateFns from 'date-fns').
Cache: servir do cache é sempre mais rápido que buscar de novo
HTTP cache headers definem por quanto tempo o browser e CDNs devem armazenar recursos. Assets com hash no nome (que o bundler gera automaticamente: main.abc123.js) mudam de nome quando o conteúdo muda — podem ser cacheados por 1 ano com segurança. HTML não deve ter cache longo (você quer que o usuário sempre veja o HTML atual). Uma boa estratégia de cache pode reduzir em 80% a quantidade de dados transferidos para visitantes recorrentes.
Banco de dados: queries lentas matam apps rápidos
Um frontend otimizado não salva uma API que demora 3 segundos por consulta. Use o plano de execução (EXPLAIN ANALYZE no PostgreSQL) para identificar queries lentas. Índices nos campos usados em WHERE, JOIN e ORDER BY resolvem a maioria dos problemas de performance de banco. N+1 query problem — carregar uma coleção e depois fazer uma query por item dentro de um loop — é o assassino silencioso de performance em apps com ORM: substitua por eager loading (carregar os relacionamentos em uma única query com JOIN). Um banco de dados bem indexado e sem N+1 queries transforma aplicações lentas em rápidas sem nenhuma mudança de infraestrutura.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
