Como reduzimos o tempo de carregamento de um site para menos de um segundo
Velocidade não é uma métrica de vaidade — ela afeta o ranqueamento e a receita. Aqui está o trabalho de performance exato que executamos em cada build, na ordem que mais importa.
A maioria dos sites lentos não é lenta por motivos misteriosos. Eles são lentos devido a um punhado de problemas previsíveis acumulados uns sobre os outros — e eles são corrigidos em uma ordem previsível. Quando um cliente nos procura com um tempo de carregamento de três segundos, raramente precisamos de truques exóticos. Precisamos de disciplina.
Este é o mesmo checklist que executamos em todos os projetos de performance, aproximadamente em ordem de prioridade. Cada etapa é barata em relação ao seu impacto, e a maioria dos sites parece drasticamente mais rápida após as três primeiras.
Meça antes de tocar em qualquer coisa
Você não pode melhorar o que não mede, e definitivamente não pode provar melhorias sem uma baseline. Começamos todos os projetos com dados de campo, não apenas pontuações de laboratório.
- Laboratório — Lighthouse e WebPageTest para um snapshot controlado e repetível.
- Campo — métricas de usuários reais (CrUX / RUM) para o que as pessoas realmente vivenciam.
- Budget — um limite rígido por rota, para que as regressões sejam detectadas no CI, não em produção.
Uma pontuação de laboratório de 100 não significa nada se seus usuários reais estão em celulares intermediários e redes instáveis. Otimize para o campo.
Elimine recursos que bloqueiam a renderização
A maior vitória isolada na maioria dos sites é tirar o CSS e o JavaScript do caminho crítico. O navegador não pode renderizar até terminar de processar os recursos que bloqueiam a renderização — portanto, quanto menos houver, mais cedo algo aparecerá.
// adiar tudo o que não for crítico
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Insira inline a pequena quantidade de CSS necessária para o primeiro viewport e, em seguida, carregue o restante de forma assíncrona. Adie scripts não críticos. O objetivo é um first paint que não espere por nada que não seja absolutamente necessário.
Trate as imagens como um budget
As imagens são geralmente o elemento mais pesado em uma página e o mais fácil de errar. Três regras cobrem noventa por cento dos casos:
- Sirva formatos modernos — AVIF ou WebP — com um fallback.
- Redimensione as imagens para suas dimensões de renderização; nunca envie uma imagem hero de 3000px para um espaço de 600px.
- Faça lazy-load de tudo o que estiver abaixo da dobra e reserve espaço para evitar deslocamento de layout (layout shift).
Cache na edge
Assim que a página estiver leve, a próxima questão é a rapidez com que os bytes chegam ao usuário. Uma CDN com cabeçalhos de cache sensatos transforma uma viagem de 600ms à origem em uma resposta de 30ms na edge. Para conteúdo dinâmico, o stale-while-revalidate oferece respostas instantâneas enquanto atualiza em segundo plano.
Performance é uma feature. Nós a incluímos no budget da mesma forma que fazemos com qualquer outra parte do projeto.
O resultado
No projeto que motivou este artigo, a página inicial passou de um largest contentful paint de 3,1s para 0,9s, e as conversões orgânicas aumentaram de forma mensurável no mesmo mês. Nada disso foi mágica — apenas o checklist acima, aplicado em ordem.
Se o seu site parece lento e você não tem certeza por onde começar, entre em contato — uma auditoria curta geralmente revela as duas ou três mudanças que mais importam.