Por que meu site está lento? Como encontrar a causa e resolver

"Meu site está lento" pode descrever vários problemas diferentes. O servidor pode demorar para enviar o primeiro byte. A página pode chegar rápido, mas levar uma eternidade para mostrar a imagem principal. Pode parecer pronta e ignorar os toques por um segundo. Ou pode carregar e depois ficar pulando, enquanto anúncios e imagens empurram o texto para baixo. Cada caso tem causas diferentes; por isso, a primeira tarefa é descobrir qual deles é o seu.

Meça antes de mudar qualquer coisa

Existem dois tipos de dados de velocidade, e eles respondem a perguntas diferentes:

• Dados de campo vêm de visitantes reais, em seus próprios dispositivos e conexões. O Chrome UX Report, do Google, os coleta para sites com tráfego suficiente, e você pode vê-los no PageSpeed Insights e no relatório de Core Web Vitals do Google Search Console. Eles mostram o que as pessoas de fato vivenciam.
• Dados de laboratório vêm de um único carregamento da página em condições controladas, como faz o Lighthouse. São menos representativos, mas são reproduzíveis e explicam por que a página está lenta.

Os Core Web Vitals do Google definem uma boa experiência como Largest Contentful Paint (LCP) de 2,5 segundos ou menos, Interaction to Next Paint (INP) de 200 milissegundos ou menos e Cumulative Layout Shift (CLS) de 0,1 ou menos, medidos no 75º percentil das visitas reais.

Para o diagnóstico, rode um teste de laboratório. O verificador de velocidade de sites gratuito do Rudra carrega a sua página com o Lighthouse e informa First Contentful Paint, LCP, Total Blocking Time, CLS, Speed Index e Time to Interactive, além das auditorias do Lighthouse que não passaram, das piores para as melhores. Tenha em mente os limites: é um único carregamento, feito a partir do nosso servidor nas condições simuladas do Lighthouse, então os números não vão bater exatamente com os seus dados de campo, e ele não consegue medir o INP, que depende de interações reais. O Total Blocking Time é o sinal de laboratório mais ligado à capacidade de resposta.

Teste alguns tipos de página representativos (página inicial, uma página de produto ou serviço, um artigo), rode cada teste mais de uma vez e olhe os resultados no mobile, não só no desktop.

As causas mais comuns e como corrigi-las

1. Resposta lenta do servidor

Nada mais pode começar enquanto o servidor não envia o HTML. Se o Time to First Byte está alto, a causa costuma ser hospedagem barata ou sobrecarregada, páginas montadas do zero a cada requisição, consultas lentas ao banco de dados ou visitantes distantes do servidor. Soluções: ative o cache de página (a maioria dos CMSs tem um plugin ou uma configuração de cache), coloque uma CDN na frente do site, remova os plugins de que você não precisa e migre para uma hospedagem melhor se o servidor simplesmente não dá conta. A orientação do Google considera bom um TTFB de 0,8 segundo ou menos. Nos rastreamentos de site completo, o Rudra sinaliza as páginas cujo servidor levou mais de 1,5 segundo para responder, e como críticas as que passaram de 3 segundos.

2. Imagens grandes demais

Uma foto exportada direto da câmera ou do celular pode ter vários megabytes e milhares de pixels de largura para depois ser exibida com 800 pixels. Redimensione, comprima e use formatos modernos. Nosso guia sobre como reduzir o tamanho das imagens mostra o passo a passo.

3. JavaScript demais

Bundles grandes e tags de terceiros (analytics, widgets de chat, testes A/B, scripts de anúncios) disputam a thread principal do navegador. Enquanto um script longo roda, a página não consegue responder aos toques, o que aparece como Total Blocking Time alto no laboratório e INP ruim em campo. Revise todas as tags de terceiros e remova as que ninguém usa, carregue os widgets não essenciais depois que a página estiver interativa ou quando o visitante pedir, e divida os bundles grandes para que cada página carregue só o que precisa.

4. CSS e scripts que bloqueiam a renderização

Os scripts no <head> sem async ou defer, e todas as folhas de estilo, precisam ser carregados antes que o navegador possa pintar qualquer coisa. Adicione defer aos scripts que não precisam rodar imediatamente, por exemplo <script src="/app.js" defer></script>, combine ou remova as folhas de estilo desnecessárias e considere colocar inline o pouco de CSS necessário para o topo da página.

