Por que seu site carrega lento (e como resolver)
O custo de ser lento
A cada segundo extra de carregamento, você perde visitantes. Google mede isso: página que carrega em 3 segundos tem 32% mais abandono que página que carrega em 1 segundo. Em 5 segundos, 90% vai embora.
Esses números parecem abstratos até você fazer a conta. Se seu site recebe 1.000 visitantes por mês via Google Ads a R$ 3 por clique, e 30% desiste porque a página demora pra carregar, você tá jogando R$ 900 fora por mês. R$ 10.800 por ano. Pra resolver um problema que uma tarde de trabalho corrige.
Se você não paga por tráfego, o custo é diferente mas igualmente real: o visitante que veio do Google orgânico, do Instagram ou de indicação saiu sem ver o conteúdo. Você nunca vai saber que ele existiu.
Tem o fator SEO também. Google usa Core Web Vitals como sinal de ranking desde 2021. Site lento perde posição pra concorrente com conteúdo equivalente mas carregamento mais rápido. Não é o fator principal de ranking, mas em nichos competitivos onde todo mundo tem conteúdo parecido, performance vira o desempate.
Os 3 vilões mais comuns
Auditei dezenas de sites nos últimos anos. Os problemas se repetem. Em 90% dos casos, são os mesmos três.
1. Imagens sem otimização
O motivo número 1 de site lento. Uma foto tirada com celular tem 3 a 5 MB. Sobe pro site no formato original (JPG de 4000x3000px), sem compressão, sem redimensionamento. Resultado: a home sozinha tem 15-20 MB de imagens.
No projeto da Family Pilates, as fotos originais do estúdio somavam quase 20 MB. Depois de converter pra WebP e redimensionar pro tamanho real de exibição, o total caiu pra 800 KB. Mesma qualidade visual, 96% mais leve.
Na Soline (energia renovável), o desafio era maior: muitas fotos de campo com painéis solares, instalações e equipe. Volume alto de imagens que precisam estar ali. Todas foram otimizadas em WebP com dimensões reais e lazy loading. O site ficou com Lighthouse 95+ mesmo sendo visualmente denso.
Como resolver:
Converta pra WebP. WebP entrega 60-80% menos peso que JPG com mesma qualidade visual. O navegador não nota a diferença. Seu Lighthouse nota. Ferramenta gratuita: squoosh.app (roda no navegador, sem instalar nada).
Redimensione pra resolução real. Imagem de 4000px num container de 800px é desperdício puro. O navegador baixa 5 MB e exibe em 800px. Redimensione pra 2x a resolução de exibição (1600px pra container de 800px, pra ficar nítido em tela retina) e pronto.
Use lazy loading nativo. loading="lazy" no HTML faz o navegador carregar a imagem só quando o usuário rola até ela. Imagens abaixo do fold (o que não aparece na tela inicial) não precisam carregar no primeiro segundo. Isso melhora o LCP bastante.
Defina width e height no HTML. Sem dimensões explícitas, o navegador não sabe o tamanho da imagem antes de carregar. O layout “pula” quando a imagem aparece. Isso causa CLS (Cumulative Layout Shift), uma das métricas que o Google penaliza. Se você usa CSS pra tornar a imagem responsiva (width: 100%; height: auto), os atributos width e height no HTML ainda servem — o navegador calcula o aspect ratio antes do download e reserva o espaço correto.
No Astro, image optimization é nativa. O componente <Image> do Astro converte, redimensiona e otimiza automaticamente no build. Por isso todos os meus projetos em Astro batem Lighthouse 95+ sem esforço manual.
2. JavaScript demais
Site institucional de 5 páginas não precisa de React, Vue ou Angular. Mas muitos são construídos com framework pesado porque “o dev sabia usar” ou “pode precisar de interatividade no futuro”.
O resultado: 200-500 KB de JavaScript pra renderizar texto estático e imagens. O navegador baixa, parseia e executa todo esse código antes de exibir a página. Tempo desperdiçado.
Já auditei site de escritório de advocacia em Next.js que mandava 287 KB de JS pro browser. Zero interatividade. Zero formulário. Zero estado. Só texto e fotos. É o que me fez migrar pra Astro pra esse tipo de projeto.
Como resolver:
Se é site estático, use Astro. Zero JS por padrão. O navegador recebe HTML puro. Todos os meus projetos de site/LP em Astro têm 0 KB de JavaScript no cliente.
Se é WordPress, faça uma auditoria de plugins. Cada plugin pode carregar seu próprio CSS e JS em todas as páginas. Plugin de formulário? Carrega JS no blog. Plugin de analytics? Carrega script no footer. Desative o que não usa, e configure os necessários pra carregar só onde precisam.
Remova bibliotecas mortas. jQuery em 2026? Animate.css importado mas não usado? Font Awesome inteiro pra 3 ícones (que são 400 KB+ de fontes e CSS pra renderizar 3 SVGs)? Cada biblioteca adicionada e esquecida é peso morto. Um teste rápido: abre o bundle analyzer do Webpack ou Vite e vê quais dependências ocupam mais espaço. Quase sempre tem surpresa.
Carregue scripts com defer ou async. defer faz o script executar depois que o HTML tá parseado. async faz o download em paralelo. Sem nenhum dos dois, o script bloqueia o carregamento da página inteira.
Teste rápido: DevTools do Chrome, aba Network, filtre por JS. Se a soma passa de 200 KB num site institucional, tem coisa sobrando. Se passa de 100 KB, já vale investigar.
3. Hospedagem inadequada
Hospedagem compartilhada de R$ 15/mês divide servidor com centenas de outros sites. Se um deles recebe pico de tráfego, o seu fica lento junto. Se o servidor tá em Virginia e seu público tá no Brasil, adiciona 150ms de latência em cada requisição.
O Tok Final é um caso onde hospedagem importa mais que o normal. Gestores de obra acessam o site do canteiro, no celular, com 3G instável. Se a hospedagem é lenta e o site demora 5 segundos pra carregar, não é aberto. Deploy na Vercel com CDN global resolve: o site é servido do ponto mais próximo do visitante.
Como resolver:
Site estático? Deploy na Vercel ou Netlify. Plano grátis, CDN global, HTTPS automático, deploy por push no Git. É a opção padrão pra qualquer projeto Astro. Zero configuração de servidor.
WordPress? Hospedagem otimizada pra WP (Cloudways, DigitalOcean com plugin de cache) em vez de compartilhada genérica. A diferença é grande.
Webapp? Supabase cloud (backend) + Vercel (frontend). O banco fica em região otimizada, o frontend no CDN global.
CDN faz diferença. CDN (Content Delivery Network) copia seu site pra servidores espalhados pelo mundo. Visitante de São Paulo recebe do servidor de São Paulo. Visitante de Lisboa recebe do servidor europeu. Sem CDN, todo mundo recebe do mesmo servidor, não importa de onde acessa. Na prática, a diferença entre servir do datacenter em Virginia vs. do edge em São Paulo pode ser 120-180ms por requisição. Parece pouco, mas uma página com 20 recursos (HTML, CSS, fontes, imagens) acumula esse delay em cada um.
Fontes também pesam
Ponto que muita gente esquece. Fontes externas (Google Fonts, Adobe Fonts) adicionam requisições HTTP extras e bloqueiam a renderização do texto.
Como resolver:
Self-hosting. Baixe as fontes em woff2 e sirva do seu próprio servidor. Elimina a requisição pro Google/Adobe. É o que faço em todos os projetos — meu site usa Degular Display e Aktiv Grotesk self-hosted.
font-display: swap. O navegador mostra o texto com fonte fallback imediatamente e troca quando a fonte customizada carrega. O visitante vê conteúdo instantaneamente, a fonte aparece 200ms depois. Melhor que tela em branco esperando a fonte.
Preload das fontes críticas. <link rel="preload" href="/fonts/fonte.woff2" as="font" type="font/woff2" crossorigin> no <head> faz o navegador começar a baixar a fonte antes de precisar dela.
Como medir a velocidade do seu site
Google PageSpeed Insights (pagespeed.web.dev): coloca a URL e ele analisa. Acima de 90 é bom. Abaixo de 50, precisa de atenção urgente. Entre 50 e 90, tem otimizações fáceis pra fazer.
Lighthouse (Chrome DevTools): mesma engine do PageSpeed, mas roda local. Mais confiável porque não depende de conexão externa. Aba Lighthouse no DevTools, roda auditoria completa.
O que olhar nos resultados:
- LCP (Largest Contentful Paint) mede quanto tempo pro conteúdo principal aparecer. Meta: menos de 2.5 segundos. Vilão comum: imagem hero pesada, fonte bloqueando render
- INP (Interaction to Next Paint) mede quanto tempo pra responder ao primeiro clique. Meta: menos de 200ms. Vilão comum: JavaScript pesado bloqueando a main thread
- CLS (Cumulative Layout Shift) mede quanto a página “pula” durante o carregamento. Meta: menos de 0.1. Vilão comum: imagem sem width/height, fonte que carrega tarde e muda tamanho do texto
Checklist rápido
- Imagens em WebP com dimensões corretas
- Lazy loading nas imagens abaixo do fold
- JavaScript com defer/async (ou zero JS se possível)
- Fontes self-hosted com font-display: swap e preload
- Hospedagem com CDN (Vercel, Netlify ou equivalente)
- Lighthouse acima de 90 em Performance
- HTTPS ativo (Google penaliza sites sem)
- Sem bibliotecas JS desnecessárias
- Imagens com width e height no HTML
Se marca todos, seu site carrega em menos de 2 segundos. Se não marca nenhum, provavelmente leva mais de 5. A maioria desses problemas se resolve em uma tarde de trabalho. O retorno compensa fácil.