Por que seu site demora pra carregar (e o que isso está custando em receita)
Um atraso de 1 segundo no carregamento reduz conversões em 7%. Descubra por que seu site está lento, o que está causando isso e como corrigir sem refazer tudo do zero.
ARCO

O problema que ninguém quantifica
Você sabe quanto custa cada segundo de espera no seu site?
A Amazon calculou: cada 100ms de latência extra custa 1% de receita. O Walmart descobriu que cada segundo de melhoria no carregamento equivale a 2% de aumento nas conversões. O Google é mais direto: acima de 3 segundos, 53% dos usuários mobile abandonam a página.
Mas aqui está o problema — a maioria das empresas não tem ideia do quanto está perdendo. Elas sabem que o site "está um pouco lento", mas nunca pararam pra calcular o custo real.
Vamos fazer essa conta.
A matemática do site lento
Suponha que seu site recebe 10.000 visitas por mês, com taxa de conversão de 2% e ticket médio de R$ 500.
Isso dá R$ 100.000 em receita mensal.
Agora: se seu site demora 4 segundos pra carregar (muito comum), e você consegue reduzir pra 2 segundos, o que acontece?
Estudos da Deloitte e Google mostram que uma redução de 0,1s no tempo de carregamento aumenta conversões em até 8% no varejo. Numa mudança de 4s pra 2s, estamos falando de 15–25% de melhoria em conversão.
Resultado: R$ 15.000 a R$ 25.000 de receita adicional por mês. Sem nenhum centavo a mais em mídia paga.
Essa é a oportunidade que fica na mesa quando o site está lento.
Por que o site está lento? As causas reais
1. LCP alto (Largest Contentful Paint)
O LCP mede quanto tempo leva pra o maior elemento visível da página aparecer — normalmente o hero image ou o título principal. Para o Google, bom é abaixo de 2,5s. Acima de 4s é crítico.
As causas mais comuns de LCP alto:
- Imagens sem otimização: JPEGs de 2–5MB sem compressão, sem lazy loading, sem WebP
- Fontes bloqueando renderização: Google Fonts carregando de forma síncrona antes do HTML
- Servidor lento: TTFB (Time to First Byte) acima de 600ms — geralmente hospedagem compartilhada ou serverless mal configurado
- JavaScript pesado no início da página: bundles grandes que precisam ser executados antes de qualquer coisa aparecer
2. CLS alto (Cumulative Layout Shift)
CLS é aquela sensação frustrante de estar prestes a clicar num botão e ele pular pra outro lugar porque um anúncio ou imagem carregou. Mais do que irritante, isso mata conversões.
Causas comuns: imagens sem dimensões definidas, banners de ads sem espaço reservado, fontes que causam refluxo.
3. JavaScript não otimizado
O problema aqui é quase sempre o mesmo: carregar tudo na página inicial, mesmo o que só é usado em interações específicas.
Um botão de chat que carrega 200KB de JavaScript na primeira visita. Um slider de imagens com uma biblioteca de 80KB pra um caso de uso que uma div com overflow:hidden resolveria. Plugins de CMS acumulados ao longo de anos.
Cada KB de JS desnecessário tem um custo: parse, compile, execute. Em dispositivos de entrada (a maioria do Brasil usa smartphones de 2017–2020), isso é a diferença entre uma página que carrega em 2s e uma que trava por 6s.
4. Hospedagem inadequada
Hospedagem compartilhada, planos de entrada de cloud providers sem configuração adequada, ou VPS sem cache HTTP bem configurado.
O sintoma é TTFB alto: o servidor demora pra responder antes mesmo do navegador começar a carregar qualquer recurso.
5. Cache ausente ou mal configurado
Sem cache, cada visita recalcula tudo do zero. Com cache bem configurado, a maioria das requisições é servida instantaneamente. É uma das alavancas de maior ROI em otimização de performance.
O que fazer: por onde começar
Passo 1: Medir antes de agir
Use o PageSpeed Insights para ter um diagnóstico inicial gratuito. Anote os Core Web Vitals: LCP, INP (Interaction to Next Paint) e CLS.
Se você usa Next.js, Vercel Analytics dá esses dados em produção, com dados reais de usuários — não só de laboratório.
Passo 2: Atacar as imagens
Imagens geralmente são o item de maior impacto e mais fácil de resolver:
- Converter todas as imagens para WebP ou AVIF (redução de 25–80% no tamanho)
- Adicionar
loading="lazy"em tudo que não está above the fold - Definir
widtheheightexplícitos em todas as tags<img>para evitar CLS - Usar CDN com cache de borda para assets estáticos
Passo 3: Resolver fontes
<!-- Forma correta de carregar Google Fonts -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="style" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap">
O display=swap é crucial: faz a fonte do sistema aparecer imediatamente enquanto a fonte personalizada carrega, eliminando o FOIT (Flash of Invisible Text).
Passo 4: Code splitting e carregamento sob demanda
Em aplicações React/Next.js:
// Ruim: importa tudo no bundle principal
import { HeavyChart } from './HeavyChart'
// Bom: carrega só quando necessário
const HeavyChart = dynamic(() => import('./HeavyChart'), {
loading: () => <Skeleton />,
ssr: false
})
Passo 5: Cache HTTP bem configurado
# nginx — cache para assets estáticos
location ~* \.(js|css|png|jpg|jpeg|webp|svg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
O que não fazer
Não otimize sem medir primeiro. Muitas empresas passam semanas comprimindo imagens quando o verdadeiro gargalo é o JavaScript de terceiros ou o TTFB do servidor.
Não use "Speed" de plugins de WordPress como solução. Plugins de otimização de performance para WordPress frequentemente criam mais problemas do que resolvem ao interferir em dependências e caching.
Não trate performance como projeto único. Performance regride com o tempo à medida que funcionalidades são adicionadas. Precisa de monitoramento contínuo.
Quando faz sentido trazer especialistas
A otimização DIY tem limite. Quando os ganhos começam a exigir mudanças de arquitetura — refatorar como assets são servidos, mudar estratégia de rendering (SSR vs SSG vs ISR), configurar CDN com edge functions — o custo de aprendizado supera o de contratar quem já sabe.
Na ARCO, fazemos diagnósticos técnicos completos (LCP, TTFB, bundle analysis) e entregamos um plano priorizado por impacto em receita. Não em jargão técnico — em R$.
Se seu site está acima de 3s, existe receita na mesa esperando pra ser recuperada.
Tags: