Um site que antes carregava bem agora parece lento. A primeira tela demora alguns segundos e os cliques respondem com atraso.

"De repente" significa que algo mudou recentemente — geralmente uma imagem grande foi adicionada, os dados se acumularam, um projeto no plano gratuito dormiu ou um script de terceiros foi acoplado. Abaixo está um checklist causa por causa.

Não existe uma solução mágica única. O motivo varia de site para site. Este guia ajuda você a isolar o culpado. Meça primeiro (Passo 0) e corrija apenas a causa correspondente.

Passo 0. Diagnostique em 30 segundos — descubra onde está a lentidão

Meça antes de chutar.

  1. Acesse https://pagespeed.web.dev/, cole a URL do seu site e clique em Analyze.
  2. Observe o LCP (Largest Contentful Paint): 2,5 s ou menos é bom, acima de 4,0 s é ruim (limites do web.dev).
  3. A lista de Opportunities / Diagnostics aponta problemas concretos — "properly size images", "reduce unused JavaScript". Esses são seus suspeitos.

Tem o Chrome? F12 → aba Lighthouse → Analyze page load dá o mesmo relatório. Sem instalar nada.

Causa 1. As imagens são grandes demais (o mais comum)

Você sobe uma foto de 4 MB do celular do jeito que está e essa única imagem derruba a página inteira. Se o Passo 0 apontou as imagens, comece por aqui.

Em um site Next.js, basta trocar <img> pelo Image do next/image para otimizar automaticamente o tamanho, a qualidade e o formato (WebP/AVIF). Imagens fora da tela usam lazy-load por padrão, e adicionar width/height reserva o espaço para o layout não pular.

jsx

import Image from 'next/image'

<Image src="/hero.png" width={1200} height={630} alt="Hero image" priority />
  • Adicione priority apenas na imagem hero do topo para ela carregar primeiro (renomeado para preload no Next.js 16).
  • Todas as outras imagens usam lazy-load automaticamente, sem nenhuma opção extra.

Usa uma ferramenta de IA para programar (Cursor, Lovable, v0)? Diga a ela: "Substitua toda tag <img> pelo componente Image do next/image e adicione priority somente na imagem hero do topo."

Não usa Next.js? O princípio é o mesmo: comprima as imagens (por exemplo, com o squoosh.app) e converta para WebP antes de subir.

Causa 2. Os dados se acumularam e o banco varre a tabela inteira

Se no começo era rápido mas ficou lento quando os posts/usuários/pedidos chegaram aos milhares, o provável culpado são consultas sem índice. Sem um índice, o banco lê a tabela de cima a baixo a cada requisição (um full scan).

Solução no Supabase (Postgres):

  1. Painel do Supabase → Advisors → Query Performance (ou Reports → Query Performance) para ver as consultas lentas e as colunas pelas quais elas filtram.
  2. Adicione um índice nas colunas pelas quais você filtra ou ordena com frequência. No SQL Editor:
sql

create index idx_posts_user_id on posts (user_id);
  1. Se a tabela já estiver grande em produção, adicione concurrently para não travar a tabela para escritas:
sql

create index concurrently idx_posts_created_at on posts (created_at);

O Supabase também tem um Index Advisor que recomenda quais índices adicionar (Query Performance → escolha uma consulta → aba Indexes). Leia a sugestão e depois execute você mesmo o SQL acima.

Causa 3. Um projeto no plano gratuito dormiu (só a primeira requisição é lenta)

"Só o primeiro carregamento depois de um tempo é lento, depois fica normal" → isso é um sinal de sono / cold start.

  • O plano Free do Supabase pode pausar um projeto após cerca de 7 dias de baixa atividade. Uma vez pausado, a primeira requisição que o acorda é lenta ou falha; use Restore no painel para reativar o projeto.
  • Funções serverless (Vercel, etc.) também demoram no cold start quando ficam um tempo sem serem chamadas.

O que fazer: para um serviço de pouco tráfego, acesse-o periodicamente para mantê-lo acordado, ou migre para um plano pago sempre ativo se você tiver tráfego de verdade. Saber que "a primeira requisição lenta de vez em quando" é o sono normal do plano gratuito — e não um bug — evita que você cace fantasmas.

Causa 4. Um script pesado ou widget de terceiros bloqueia a renderização

Se você adicionou recentemente um widget de chat, anúncios, analytics, web fonts ou um embed do YouTube, isso pode estar bloqueando sua primeira renderização. O web.dev observa que scripts síncronos e CSS que bloqueia a renderização no <head> atrasam a renderização.

  • Adie scripts externos não essenciais com async/defer, ou carregue-os no final da página.
  • Os scripts listados em "Reduce the impact of third-party code" do PageSpeed são suspeitos de primeira. Remova um de cada vez para achar o responsável.

Ainda travado?

  • Cole os 3 principais achados do seu relatório do PageSpeed do Passo 0 direto na sua ferramenta de IA e peça para corrigi-los. Os achados do Lighthouse são específicos o suficiente para servir de instruções prontas.
  • Lembre quando ficou lento e o que você mudou naquele momento — reverter o deploy/commit recente costuma ser o caminho mais rápido.

De novo: isto é um checklist para isolar o culpado, não um conserto de uma linha. Siga na ordem — meça (Passo 0) e aplique apenas a causa correspondente.