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.