5. Falta de compressão

Arquivos de texto (HTML, CSS, JavaScript, JSON, SVG) encolhem drasticamente com gzip ou Brotli. Na aba Network (Rede) do navegador, procure nos cabeçalhos de resposta da sua página por content-encoding: br ou gzip. Se não estiver lá, ative a compressão no servidor (no nginx, gzip on; mais uma lista em gzip_types) ou na sua CDN.

6. Arquivos estáticos sem cache

Quem volta ao site não deveria baixar de novo o seu logotipo e a sua folha de estilo. Para arquivos cujo nome muda quando o conteúdo muda (a maioria das ferramentas de build adiciona um hash, como app.3f9a2c.js), envie Cache-Control: public, max-age=31536000, immutable. Mantenha o HTML com cache curto ou com revalidação, para que as atualizações apareçam logo.

7. Fontes web pesadas

Várias famílias de fontes, cada uma em muitos pesos, somam rápido, e o texto pode ficar invisível enquanto as fontes são baixadas. Use menos pesos, sirva WOFF2, reduza as fontes aos caracteres de que você precisa (subsetting), adicione font-display: swap para que o texto apareça imediatamente em uma fonte substituta e faça preload apenas da fonte usada acima da dobra. Uma pilha de fontes do sistema dispensa o download por completo.

8. Mudanças de layout

Páginas que pulam geralmente são resultado de imagens e incorporações sem espaço reservado, anúncios injetados no meio do conteúdo ou banners que aparecem acima do texto depois do carregamento. Dê a cada imagem os atributos width e height (ou um aspect-ratio no CSS), reserve espaço para anúncios e incorporações com um min-height e exiba banners de cookies e de promoção como sobreposições, em vez de empurrar o conteúdo para baixo.

9. Páginas inchadas e requisições demais

Documentos HTML muito grandes (muitas vezes por causa de dados embutidos ou de grades de produtos sem fim), dezenas de scripts e o mesmo script incluído duas vezes deixam a página mais lenta. Pagine as listas longas, mova os dados embutidos volumosos para arquivos separados e com cache, e remova as tags duplicadas. O rastreamento do Rudra sinaliza documentos HTML com mais de 1 MB, páginas que referenciam mais de 100 recursos e scripts carregados mais de uma vez.

10. Redirecionamentos antes mesmo de a página começar

Um visitante que digita example.com e é redirecionado para https://example.com, depois para https://www.example.com e depois para /home espera por cada salto. Redirecione direto para o URL final em uma única etapa e use os URLs finais em todos os links.

O que corrigir primeiro

1. Se a resposta do servidor está lenta, comece por ela. Todas as outras métricas dependem disso.
2. Se o LCP está ruim, encontre o elemento de LCP. O Lighthouse diz qual é. Normalmente é uma imagem de destaque (comprima-a, não aplique lazy loading nela e considere fetchpriority="high") ou um título atrasado por fontes ou por CSS que bloqueia a renderização.
3. Se o Total Blocking Time ou o INP estão ruins, olhe para o JavaScript, principalmente para as tags de terceiros.
4. Se o CLS está ruim, reserve espaço para imagens, incorporações, anúncios e banners.
5. Teste de novo após cada mudança, para saber o que realmente ajudou.

O que um teste de velocidade não consegue mostrar

Um teste de laboratório carrega um único URL público, sem login, a partir de um único local. Ele não mostra a etapa lenta do checkout que fica atrás de um login, a página que só é lenta para visitantes de outro continente nem o widget que só se comporta mal depois de um minuto de rolagem. Use-o para encontrar e explicar problemas e depois confirme as melhorias nos dados de campo ao longo das semanas seguintes.

Erros comuns

• Correr atrás de uma nota perfeita no Lighthouse em vez das métricas que os seus visitantes sentem.
• Testar só no desktop, no Wi-Fi rápido do escritório.
• Aplicar lazy loading na imagem de destaque, o que atrasa o LCP.
• Instalar vários plugins de "velocidade" ou de cache que entram em conflito entre si.
• Avaliar uma mudança com base em um único teste; os resultados variam de uma execução para outra.